Location Based Access Control - v0.1.0 Released

Tags: #<Tag:0x00007f1f81f66fd8> #<Tag:0x00007f1f81f66790>

Location Based Access Control - v0.1.0 Released

Hi every one,

I am very happy to announce that the first version of the Location Based Access control module has been released!. You can download and install the module from these resources,

Deployment Steps for the Location based access control module can be found here :


The tickets information for this release can be found on the JIRA project here: https://issues.openmrs.org/browse/LBAC

I would like to request the community to download and test this module and give your feedback which is the most wanted requirement for now :smile:. Please feel free to post your feedback and comments about the module, and any suggestions or ideas to be added into this module.

What is Location Based Access Control?

Currently, OpenMRS has user privileges based access control. So the user needs to have the required privilege to access some of the OpenMRS service. Anyway, OpenMRS doesn’t have any proper location control for their services. Even anyone from any location can access the stored data(eg: Patients information, Encounters, etc)in the OpenMRS. Actually, still, they haven’t concerned about the location management inside the OpenMRS. But we should prepare the OpenMRS to support the access control based on the locations. It will add more value to the data security also and accessibility also.

Like the privileges based access control, we decided to implement a Location based Access control system for the OpenMRS. It will manage the access to all services based on the locations. Some implementations want to register the users and patients (the persons also) in certain selected locations. Then access them based on the location that someone has logged in. That way, if someone is logged in a certain location, they should see only those encounters, observations, and patients registered in that location.

Anyway, the user who has multiple locations access (like Admin in our privilege based access control system) should be able to see patients in all locations. We can allocate multiple locations access to the System Developer or System administrator.

I think you can simply understand the concept by these images,

How to use Location Based Access Control module?

Major features from this module are,

  • All Patient, Person, and User objects are restricted by the locations. A user from a location can’t get the patient/person/user information from another location.

  • Able to assign/edit the locations to the patient during the registration through the patient dashboard.

    1. Go to Patient Registration Dashboard. You can see a new section as “Patient Location”, and there will be a selection box with all active locations in your distribution.
    2. Select a location for the patient and complete the patient registration.
    3. Go to Find Patient Dashboard, and search for the patient. You can see that person only when you logged in with the same location of that patient location which was assigned during the registration.
  • Able to assign/edit the accessible location to the users through the Manage Account Page (In User section).

    1. Go to Manage Account Dashboard. You can see a new field as “Location” in the user section, and there will be a selection box with all active locations in your distribution.
    2. Select a location for the user and save it (Make sure about the user privileges).
  • Users can log in with only their credentials (username and password). There will be no need to select the locations from the login.

  • Encounters and Observations are restricted by the locations to see only the information which belongs to the user logged in location.

Cc : @dkayiwa


Exciting! :slight_smile:

Does this work at the API level, or at the UI level? e.g. how thorough is the protection? Can I find patients I’m not supposed to be able to see via REST? Or if someone emails me the URL of the dashboard of a patient I shouldn’t be able to see, can I click the link and see them?

What’s the performance implication of using this module once you have 10k or 100k patients?

1 Like

It works on the API level. We implemented this protection using the AOP techniques which track the OpenMRS services in the API level.

Eg : If we think about the PatientService, the LBAC module will track each get* methods (getPatient(), getPatients(), …). So when someone tries to access these objects from the API level, it will check the accessible locations of the authenticated user and will restrict by the locations. So,

  • You can’t get the patients objects which belong to other locations through the Patient Service
  • Thus you can’t get it through any UI levels or views
  • Thus you can’t get it through REST services and Data Exports (Reports and Cohorts need some work for the restrictions, and we are waiting for the feedback to start work on those)

Or if someone emails me the URL of the dashboard of a patient I shouldn’t be able to see, can I click the link and see them?

You can use that link or patientId to get the patient information from the system, only if you have the access to that location. If you haven’t the access to that location, then you can’t :slight_smile:

What’s the performance implication of using this module once you have 10k or 100k patients?

Still we haven’t estimated the performance for these scanerios. We will do it in the next phase and add improvements to the module as well :slight_smile:


Have successfully installed the module but I can’t see any location tab in the manage account dash. Using refapp 2.8. How do I use it?

@nourudeen are you following the instructions here? https://wiki.openmrs.org/display/docs/Location+Based+Access+Control+-+Deployment+Steps

cc @suthagar23

Yes. Probably its because I did not upgrade the refapp module to 2.9. Just built it and will retry again.

Used the latest of all the needed modules. But now experiencing a new issue. At login, there is no location selector but then I put my credentials, instead of logging in, it shows the username and password again but with the location selector. In user accounts, still no option of location.

Have you check this - https://addons.openmrs.org/show/org.openmrs.module.uiframework . Or you can use Manage modules feature in the Ref Application to search and download the modules (Check here).

I think, you have missed to update the modules required by this module. Please make sure about the required versions and configuration steps.

@dkayiwa I am having trouble with a particular step. After copying the custom definition, the step 6 is confusing. Which UUID you referring to?

That is the uuid of the person attribute which is used to for location property. You can follow that path(in step6) to get this uuid from your system.

Let me get this right…if I choose any person attribute eg mothers name, copy the UUID of the attribute, I am to replace the UUID of locationAttribute I created earlier which also has its own UUID? Whats the use of this person attribute in location selector? Am very confused.

Thank you guys. I finally did it. It works. Though I see I cannot assign location to an already existing user only for new user. But well it works. Thanks again @suthagar and dkayiwa

Why don’t you assign location to existing users? Did you try to edit the user(through the edit section, you can assign location for existing user)? We have implemented and tested this feature.

1 Like

@suthagar23, that looks promising :+1:

Is there a roadmap or list of the next phase and improvements?

I understand that the restrictions are made on the API level. Then how much of this module is dependent on the Ref App?

Can you assign location to existing patients? I asking this because when I click on edit on the patient header, it takes me to a page that only allows me to edit the patient name, gender and DOB.

I probably will need to edit this functionality so it points to the full patient registration page rather than a subset of it. (unless you have a way to do this easily?)

Hi @mksrom,

I and @dkayiwa is waiting for some suggestions from implementers to finalize the next steps for this module. Anyhow we have some steps which can lead this module to next phase. Those are,

  • Automating the LABC module installation, need to reduce the workload at the beginning of a user
  • Create a dashboard for LBAC module. I prefer to go for a react OWA, So we need some rest endpoints inside our module.
  • Create a REST endpoint to show/edit the configurations of LBAC (Create Person Attributes for LBAC, Global Property attribute for LBAC, Check and show about the required module’s versions to use a feature from LBAC, Login Screen managements, LBAC On/OFF feature). Then create an OWA page to show/edit the configurations of LBAC through the REST endpoint.
  • Create a REST endpoint to migrate a patient from one location to another location quickly, then create a page in OWA with required functions for patient migrations.
  • Enable encounter access based on multiple admitted/channeled locations.
  • Add location restrictions to Reporting-REST, and Reference metadata modules.

I understand that the restrictions are made on the API level. Then how much of this module is dependent on the Ref App?

It’s a separate module which depends on App UI, Admin UI, UI Framework, and Core 2.0.5. Take a look into here : https://wiki.openmrs.org/display/docs/Location+Based+Access+Control+-+Deployment+Steps


1 Like

Hi @jesplana

Have you followed this steps carefully : https://wiki.openmrs.org/display/docs/Location+Based+Access+Control+-+Deployment+Steps?

There should be a link as “Edit Patient Location” which will point to edit locations for existing patients. See here : https://medium.com/@suthagar23/allow-users-to-edit-the-patient-location-through-the-patient-dashboard-fd79feb3aba2

Please check and let me know, if you have any issues.


Thanks for the roadmap.

What I am trying to assess here is how much it leverages on Ref App UI specific modules and how big of a deal would that be to use it in Bahmni. Would it be a possible scenario to split UI and API components in 2 modules so any OpenMRS distribution could depend on it?

Actually, we wrapped OpenMRS core APIs through Spring AOP concept and implemented some UI Fragments (See here) which are specifically needed for this module (it will integrate with AppUI and AdminUI modules to add required fragments)

Would it be a possible scenario to split UI and API components in 2 modules so any OpenMRS distribution could depend on it?

Still, we don’t have any separate UI for this module. It designed to work completely in the background as a wrapper module for OpenMRS Core APIs. I don’t know, how to use this module for Bahmni since I haven’t any idea about that architecture. @dkayiwa Do you have any idea about How to make this for Bahmni?

Hi - @mksrom - at AMPATH we are interested in building on the user role provisioning functionality of OpenMRS core, and expand it to be able to track audit trails of providers accessing patient charts.

There may be overlap with location based access control.

We’d like to build this in such a way that it integrates into core, but doesn’t require the ref app. This would hopefully work both for Bahmni, AMPATH, and ref app applications.

Do you have any documentation from the Bahmni perspective outlining what functionality you’re looking for?

@suthagar23, do you think there is a way to disconnect part of this module from the Ref app?

cc @jdick