By Steve Hackbarth | 11/14/2016
The Ursa Server runs as a NodeJS cluster behind an Nginx reverse proxy, using Redis and a PostgreSQL application database. All four of these services should be running on the Ursa Health server for the application to function.
The Ursa Server also attaches to a datamart, where the clinical/claims/etc data is kept. The datamart can be a relational database of any structure. Oracle and PostgreSQL are both supported. If the datamart is PostgreSQL it is certainly possible to also run it with the Ursa application database on the Ursa Server. In a modestly-sized deployment it can simply be another schema on the same PostgreSQL database.
The following environment variables are required:
The location of the Ursa application database, in the form
postgres://ursa:changeme_to_secure_password@localhost:5432/ursa_app_db. The user
ursa. Please use a strong password!
You need not have actually created the database, user, or password yet.
The Ursa build process will walk you through those steps based on the values you put in this
The location of the datamart, in the form
postgres://ursa:changeme_to_secure_password@localhost:5432/ursa_app_db. If the implementation
is using postgres for the datamart it’s possible to make the DATAMART_URL the same as the
DATABASE_URL. Indeed, doing so will speed up instantiations considerably. The different data will
be kept in different schema.
The directory in which the PostgreSQL binaries (such as
pg_restore) are kept.
Because the Ursa application needs to be able to read and write to the datamart, if the datamart is shared with other users it is best practice to set up a service account for Ursa to the datamart and only grant write access for that account to a dedicated schema on the database.
The location of the Ursa application code, for example
The directory into which the Ursa application will output its logs. If you have set up cron, the application will also export an
ursa-app-db.dump every night into this directory. This dump represents the essential core of the metadata in ursa necessary to rebuild the entire database in the event of catastrophic data loss. It contains no PHI, unless an Ursa user has entered some PHI as a comment into the Ursa news feed. We strongly recommend you copy this backup dump every day into storage.
The web address of your Ursa application, for example
This must be set as:
A comma-separated list of usernames who have the authority to submit bespoke SQL into the database. This SQL will be executed during ETL without sanitization, so guard this list carefully and only grant this status to users who are qualified to have direct read/write access to the datamart.
To enable transactional emailing for cloud deployments, you’ll probably want to use Mandrill and
MANDRILL_API_KEY variable. To enable transactional emailing for on-premise deployments,
you can set
SMTP_HOST to something like
mymail.mydomain.edu. The port will default to 25 unless
you override it with the