Location Based Access Control - v0.1.0 Released

Development
,
21

@gschmidt most of this implementation is only connected with only OpenMRS Core to restrict the Core API responses based on the locations.

We only depend on the Ref App for some UI changes like adding/editing locations to patients and users. Hopefully we can integrate this module with other distributions like Bahmini, AMPATH if we have any UI alternatives to assign/edit locations for patients and users (as person attribute or user property).

22

Hi @gschmidt, I have limited requirements on this one. It has just been discussed on a call with a potential client. The idea is that they have 10+ small clinics all over the world and having 10+ production servers would be too expensive for them, and really some clinics are just 1 practitioner so not worth having a dedicated server.

The idea was to see if we could consider restrict the access Per Location. That way we would only have one production server set with multiple locations/clinics.

Since they need ERP features as well they lean towards Bahmni and not the Ref App but that may be something to discuss with them, as I guess we would have to apply the same Location based access control on Odoo too


@suthagar23 :

OK so that should not be too difficult to implement these UI components in Bahmni I guess.

2 Likes
23

@mksrom

You just need to adopt some UI implementation to show a location selector while Patient Registration(location property should save as a person attribute) and User registration (location property should save as a user property).

After, Location based access control module will start to work with OpenMRS Core APIs silently to restrict the metadata based on the locations :smile:. (You just need to make sure about the configurations also)

1 Like
24

@mksrom @suthagar23 cc @jdick @nkimaina @achachiez @rtanui

Hi - this is encouraging that we can get something that functions in core for location privileges potentially using the existing module. The AMPATH devs were talking on Friday and they built something to handle location privileges in the past, but didn’t roll into production.

(1) In addition to being able to control access to patients by location, we’d like to set permissions by department (eg. hypertension program vs HIV program), or by patient list (eg. for a research coordinator only to have access to those patients in their research study). Some of this we may be able to do using the built in privilege based access controls.

(2) We also have an interest to track audit trails (time-stamping which user opens which patient records). This may connect into this type of a module, or perhaps is entirely separate. But the ability to develop ‘alerts’ when users are potentially accessing charts they should not be accessing (ie. patients at a different location than the clinic they are in) would rely on location based awareness.

We don’t use ref app, and so we were hoping to connect these module’s UX to the OpenMRS core administration panel. Do either of you use it?

Two volunteer developers will be joining part time later this week, and this may be a good project for them to work on and potentially collaborate on the roadmap @suthagar23 mentioned above. Or are plans already in place to expand this via Google Summer of Code?

2 Likes
25

Yes we do.

26

@suthagar23, the person or patient object does not have a location field right? How does LBAC apply the filters on patients if they have no visit, encounter or obs?

27

Hi @gschmidt

Thanks for this idea, I will take this requirement to next phase this module development.

We don’t use ref app, and so we were hoping to connect these module’s UX to the OpenMRS core administration panel. Do either of you use it?

The current implementation of this module doesn’t have any separate UI. It designed to change some UIs of existing modules in ref app (e.g. patient registration page). We planned to initiate a UI for this module through the next phase of development once the functionalities of this module are accepted by some implementers.

Two volunteer developers will be joining part time later this week, and this may be a good project for them to work on and potentially collaborate on the roadmap @suthagar23 mentioned above. Or are plans already in place to expand this via Google Summer of Code?

Great news. Yes, I and @dkayiwa will help to make this module better. At the same time, we planned to move this module development for Google Summer of Code 2019 as LBAC Phase - 2 development.

1 Like
28

@suthagar23, the person or patient object does not have a location field right? How does LBAC apply the filters on patients if they have no visit, encounter or obs?

Yes, Patient or Person object doesn’t have location field by default.

When you install this module, it will create a person attribute type for location property. So then,

  • It will assign the location property of the patient as a person attribute
  • It will assign the location property of the person as a user property.

So it will filter the patient/user access by validating the person attribute/user property of respected objects.

1 Like
29

This is very interesting. I haven’t looked deeply onto the code. Can you help me with few questions?

  1. In the advisors, I see that there are restrictions placed on the invokable method names. Example: PatientService.getPatients. I am assuming that the “PatientServiceInterceptorAdvice” is called only for the matching methods. Would it be possible to allow “addition” to the “restrictedGetMethodNames” set for more methods, so that others may use the same means based on their needs.
  2. Does the LBAC cater to the location hierarchy as well? The advice does the filtering based on attribute against the specified provider/user location, using the LocationUtils method.
  • Would it be possible to consider hierarchy of Location as well. Example: I have a facility - and there are multiple login locations, under that “REG”, “EMERGENCY”, “OPD”, “IPD” or even various departments, depending upon how a specific context is modelled. A person maybe registered from or have encounters at different locations (a department, registration desks or OPD rooms or IPD wards). I believe while checking the provider/user location here, if we consider the descendant locations as well, it will allow users/providers to have access downstream as well (e.g. Encounter may happen at OPD or IPD, but if as a provider, by login location is at the Facility level, I want to get all the information for the patient across locations.
  1. Any thoughts applying the same over “org.openmrs.api.VisitService”?
  2. Does it need to depend on app-ui or refapp? From what I understand, the dependencies and means are really on the openmrs core. As long as the means of adding person attribute, global properties, provider attributes are done - then this should not be dependent on the refapp or app-ui.
1 Like
30

Hi @angshuonline

Yes, Possible! We can easily catch the “GET” methods and can restrict those based on the given instructions. In this line, we can split the method name, and catch the restricted GET methods.

Would it be possible to consider hierarchy of Location as well. Example: I have a facility - and there are multiple login locations, under that “REG”, “EMERGENCY”, “OPD”, “IPD” or even various departments, depending upon how a specific context is modelled. A person maybe registered from or have encounters at different locations (a department, registration desks or OPD rooms or IPD wards). I believe while checking the provider/user location here, if we consider the descendant locations as well, it will allow users/providers to have access downstream as well (e.g. Encounter may happen at OPD or IPD, but if as a provider, by login location is at the Facility level, I want to get all the information for the patient across locations.

We just implemented to restrict encounters/visits based on those respected locations during the Phase-1 development. We had this discussion during development also, and not decided to go with that since it made to more complex for the first phase of development. (See this ticket LBAC-16)

Anyway, we would proceed with this idea for the next phase of development like this following way, LBAC should restrict the patient’s encounters/visits based on the patient’s location (not by encounter/visit locations). Does it make sense? - Here we can allow the encounters/visits from different locations which belong to a patient who is under the same access location of the user.

  1. Does it need to depend on app-ui or refapp? From what I understand, the dependencies and means are really on the openmrs core. As long as the means of adding person attribute, global properties, provider attributes are done - then this should not be dependent on the refapp or app-ui.

NO, As I said before we just depend on the ref app UI for adding/changing patient locations, and user locations. If you have any alternative ways to add/change patient locations (as person attribute) and user locations (as user property), then you can simply go with this module without any issues.

31

Thanks for the clarifications.

regarding,

The module dependencies (config.xml) then needs to be modified for appui

32

Yes, we used AppUI module to get the logged-in location of the user via the session (See here). Then we are replacing the login property by the user property (See here) - It only applies if the user doesn’t have the location property at login time (For some existing users).

But when we totally migrate to LBAC, we will not have any location selection in the OpenMRS Login screen. So we don’t need to depend on this AppUI module or fetching location from session since no one can log in to the system without having location property.

1 Like
33

Hello. I have a really confusion scenario here. Thought the LBAC could solve my location access issue but
anyway I want this setup


  1. New patients come to reception and get registered.
  2. 2 nos. registration client computers in same room (reception above)
  3. Registered patients data accessed at another location called vitals area by a nurse
  4. Patients are seen by doctors at area called consultation.
  5. Returning patients schedule appointment at (1) above. All receptionist should be able to see all pts registered in facility or any location so that can schedule appointment for them but not see patient medical records. All vitals recording points should see all patients in facility registered at different points to input their vital. How can I get this done?
34

Problem I ran into is receptionist A registered patient but in search pt app, receptionist B does not see those patients (even though they are receptionists). Nurse for vitals does not and even doctor does not because they are in different places while in same facility and patient must pass through each of these points.

35

@nourudeen, are you using OpenMRS Ref App (or Ref App based) or Bahmni?

36

Openmrs 2.2

37

Hi @nourudeen,

Thanks for your info. Actually we haven’t implemented the feature which can track and allow the data access based on the user roles across multiple locations (for receptionist). Still It can restrict the data access based on the locations.

Hopefully , We will include this feature through the next development phase.

Thanks

38

Thanks for the help everyone.

39

Hi Im new to the OpenMRS Community. Just wanted to get an idea about the business-end application of this module before installing it. Using this module,

  1. Can a new health facility be set up in a different location that operates independently from other health facilities?
  2. Can a health facility access patient and staff data from another health facility?
  3. Which data can be restricted from one location to another?
40

@hasini location based access, as well as virtually any data segregation strategy, is better done with Data Filter, at least IMO. The module is reasonably documented, although this documentation is a little outdated and not quite to the point. Anyway, see Data Filter - Documentation - OpenMRS Wiki