Ursa Server Configuration

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 must be 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 environment variable.


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.


Must be pg, azuredw, vertica, or oracle.


The directory in which the PostgreSQL binaries (such as pg_dump and 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 /usr/local/ursa-app.


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 https://ursa.mydomain.com.


This must be set as:

export NODE_ENV=production


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 set the 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 SMTP_PORT variable.