Users

Levels of User Access

There are six levels of user access (with higher levels having all privileges of lower levels):

1. Limited End-User: has access to the overall dashboards and measure performance in Analytics Portal but no access to Case Review.
2. End-User: has complete access to the Analytics Portal reports to which they are assigned, including access to Case Review
3. Reviewer: adds read-only access beyond Analytics Portal to the full scope of Ursa Studio except for user management.
4. Architect: adds access beyond Analytics Portal to the full scope of Ursa studio except for user management.
5. Admin: adds access to create and edit users.
6. Bespoke Author: has the ability to create and edit bespoke SQL objects and bespoke models.

Bespoke Author authority is very sensitive because these users can save bespoke SQL objects and bespoke models to the database. Because bespoke R, Python, or SQL code is executed verbatim in the ELT process, this level of access should be considered comparable to giving database credentials and OS access. As such, there is no way through Ursa Studio for this user type to be granted. Bespoke Authors are defined by a comma-separated list of usernames in the BESPOKE_AUTHORS environment variable, defined at run-time of the application.

Allowing PHI Download

For deployments with PHI downloading enabled, admins can authorize users on a user-by-user basis to download PHI by means of a "Allow PHI Download" checkbox in the user screen. Any changes to this checkbox will be noted in the privilege escalation log, and if the user's authorization has been removed, the user will immediately be logged off from any active sessions, to enforce the updated restrictions. Limited End Users are never allowed to download PHI.

Authorized users will see a "Download Data to CSV" option in the case review (or data review) hamburger menu. For instances that allow an export to cloud storage, this export option will be independently available alongside the "download" option.

Password Management

For implementations in which Ursa Studio manages authentication, users can change their passwords in the user home screen, which can be reached by clicking on the My Account link in the topbar. There is also a token-based “Reset Password” link from the login page, which will send an authorization token to the email address profiled with the user.

Per HIPAA regulations, user accounts are locked after 90 days of inactivity, if the password has not been changed within 90 days (60 for admins), or upon 5 consecutive failed login attempts. Passwords are required to be at least 10 characters long and to contain at least three of the following: lowercase letters, uppercase letters, numbers, and special characters. These requirements are shown to the user in a tooltip whenever they set or edit their password. Furthermore, users will not be allowed to choose any of the most commonly used 10,000 passwords per industry-compiled lists. Users are not allowed to reuse any of their 12 recently used passwords.

User Groups

Grouping a number of users together can be convenient—for example, to grant them all access to a report en bloc or to send an email through Analytics Portal to a group. Users can either be added to groups from the user screen or from the user group management screen.

User groups can be tied with provider affiliations, such that the membership of the user group will automatically track the membership of the affiliation. To enable such automatic tracking, the origin of the user group should be set to Provider Affiliation.

Privilege Escalation Log

For compliance purposes, the User Manager dashboard supplies a report of all user creation, privilege escalation, user deletion, and user re-activation. The log even reports temporary modifications to user privileges. The privilege escalation log should be reviewed periodically by a privacy or compliance officer.

Hidden Namespaces

Ursa Studio administrators will be able to set a user's hidden namespaces, which represent the namespaces whose objects and measures the user is not authorized to view the contents of. Changes to a user's hidden namespaces will appear in the privilege escalation log and will automatically log the user out of any current session to enforce the change to their authorization.

Users will be blocked from seeing data from objects and measures in hidden namespaces. They will also be blocked from editing objects and measures in hidden namespaces or invoking objects in hidden namespaces while working with other objects and measures. Users can still view and edit measures and objects in unprotected namespaces that already invoke hidden objects; they are only blocked from adding new upstream hidden objects.

This allows data from sensitive namespaces to eventually flow into unprotected namespaces, but the only users capable of setting up such a data flow are users who themselves have access to the sensitive namespace. All redaction logic should happen in an object in the sensitive namespace, because once that object is invoked in an object or measure in an unprotected namespace, users can, for example, change the fields from the protected object that are published into the downstream unprotected object or measure.

Other User Access Control

User access is further controlled by individualized report granting and attribution fields. Users are only allowed to access reports to which they have been granted access.