User Management and Access Control
Roles and Privileges are controlled through the Administration page, under the Manage Users section.
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 Patients or Add Users) while roles are used to group privileges into more manageable groupings. To make the system easier to manage, roles can contain other roles as well as privileges. Roles inherit all the privileges of their parent roles.
We will use this example: you are working with several privileges related to patient data—e.g., View Patients, Edit Patients, and Add Patients. The View Patients privilege lets users look at patients in the system, the Edit Patients privilege lets users edit information about existing patients, and the Add Patients 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.
Designing role and privilege schemes
In order to give these privileges to the relevant users, you must define a role for each of these types of user.
|Medical Student||View Patients|
|Data Assistant||View Patients
|Data Manager||View Patients
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. 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)||Additional Privilege(s)|
|Medical Student||View Patient|
|Data Assistant||View Patient
|Data Manager||Data Assistant||Add Patient|
You can see that the Data Manager role can be 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.
In a common deployment scenario, you would define a role 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 new role that the others can all inherit from. 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).
There are some special roles that are predefined within OpenMRS and cannot be deleted: Anonymous, Authenticated, and System Developer. Any privileges granted to the Anonymous role will be available to people without logging into the system. Generally, Anonymous privileges should be 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. 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.
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.
You create roles through Administration > Manage Roles.
- Allows to add a new role
- Lists all roles present in the system
- Click a role to edit it.
If you then follow the Add Role link, you will see a form for adding a new role.
- Enter Role Name
- Choose Roles Privileges of which you want to inherit
- Choose Privileges which you want this Role to have
To create these users, we'll go through Administration > Manage Users. This page also lets you find and edit existing users.
- Create a new User
- Search Users by Name or Roles
- Search results
- Edit a single User
Users in OpenMRS need to be associated with Persons. You either need to create a new Person, or attach the user account to an existing one.
In both cases you will be taken to the same Add/Edit User screen. (If you selected an existing person, the fields in the Demographic Info section will be filled out for you.)