Adding more location restrictions to the OpenMRS Services — Location Based Access Control

Week 12 [July 31, 2018 — Aug 06, 2018]

Now the time to add more locations restrictions to the OpenMRS services and Metadata. OpenMRS Service methods are directly accessing the data access object(DAO) to get from the database. So I wanted to add the location restrictions to the following service's methods as the first step,

  1. PatientService Methods — Contains methods to get/set the Patient and the related information
  2. Person Service Methods — Contains methods to get/set the Person and the related information
  3. User Service Methods — Contains methods to get/set the User and the related information
  4. Encounter Service Methods — Contains methods to get/set the Encounters and the related information
The user is able to see the Patient — Suthagar in the Inpatient Ward
The user couldn’t see the patient — Suthagar in the Isolation Ward

These are the tickets related to the task which I have worked on the last week,

After that, I wanted to work with other OpenMRS components to verify those are working along with the location restrictions.

  • OpenMRS Cohort Builder
  • OpenMRS Reporting Module
  • OpenMRS Data Export

OpenMRS Cohort builder failed to address the location restrictions since it’s used an own service to access the DAO to get the patient information. So I wanted to add the fixes to reporting-compatibility module to work along with the location restrictions (And it’s should not depend on each other modules). After adding the fix, I can see the Cohort builder is working with the locations restrictions.

Admin user can able to see all the patients in the Cohort Builder
Doctor (not Admin) can only see the patients belong to the logged-in location in Cohort Builder

Data Export feature uses the reporting-compatibility module to export the data. Since we added the fix to the reporting-compatibility module for the Cohorts, Data Export also addressed the location restrictions.

Reporting module fetches the data directly from the database through the SQL queries. So We can’t add any locations based restrictions to those methods since we haven’t any query based restrictions methods. So we skip this part for the initial release and decided to address this issue in the next release as the main target.

Status of the Project Road Map

This is the last week of the Google Summer of Code, the project roadmap including the objectives and extra credits are given below with the status.


  1. COMPLETED : Assign users to locations on registration (LBAC-2)
  2. COMPLETED : Assign patients to locations on registration (LBAC-3)
  3. COMPLETED : During the encounter, observation, and patient searches, return only those in the logged in location (LBAC-8, LBAC-9, LBAC-14,LBAC-15, LBAC-16)
  4. COMPLETED : Ability to move patients from one location to another by an administrator (LBAC-5, LBAC-11)
  5. COMPLETED : Ability to assign locations to already existing patients (LBAC-5)
  6. COMPLETED : Ability to assign locations to already existing users (LBAC-2)
  7. COMPLETED : Login screen should not require users to select locations because, on login, you know the location to which a user belongs. (LBAC-13)

Extra Credit

  1. COMPLETED : When reports and other tools are run by a user in a certain location, they should include only those patients registered in the logged in location (LBAC-8, LBAC-9, LBAC-14,LBAC-15, LBAC-16)
  2. COMPLETED : REST calls while in a certain location should return only those results in the logged in location (LBAC-8, LBAC-9, LBAC-14,LBAC-15, LBAC-16)
Now the time to release the 0.1-beta version of the module … :-)
Like what you read? Give Kailayapathy Suthagar a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.