Page tree
Skip to end of metadata
Go to start of metadata


This page is devoted to discussion and design related to security and access control.  It arises from a Developers Forum meeting held June 20, 2013, and includes all the material from the notes of that meeting.  During the meeting, we tried to catalog inadequacies of and alternatives to our current access control system as the first step in a process of deciding whether and at what priority we might want to upgrade our current access control system.  We welcome peoples' experiences and ideas either in writing or in person.



  1. What standards are we trying to meet?  In US, HIPAA and states make the rules; Europe has privacy standards.  What about the countries we are working in?  Are there minimal good practices that we should try to propagate?  UNAIDS/PEPFAR have issued security and privacy guidance.  US FDA has special requirements for drug trials; as I understand them, they deal more with auditing than with privacy.  See Resources below.
  2. We would like to have the ability to limit access to patient and encounter data by location.  This handles two use cases: (a) a multi-facility installation, either internet connected or synchronized; and (b) a location within a facility with special privacy requirements, typically a psychiatric ward or an STD clinic.  We should discuss whether a treating physician (or others) without special privileges should be able to access these records.
  3. We would like to have the ability to limit access to patient and encounter data by role.  Registration clerks and administrators should not have routine access to patient health data.  Do we need to limit access any further?  E.g., should community health workers doing programmatic outreach have access to observations/encounters not related to the program?
  4. We would like to have the ability to limit access to providers who have a relationship with the patient.  See the British Medical Association principles in the Powerpoint presentation by Dominic Duggan below.
  5. Aggregate reports should always give the same results, regardless of who runs them.  This probably requires us to distinguish between reads for the purpose of aggregating and reads for the purpose displaying detail; we might be able to have reporting tasks run as a different, trusted user.  Should a registration clerk be able print out a flow sheet?




  1. Our basic role-based security involves basic SQL CRUD permissions on each table.  In addition, we have permissions for viewing/editing forms.  We have encountered the same issues described in Dominic Duggan's presentation – many privileges to assign, many facilities avoiding problems by giving people more rights than they should have.
  2. Restrict by roles module  This is currently unsupported and apparently did not work quite as desired.  It can do both location and role limitation if each location is given its own role.
  3. In OpenMRS 1.10 it is possible to define a privilege required to view or edit an encounter. TRUNK-3377
  4. A prototype implementation of the British Medical Association (BMA) security model was created as part of a senior design project.  See this wiki page..
  5. Lasantha Ranaweera created an XACML version of OpenMRS, see the discussion at!topic/dev/ZABGquZ8vdg and the Resources below
  6. Philip Fong and Syed Zain Rizvi have implemented a Relationship-Based Access Control (ReBAC) system in OpenMRS. An important feature of ReBAC is the explicit tracking of relationships between individuals in the system, and making authorization decisions based on these relationships.Role-Based Access Control (RBAC), which OpenMRS implements, provides a reasonably robust mechanism for restricting access to information; however, OpenMRS does not yet have a mechanism for restricting access to specific data (e.g., a clinician is allowed to access the record of patient X, but not patient Y; or, a clinician is permitted to access a patient's data except for specific lab results). An important feature of ReBAC is the explicit tracking of relationships between individuals in the system, and making authorization decisions based on these relationships.  See Resources below.


Dominic Duggan made a presentation which is attached to this page and available here.


Information on HIPAA

UNAIDS/PEPFAR Confidentiality and Security Guidelines

Relationship-based Access Control

General information on XACML

Lasantha Ranaweera's implemention of XACML for OpenMRS







  • No labels

1 Comment

  1. Recently I was asked to investigate access control in VISTA, the Veterans’ Administration open source EMR, and I had a realization which I should probably have had much earlier in connection with the British Medical Association model described on the wiki and my field trip to view the EPIC system (!topic/implementers/ZbsuyOaa0fo). That is that these systems are based on document management systems; it is the document more than the data within it which is controlled. A clinical note is a document written about the patient by the examining physician, and it is the physician and patient who control access to the document. OpenMRS, however, arose in a form entry environment where the data elements came from a defined vocabulary; it is more data element-oriented. The role-based table access privileges of our current system do not even address the same issues as access control in a clinical document context. And note that a document-based access control model can pose problems for clinical decision support or reporting, which may need to use data which does not “belong” to the current user, and for trans-document information such as problem and allergy lists.

    So if we are to implement an access control model which is more document-oriented, we need to look at our analog to the document, the encounter form. The encounter contains at least one provider, a patient and a location, which seems to be the type of information on which access control decisions are made; there is even encounter_provider_role, which might prove useful. The form has a schema, which is kept in the form and form_field tables (except for HTML form entry, see HTML-46). It might appear that form access privileges/rights would suffice. However, I think we have discovered that form fragments or sections are actually more useful, especially in direct entry environments. These sections provide re-use of code for display/entry of data which appears in multiple contexts, and can be subject to different access control. For example, the vitals collected at an otherwise confidential HIV visit can be used when evaluating a patient’s hypertension in a blood pressure control visit. (Compare the different security restrictions on each paragraph of the classified documents we have been reading lately.)

    There are some data elements which are kept outside of encounters. Most obvious are patient name, address and attributes; problem and allergy lists; and encounterless observations (for which I have never understood the need). Perhaps it would help if we had both person and patient attributes; the person attributes would be personal identifying information, while the patient attributes would medical/administrative information such as home clinic or number of pregnancies.

    I have no conclusions or proposals to offer, I merely wanted to raise these issues and solicit comments, either here on the web page or on the list (!topic/dev/bsYrQ02Okk4), where this is cross-posted.