Location Based Access Control — GSoC 2018 with OpenMRS
Primary Mentor: @dkayiwa
Backup Mentor: @wyclif
OpenMRS Wiki Pages :
Final Blog Report :
JIRA Project : - OpenMRS Issues
GitHub Repository : GitHub - openmrs/openmrs-module-locationbasedaccess: Adds ability to access patients based on their locations
Project Plan and Deliverables
As we planned, I have started to work on this project. As the first step, We decided to implement this feature as a separate module which can be attached to any OpenMRS distributions easily. The first phase of this project is planned to carry out through the Google Summer of Code period, and later on, it will be continued with more features.
These are the deliverables from the first phase of this project through the GSoC time,
-
Assign users to locations on registration -
Assign patients to locations on registration
-
During an encounter, observation, and patient searches, return only those in the logged in location
-
Ability to move patients from one location to another by an administrator
-
Ability to assign locations to already existing patients
-
Ability to assign locations to already existing users
-
The login screen should not require users to select locations because, on login, you know the location to which a user belongs.
-
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
-
REST calls while in a certain location should return only those results in the logged in location
Implementation
1. Restrict the patients by the locations
The first plan of our project is to restrict the patients by their locations. So I wanted to allow the users to register the patients with the location property which will be used to track them by the locations later. OpenMRS patient dashboard can be customized to include more fields using the app definition properties. So I used this feature to attach a location selector with the Patient Registration dashboard. After this, I worked to bring this feature for the Patient EditSection which can allow users to assign the location to the existing patients. So We have provided a basic implementation to assign the locations for the patients. Then I have worked to restrict the patients by the locations using the AOP techniques. I have added the AOP Advices to track the PatientService methods which are directly dealing with the patient objects.
So as the result,
- Super Admin can only access the patients from different locations since he is the only one who responsible for the OpenMRS objects.
- Daemon threads also can access the patients from different locations since those are used to track the patients in the background to increase the system usability
- The users from Location-1 can only see the patients from the Location-1. They can’t get the information from the Location-2
2. Restrict the users by the locations
The second phase of this project was to restrict the users by the locations. The ultimate target of this goal is to avoid the location selector from the login screens while logging-in to the OpenMRS. The user registration was done in the OpenMRS AdminUI module, and I can’t make any required changes on that dashboard to assign the locations during the registrations. So we decided to add more feasibility to the user registration dashboard to customize the registration fields using the OpenMRS extension configurations which can easily decouple the modules from the AdminUI. So I worked to implement this feature in the AdminUI module — User registration dashboard, and added support to autosave the field values with the dashboard updates for Person Attributes and User properties (the third party module doesn’t need to handle the update of that field information if it configured as a personAttribute or user property, it will be automatically saved by the Account dashboard itself).
So as the result,
- Modules can create the extensions to include the custom field to the user registration dashboard(person info section or user info section)
- Modules can create the separate extensions to include the custom view fragments to view the custom field information.
- Finally, I have used this feature to include a custom location selector in the user registration dashboard to allow the users for selecting the locations during the registrations. I configured to save that location information as the user property for that respected user.
3. Login without location selection
Currently, OpenMRS requires to select the locations during each user logins and that location is kept as a session variable in the web layer for the future usage. Since I have already added the feature to assign the locations to the users by the location properties, It can be able to fetch the user location again from the user property. So no more requirement to select the locations during each login. Finally, I have removed the location selection from the login screen.
So as the results,
- If the user contains the location user property, the login method will fetch that location as the session location
- If the user doesn’t contain the location user property(for existing users who haven’t the location user property) will be redirected to select the locations again.
4. Add more restrictions to the objects
So I have almost completed the location assignment part for the patients and users during the registrations. Now the time to add more restrictions for those objects by the location properties. So I wanted to figure out the solutions for,
- Restrict the encounters and observations by the locations
- Restrict the OpenMRS Reporting by the locations
- Restrict the OpenMRS Cohorts by the locations
- Restrict the OpenMRS REST Service by the locations
- OpenMRS Data Export feature should only export the information from the logged in location.
- So I have worked with my mentor to analyze those scenarios and added solutions to restrict those by the locations.
Mid Term Presentation
Learning through the GSoC
Not like last, This time I was able to dive more into the OpenMRS. Yes, I had a chance to make a new module for OpenMRS this time. I have worked with Java, Spring, and Angular during the project time, and got a lot of experience for the better programming and about the quality of the code. I would like to thank my awesome mentor Daniel Kayiwa(@dkayiwa) who helped me a lot during the last three months. I never felt about the remove working during the GSoC time, Since I was able to get the reply to each question and discussions quickly from my mentor.
The OpenMRS community also helped me a lot to clarify my problems and issues during the development time in the multiple components of OpenMRS.
Again a change to…. Write Code, Save Lives….!
Cc : @dkayiwa @danfuterman
– Suthagar.