When you onboard a new client, there are several things to consider, but probably most important is the security mechanisms to be used. This document discusses the issues to consider when configuring security for a department.

Overview

The monitor application allows for fine grained control over what users have access to the system and what features and functions and data they are allowed to make use of when using the application.

When a new lab/department is set up, a single user is assigned the responsibility of being the “Manager”. The manager acts as the controller of policies to be implemented within the department and is responsible for managing what users can be a part of the department and what they can see and do if they are a part of the department.

Users within a department are assigned a privilege level. The privilege level is a number between 0 and 8000 with the highest level privilege being 8000. The higher the number, the more applications a user has access to when using the monitor.

Applications are icons placed on the main menu. A manager can create any number of menus and assign any number of applications to that menu. When the menu is created, a privilege level is assigned to the menu. A user must have a privilege level assigned to themselves that is equal to or greater than the privilege level of the menu in order to be able to see and use the menu.

In essence, menus act as the primary method of assigning applications for use to users of a certain privilege level. Users can only use applications that appear on one of the menus they’ve been granted access to.

Once a user has access to the application, the features and data that the application displays is governed by the user class. A user class is a named entity that groups together a set of users with the functions being made available in the user class. For example, you may create a user class named “Care Coordinators” and provide access to PHI data to users that you place in the class and you might create another user class called “IT Support” that has access to the application but can not see any PHI data. What data is seen and what actions are available to a user then within an application are controlled by user class.

So, in essence, a user’s rights to use the data and tools within a department are specified by their privilege level and their assigned user class. It is the manager that makes those assignment.

Other people may have manager-level authority (8000 privilege and no assigned user class) within the department. As such, they can assist the manager with most configuration tasks, but it is only the manager who is allowed to establish certain policies and controls within the system.

The following sections provide additional information on the concepts described here.

Manager

The manager is the person responsible for the department. The department can only have one manager assigned, but the manager can have other assistants. A user with a privilege level of 8000 without any restricting user class can function as the manager with respect to most configuration but can not perform some of the functions that are specifically assigned to the manager, such as deleting the department.

The manager is typically assigned when the department is created, but can be changed by the manager to another user if required by way of the Lab/Department Notebook. The manager is listed on the front page of this notebook. Other 8000 level users that are eligible to be managers can be selected from to re-assign manager responsibilities.

Users

Before a user can work within a department they must be granted access to the department by the manager or someone else within in the department who has manager level authority.

Every user have a user profile which is identified by their user ID and password. The manager can create the user profile information for the user and then pass that information along to the user. When the manager creates the user profile, the manager can also assign a privilege level and a user class to the user. The privilege level and the user class provide the user with access to the system applications and dictate what features and data are available within the application.

A user may be a member of more than one lab/department. In that case, a manager can invite a member to join their department without having to first create a user profile. Rather, the manager references the pre-existing account when granting access to the department. No matter which method is used (pre-existing or new account) the manager gets to decide on the privilege level and user class that will be assigned to that user when they work within the department.

Passwords

Passwords are associated with user profile’s and therefore user IDs. A user ID and password is required to sign on and access the system. The rules that govern password use within the system are specified by the manager of the department. Password rules vary in complexity. A user’s account is subject to the strongest password rule set up for any department that they have access to.

For example, say Joe is a member of 2 departments. In one department, the manager has decided that no stringent password rules should be enforced. In Joe’s second department, that manager has decided to ensure passwords are 8 characters long, have special symbols and numbers and must be changed within 30 days. For Joe, this means his password must follow the more complex rule, even though Joe’s first department had no such restriction. The general rule is your password must match your most strict member password rule set up by your associated managers.

Privileges

A privilege in the monitor is just a number between 0 and 8000. The manager of the department gets to decide upon what those values mean. They do so by creating menus and assigning a privilege the the menu. In order for a user to use a menu (and the applications contained within it), they must have a privilege level higher than that of the menu. A user will have access to any menu whose privilege level is less than or equal to their privilege level.

The system does not enforce any specific privilege level configuration. Rather, the manager makes those rules and all users that are members in the lab/department, are subject to the rules set forth by the manager.

Menus

A menu is a named collection of applications. Menus are displayed in the top menu bar on the monitor. A user can select a menu and then the system will respond by showing the applications that are on that menu. The menu that is currently displayed is shown in the top left “black bar” when using the monitor.

A user may have access to one or more menus when working within a department. Which menus they have access to is based on their privilege level. A user can see all menus that have a privilege level less than or equal to their own.

Managers create menus and assign applications to the menu. They name the menu and they set the privilege level based on their requirements and security concerns.

User Classes

A user class is a named entity that connects users with features and data managed by an application. As an example, a user class might specify that all users within the class do not have the rights to download the patient list on the Subject Search screen. The application is “Subject Search” and the feature “Download” is turned off then for members of this user class.

Within a department a user can only be assigned to a single user class. They may however also not be assigned to a user class. If a user is not assigned to a user class, they are presumed to have access to all application features to which they have privilege for use. In other words, user classes restrict access to features and by default all features are enabled.

Sign On

By default, the monitor application uses something called “Forms Authentication” to allow a user to sign on. With forms authentication, the user is prompted to sign on if they have not already done so or if their session has expired and that sign on is done solely by the monitor application, comparing the user’s entered credentials with those stored in the monitor database. If the user enters valid credentials, they are signed on and placed within the default department to which they normally work. The menu they see displayed as their initial menu is the menu the manager has indicated they should see. Similarly, the first screen displayed is determined by what the department manager has specified for the user.

So, at sign on to the monitor, the system:

• Validates the user credentials
• Determines the users’s default department to start
• Determines the user’s privilege level
• Determines the user’s class
• Uses the determinations to display the default landing page for the user as configured by the manager.

Sessions

The monitor application is a web based application. Web servers perform better if they are not spending time managing users who are no longer actively using the system. To manage whether or not a user is actively using the system, the web based application creates a session when the user logs on. The session is updated each time the user interacts with the web based application by clicking on buttons that submit data.

Sessions are terminated automatically if the web based application determines that the user has not used the system within a preset amount of time. HIPAA rules mandate that this “time out” time be 20 minutes. This is not changeable. All users of the monitor follow the 20 minute rule. The HIPAA rule is in place to prevent people from walking away and leaving patient oriented data exposed for a non-authorized user to see. System-wise, the 20 minute rule also keeps the system focused on servicing users that are actively using the system rather than spending time and resources for inactive users.

To keep your session alive, submit data. Each time you do, the counter resets on when the session will time out. Some screens automatically submit data for you (specifically the dashboard can as can the notes screen) but all others require you to interact in order to keep your session alive.

If your session expires, you sign back on and usually you are placed right back to where you left off.

Single Sign on

Whereas the default mechanism is to use the credentials stored with the monitor database to provide authentication to a user, customers are allowed to set up a “single sign on” service to be used with the application. The single sign on service, once configured, routes all user IDs from a particular domain to an external service that validates whether or not the user should have access to the monitor. A typical scenario involves using the Microsoft Active Directory.

Single sign on is really nice as it allows a customer-based IT department the rights to turn off access to the monitor application using tools that they are familiar with at the point in time that they feel the changes are necessary.

Work with your technical team if you are interested in setting up single sign on for your users.