LMI - Administrative Documentation

Administrating OpenMRS

Controlling User Accounts & Privileges

OpenMRS uses privileges and roles to control access to data within the system. Privileges define what can or cannot be done in the system (e.g., Edit People or Add User) while Roles are used to group privileges into more manageable grouping. To make the system easier to manage, roles can contain other roles as well as privileges. Roles inherit all privileges that exist within the child roles.

We'll use this example: you are working with several privileges related to patient data — e.g., View Patient, Edit Patient, and Add Patient. The View Patient privilege lets users look at patients in the system, the Edit Patient privilege lets users edit information about existing patients, and the Add Patient privilege allows users to create a completely new patient record within the system. Now imagine that you need to assign the proper rules to three people: Mary the Medical Student, Bob the Data Assistant, and Erica the Data Manager. You want medical students to be able to view patients, but not edit or add them. Data assistants should be able to not only view, but also edit patient data. And you want your data managers to be able to create new patients within your system. In the simplest method of assigning privileges you could individually assign the privileges:

User	Privilege(s)
Mary the Medical Student	View Patient
Bob the Data Assistant	View Patient Edit Patient
Erica the Data Manager	View Patient Edit Patient Add Patient

However, with this scheme, each time you add a new user to the system, you will have to make sure that you assign all of the proper privileges to the user. As your system grows, you may have dozens of privileges to manage for many of your users and the management will become very difficult.

Now, let's introduce roles. We will define a role for each type of user we need. In this example, we have a medical student, a data assistant, and a data manager. Each one of these could be a role.

Role	Privilege(s)
Medical Student	View Patient
Data Assistant	View Patient Edit Patient
Data Manager	View Patient Edit Patient Add Patient

This looks very similar to the first case, except we are now assigning privileges to roles instead of specific users. Why bother? The benefit comes as you add more users to the system. Now when you need to add a new user, say John the Medical Student, you need only assign a single role to that user.

User	Role(s)
Mary	Medical Student
Bob	Data Assistant
Erica	Data Manager
John	Medical Student

Now, by defining the main roles for users of your system and assigning users to those roles, you have a much easier system to manage and users will automatically inherit all privileges given to their role(s). Of course, some users will have multiple roles. You can also assign specific privileges to users in special cases. Now, let's take this process one step further. While it may not seem necessary in this simple example, as your system grows, you will likely end up with a large number of different roles. Very often, certain roles can be defined as a combination of other roles. In our example, a Data Manager oversees the Data Assistants and, therefore, should have all of their privileges plus some additional privileges. So, let's redesign our roles slightly to show how this might work.

Role	Inherit Privileges from Role(s)	Privilege(s)
Medical Student		View Patient
Data Assistant		View Patient Edit Patient
Data Manager	Data Assistant	Add Patient

You can see that the Data Manager role is more clearly defined as a Data Assistant with the extra ability to add patients to the system. In addition, if you should change or enhance the privileges of the Data Assistant role at any time in the future, the Data Manager will automatically adapt to those changes — for example, if you decided a month later to allow any Data Assistant to Edit Encounters (by adding the Edit Encounters privilege to the Data Assistant role), the Data Manager role would automatically gain the ability to edit encounters as well.

Common scenarios would be to define roles like Provider that is inherited by Physician, Nurse, Clinical Officer, etc. You can then control most of the privileges within the Provider role and those changes will effect all types of providers in the system. If you find that you have to go through multiple roles and edit them to make a change, then you could likely benefit from defining a role that applies to all of the roles and/or users you are editing and make define a new role to manage those privileges. For example, if you found that you were constantly editing roles like Provider', Data Assistant, and Caregiver whenever you adjusted how patient data are allowed to be viewed in your system (i.e., affecting all users/roles that are allowed to view patient data), you might benefit from creating a new Patient Data Viewer role, assigning it to each of those other roles, and then managing the privileges in one place (under that new role).

Some privileges are built into the system and cannot be deleted. Other privileges may be added by modules. It is unlikely that you will be adding new privileges yourself, since privileges are only useful when they are understood and used by the system. On the other hand, you will definitely be creating new roles to fit your needs and will be managing privileges within those roles.

There are some special roles that are predefined within OpenMRS and cannot be deleted: Anonymous, Authenticated, Provider, and System Developer. Any privileges granted to the Anonymous role will be available to people without logging into the system. Generally, Anonymous privileges are kept very restricted, since patient information might otherwise be compromised. Privileges granted to the Authenticated role are granted to anyone that logs into your system, no matter what other role(s) they might be assigned. Granting privileges to the Authenticated role is an easy way to grant privileges to all users of the system. Provider represents the most basic care provider and can serve as the basic role from which to build specialized providers (physicians, nurses, medical students, etc.). The System Developer role is automatically granted full access to the system and should only be granted to system administrators.

Super users (system administrators) are automatically granted all privileges in the system; therefore, you must be very careful to protect your system administrator password.

---

What privileges are required for various actions?

• View Patients
  • Manage Relationships Template:Info
  • Patient Dashboard - View Demographics Section
  • Patient Dashboard - View Encounters Section
  • Patient Dashboard - View Forms Section
  • Patient Dashboard - View Graphs Section
  • Patient Dashboard - View Overview Section
  • Patient Dashboard - View Patient Summary
  • Print Clinical Summary
  • View Clinical Summary
  • View Concept Classes
  • View Concept Datatypes
  • View Concepts
  • View Encounter Types
  • View Encounters
  • View Forms
  • View Locations
  • View Observations
  • View Patient Programs
  • View Patients
  • View People
  • View Person Attribute Types
  • View Programs
  • View Relationship Types
  • View Relationships

• Do Data Exports
  • View Data Exports
  • Add Data Exports
  • Edit Data Exports
  • Delete Data Exports

• Work with Programs
  • Manage Programs - Required to add a new program, work flow, etc.
  • Edit Patient Programs - Required to allow a user to change the program that a patient is in.

• Tribes
  • Manage Tribes
  • Edit Person Tribe - Assign a patient to a tribe. Only required if global property restrict_patient_attribute.tribe is set to true

This section covered under the [OpenMRS Public License]