OpenMRS Planet

Google Summer of Code 2018 — Final Report

I am very excited to work with OpenMRS once again through this year Google Summer of Code(GSoC). Yes, I was selected to work on a project called Location Based access control in OpenMRS under the guidance of Daniel Kayiwa.

A little bit about OpenMRS

OpenMRS is an open source platform which enables the design of a customized medical records system without any of the software development experience (although it required medical and system’s analysis knowledge to use the system). OpenMRS is also a community of people working to apply health information technologies to solve problems, primarily in resource-poor environments.

OpenMRS Core is the baseline of the OpenMRS development and other modules are allowed to integrate with OpenMRS Core to expand their services and features. There are multiple distributions around the world based on the OpenMRS platform.

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.

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

I have to work for 12 weeks to complete the goal of Google Summer of Code program with OpenMRS. As the first step, I have worked on the Spring Aspect-Oriented programming(AOP) with OpenMRS which is the core part of our module. We decided to track the OpenMRS major services methods which are dealing with patients, users, persons, encounters, and cohorts to restrict by the locations.

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,

1. Super Admin can only access the patients from different locations since he is the only one who responsible for the OpenMRS objects.
2. 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
3. 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.

Adding custom fragments to Manage Account dashboard - Documentation - OpenMRS Wiki

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.

5. Module First Release — v0.1.0-beta

As we completed the first phase of this project, we decided to release the very first beta version of this module for the public usage. You can get the module from the OpenMRS Add-Ons or Bintray using this following link,

locationbasedaccess

Deployment

Detail module deployment guidelines can be found from this link,

Location Based Access Control - Deployment Steps - Documentation - OpenMRS Wiki

JIRA Tickets and Pull Requests

Location based access control project Link to the OpenMRS JIRA : LBAC

I wanted to work on multiple components in the OpenMRS to address the location based control implementation. I have listed those tickets below,
LBAC — Location Based Access Control
RA — Reference Application
EA — EMR API module
RCM — Reporting Compatibility module

We had a brief discussion about each and every pull requests for the tickets and my mentor reviewed those pull requests as soon as possible to hurry the project implementation. Actually, he worked me to review each and every line of the pull requests to improve the code quality. I was able to learn much about the code quality and the techniques through those pull request reviews.

• LBAC-1 : Abstract design for the location based access control project.

LBAC-1 Changed the module structure based on the classes by suthagar23 · Pull Request #24 · openmrs/openmrs-module-locationbasedaccess

• LBAC-2 : Assign users to the locations on registration

LBAC-2 Added implementation to add the locations to the users on registration by suthagar23 · Pull Request #17 · openmrs/openmrs-module-locationbasedaccess

• LBAC-3 : Assign patients to locations on registration

LBAC-3 Added implementation for assigning the patients to the locations on registration by suthagar23 · Pull Request #4 · openmrs/openmrs-module-locationbasedaccess

• LBAC-4 : Create basic module structure for the project

Created new module for Location based access control project by suthagar23 · Pull Request #5 · openmrs/openmrs-module-locationbasedaccess

• LBAC-5 : Allow to edit the patient’s locations through the patient dashboard

LBAC-5 Added implementation to edit the patient's locations though patient dashboard by suthagar23 · Pull Request #8 · openmrs/openmrs-module-locationbasedaccess

• LBAC-7 : Select the session location as default to the fragment location selector

LBAC-7 Added fix to select the session locaion in the location selector by suthagar23 · Pull Request #9 · openmrs/openmrs-module-locationbasedaccess

• LBAC-8 : Failed to filer the patients who listed in the findPatients page before searching

LBAC-8 Fixed to restrict the patients on findPatients initial view by suthagar23 · Pull Request #10 · openmrs/openmrs-module-locationbasedaccess

• LBAC-9 : Failed to restrict the patient by location when searched using the UUID

LBAC-9 Added AOP Advice to getPatientByUuid method in the PatientService by suthagar23 · Pull Request #11 · openmrs/openmrs-module-locationbasedaccess

• LBAC-10 : Failed to get the location property from the Daemon thread user

LBAC-10 Added exception for Daemon thread user to access the methods covered with AOP Advices by suthagar23 · Pull Request #13 · openmrs/openmrs-module-locationbasedaccess

• LBAC-11 : Allow system administrator to access all the patients in the system

LBAC-12 Added fix to show the patient location in the patient dashboard by suthagar23 · Pull Request #15 · openmrs/openmrs-module-locationbasedaccess

• LBAC-12 : Indicate the patient location information in the patient dashboard

LBAC-12 Added fix to show the patient location in the patient dashboard by suthagar23 · Pull Request #15 · openmrs/openmrs-module-locationbasedaccess

• LBAC-13 : Create RefApp Location Global property while starting the module to change the login screen

LBAC-13 Added implementation to create RefApp location glopal property by suthagar23 · Pull Request #19 · openmrs/openmrs-module-locationbasedaccess

• LBAC-14 : Add restrictions to the PersonService methods to restrict them by the locations

LBAC-14 Added restrictions to the PersonService methods to restrict them by the locations by suthagar23 · Pull Request #20 · openmrs/openmrs-module-locationbasedaccess

• LBAC-15 : Add restrictions to the UserService methods to restrict them by the location

LBAC-15 Added restrictions to the UserService methods to restrict them by the location by suthagar23 · Pull Request #22 · openmrs/openmrs-module-locationbasedaccess

• LBAC-16 : Failed to restrict the encounters of the patients from other locations

LBAC-16 Added implementation to restrict the encounters of the patients from other locations by suthagar23 · Pull Request #23 · openmrs/openmrs-module-locationbasedaccess

• RA-1503 : [AppUI] Store the session location information into the UserContext to extend the API usage

RA-1503 Added implementation to store the session location in userContext by suthagar23 · Pull Request #19 · openmrs/openmrs-module-appui

• RA-1511 : [Registration App]Allow users to customize the info message while editing the patients through section

RA-1511 Added fix to support the custom fragment info message for editSection by suthagar23 · Pull Request #33 · openmrs/openmrs-module-registrationapp

• EA-138 : Failed to load all the patients if one patient is missing in the lastViewedPatient list.
• RA-1513 : [Admin UI] Add new account/Edit account dashboards should allow the extensions to add the custom fragments to the dashboard

RA-1513 Added support to allow the extensions to add the custom fragments to the Manage Account dashboard by suthagar23 · Pull Request #44 · openmrs/openmrs-module-adminui

• RA-1516 : [Reference Application] Add support to select the location from the userProperty in the Login Screen

RA-1516 Added support to select the location from the userProperty in the Login Screen by suthagar23 · Pull Request #47 · openmrs/openmrs-module-referenceapplication

• RCM-108 : Add restrictions to the ReportService methods to restrict them by the location

LBAC-17 Added restrictions to the ReportService methods to restrict them by the location by suthagar23 · Pull Request #25 · openmrs/openmrs-module-locationbasedaccess

• RCM-109 : Need to add patient verification to return Cohorts objects for the serviceMethods

RCM-109 Added patient verification to return Cohorts objects for the serviceMethods by suthagar23 · Pull Request #39 · openmrs/openmrs-module-reportingcompatibility

Weekly Reports and Presentation

This is the mid-term presentation for OpenMRS about the project. I have added some demonstrations about the project in this video.

Weekly Reports are listed below,

1. Week-1 : Introduction to Location Based Access Control
2. Week-2 : Aspect Oriented Programming (AOP)
3. Week-3 : Customizing the OpenMRS Patient Dashboard with Access Location Information
4. Week-4 : Location based access control for patients
5. Week-5 : First Evaluations — GSoC 2018
6. Week-6 : Touching the Target of Phase — 1 for Location Based access control to the Patients
7. Week-7 : Adding restrictions to the users to view the patient without location
8. Week-8 : Allow users to edit the patient location through the patient dashboard
9. Week-9 : Second Evaluations — GSoC 2018
10. Week-10 : Assign Locations to the Users through the Location Based Access Control Module — OpenMRS
11. Week-11 : Say Goodbye to OpenMRS login location selection
12. Week-12 : Adding more location restrictions to the OpenMRS Services — Location Based Access Control

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 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 for each questions 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….!

What if my partition is not showing up or gone missing?

In that case, TestDisk could help. It is a disk utility designed to help people recover their lost partitions.

To install it, here in my case on Debian, I’ll do

$ sudo apt-get install testdisk
$ testdisk

TestDisk has a QUICK SEARCH option which can search and list all your missing partitions if there’s any. Most probably your missing partitions should have appeared by now. If not, try running a DEEPER SEARCH. Once it found any, use the WRITE option of TestDisk which will re-write the partition table for you.

Restart your computer and your missing partitions should now show up.

I won’t go into detail. For a more thorough guide, follow the Step By Step guide from the official Wiki.

How to fix when my NTFS goes RAW?

It’s better to use Windows utilities when it comes to dealing with NTFS.

1. Boot into a Windows Recovery Disk.
2. Then go into ‘System Recovery Options’ menu.
3. Open the command prompt window.

4. Use one or more of the following commands to find out the label of your corrupted partition.

    diskpart list disk
    diskpart select disk
    diskpart list volumes
   

5. Once done exit from diskpart and run

    chkdsk /f /r D:
    where D: is the drive letter of the corrupted partition. 
   

If you have got better solutions, let us know in the comment section.

Project — Enhancements of Attachments Module.

Primary mentor : @mksd ( Dimitri R)
Backup mentor : Muhammad Ahmed Memon , chine zoheir
Student: Ridmal Madushanka
Project wiki: Link

Overview:

OpenMRS is an open source software platform which provides facilities to design of a customized medical system with no programming knowledge. Attachments module in the Open MRS enables the view and manages file attachments functionalities in the openMRS. Basically user ( with privileges ) can upload , view and delete the attachments for particulate Patient. Attachments both integrates on the Clinician Facing Patient Dashboard and on the Visits & Encounters Patient Dashboard.

Objectives:

So main objectives of this GSOC program is enhance the Attachment module to version 2.0.So it consist of two main objectives.

1. Attachments to become 100% RestFull.

Issues IDs : ATT-24 , ATT-27

• Implement Attachment Service( Fetch the Attachments based on the given parameters )
• Develop test cases for each method in the Attachment Service ( Java API )
• REST end point for file upload should allow to specify encounter
• Implement Serach method in Attachment Resource.
• Develop Context-independent Test methods ( Mock tests ) for Test the Attachment Resource Search method.

2. Segregate Attachment UI to Open Web APP ( research part ).

GSoC Contributions:

Description about the contributions can be found in the below blog posts. Flowing Commits are my contributions to the Attachment Module in this GSOC program.

• ATT-24: AttachmentResource's doSearch() mock-based tests · openmrs/openmrs-module-attachments@c237dec
• ATT-24: includeRetired becomes includeVoided · openmrs/openmrs-module-attachments@9095a67
• ATT-27: REST end point for file upload should allow to specify encounter · openmrs/openmrs-module-attachments@c4d6b91
• ATT-24: Foundation of the Java API. · openmrs/openmrs-module-attachments@fb128fe

Other Resources:

Mid-Term Presentation :

Weekly Blog posts :

• GSOC 2018 with OpenMRS — Week 1
• GSOC 2018 with OpenMRS — Week 2
• GSOC 2018 with OpenMRS — Week 3
• GSOC 2018 with OpenMRS — Week 4
• GSOC 2018 with OpenMRS — Week 5
• GSOC 2018 with OpenMRS — Week 6
• GSOC 2018 with OpenMRS — Week 7
• GSOC 2018 with OpenMRS — Week 8
• GSOC 2018 with OpenMRS — Week 9
• GSOC 2018 with OpenMRS — Week 10
• GSOC 2018 with OpenMRS — Week 11
• GSOC 2018 with OpenMRS — Week 12

OpenMRS talk thread :

All the things i have been working on from the beginning of the GSOC program is recorded in the OpenMRS talk threads.

• GSCoC 2018 / 'Attachments enhancements'
• Attachments: REST end point for file upload should allow to specify encounter (ATT-27)
• How to expand and integrate privileges in Attachments (ATT-9)

Further Works:

Segregate to Attachment UI to Open Web app is not yet started for implementation. it need to have more research on how to implement that. So i hope to continue its work after the GSOC program.

Experience:

Actually this is my first time with GSOC and it was really awesome experience to me. Able to work with top level developers and gain more knowledge with the help of them. The most amazing thing in the GSOC program is that we can get more things we didn’t expected. For example Attachment module is used test driven development for its implementations and because of that i am able to learn and practice test driven development strategies first time.

And i loved every moment i worked in this GSOC program. Most specially i would like to thanks @mksd who help me a lot in this time period. He gave me lot of knowledge , motivate me , Kind to me and always correct my mistakes. He work with very patient and he always allow me to talk anytime to him even he is vey busy with other works.I am very glad to meet him in this GSOC program. Also i would like to thank all the others including my backup mentors who helped me in this time period.And I wish to continue my work with this awesome Organization and “ Write code to Save lives”. :-)

Hello World! This week was very hectic as I had been undergoing training at the company that I recently started working for. Could only dedicate the weekend to the project. I played around with mockito and in memory database to try to figure out how the module could be tested. once after figuring out how the tests worked, I realised that i had to refactor the code quiet a bit to make it testable. Spent the rest of the time in refactoring and writing tests. Thats all for the update. Thanks for reading.

GSoC with OpenMRS week 10 was originally published in piyush.kundnani on Medium, where people are continuing the conversation by highlighting and responding to this story.

Overview

• Primary mentor : Daniel Futerman
• Backup mentor : Darius Jazayeri
• Student : Isuranga Perera

Bahmni is built for point-of-care use, and healthcare workers use it directly as they are seeing patients in resource-limited settings). This works for many workflows (e.g. seeing patients in the order they are queued), but adding a notification would allow for some improved workflows, by not requiring the doctor to actively remember to check on things.

For example:

1. A doctor requests lab tests for a patients, and wants to be notified as soon as the results are ready (or perhaps only if there are abnormal results)
2. A doctor wants to know if one of their patients is revisiting the facility (to provide followup care, because the patient is participating in a research study, etc)

Objectives

The main objective of this project is to provide ability for healthcare providers to be able to subscribe (unsubscribe) to and get notifications of specific events for patients of their special interest.

Use-cases

1. As a doctor i am doing my final year thesis and i have identified a set of patients. I would like to meet the patient whenever the patient is visiting the hospital.
2. (1) doctor sees the patient and orders a lab test, (2) patient goes back to the waiting room, (3) doctor continues seeing more patients out of the queue (i.e. still at hospital in the same consult room, sitting by the computer), (4) lab result is ready, and doctor gets notified, (5) doctor sees the original patient next, before returning to the queue.
3. (1) doctor sees patient in outpatient clinic in the morning, and orders some lab tests, (2) in the afternoon doctor is rounding in the inpatient wards (i.e. still at the hospital, but somewhere else, not in front of a computer), (3) lab result is ready, and doctor gets notified, (4) doctor advises nurse on what action to take
4. (1) doctor sees patient, and orders a lab test that takes days to complete, (2) patient goes home, (3) result is ready, doctor is notified, (4) doctor works with registration clerk to track down patient.

Project Design

This project is composed from 2 major components.

1. Subscriptions management module — users create new notification subscriptions , covering the following workflow.

I create a new notification rule -> I choose a patient -> I select one or more predefined events -> I choose a notification type -> I start getting notification whenever the event happens.

2. Microservice to read Bahmni atom feed — This module keep polling the Bahmni atom feed and determines whether anything notifiable has happened.

Subscriptions Management Module

Subscription management module expose UIs which allows users to create/modify subscriptions for notifications by associating various events (patient visit, lab result arrival etc.)

This module is composed of three layers

1. OWA — Frontend of the application. Expose relevant UIs to manage subscriptions.
2. API — Dao entities and service layer of the application. Expose a set of APIs
3. OMOD — Expose endpoints to service layer operations. OWA deals with this component

Flow of creating new subscriptions

Feed Reader Microservice

Atom Feed Processor microservice is responsible for polling the atom feed for new notifications(events) and process them in order to identify if there are events that users are subscribed for. To be precise there are 2 layers of filters at the Atom Feed Processor.

1. Layer 01 — Filter new notification based on subscriptions. Notification which are not relevant (No user has subscribed to these notifications) are rejected. Only those relevant events are directed to the next filtering layer (Layer 2)
2. Layer 02 — Search for patients involved with the received notification. Notifications are accepted only if the notification relates to a patient to whom users have subscribed for.
3. This is an optional layer of filtering which associated with lab results. This filtering is called after layer 01 & layer 02 filtering only. This checks if the lab results are normal or not. Notification is accepted only if the lab result is abnormal; otherwise rejected.

Activity diagram of microservice

Technologies used for the microservice

1. Java
2. JavaSpark Framework
3. Hibernate
4. MySQL

Interim Presentation

Final Project Demonstration

Future Work

This module was developed as a proof of concept. Therefore notifications icon and logic behind it only appears in notifications owa. However this can be easily moved to Bahmni header whenever needed.

Currently, the module supports two predefined events (patient visit & lab report arrival). However, using predefined events make the module less flexible. When a user needs to add more events he has to modify the code base. Therefore having an alternative way to define events is much suitable. This can be achieved by specifying a custom schema/configuration (JSON or XML). The module should be able to parse the configuration provided by the user and add the new event.

In addition to that microservice module can be improved to handle failed events and resend them whenever the relevant user becomes available.
One of the most important things is using a graph database to specify relationships among entities/events (patient visit event has patients and the user etc.). By using a graph database we can support events with more complex relationships.

Final Words

The community has been quite supportive throughout this time, and I’d like to say thank you all! Plus, we should definitely add more documentation for the resources available — like the UI Commons library.

And a special thank you to @danfuterman for always checking on my work and motivating me to do my best.

It’s been a privilege working with the OpenMRS community, and I hope to be part of it in the future as well. Thank you for a summer well spent

Reference

1. Subscription management module project repository
2. Microservice project repository
3. JIRA board
4. Project Description

• Primary mentor : Sam Mbuga
• Backup mentor : Martin Were
• Student : Dileka Madushan
• Project Wiki: Link

Overview

The Patient Clinical Summary generates a summary that is being displayed on the patient dashboard which is helpful for the clinicians to make clinical decisions without going through numerous encounters/observations. It would also be helpful for clinicians access these reports off-line specially when they visit patients in rural areas.

Objectives:

• Generating Patient clinical summaries using SQL data set definitions.
• Creating scheduled tasks to generate patient clinical reports.
• Creating user interface to create report configurations.
• Creating back-end infrastructure to implement functionality.
• Creating endpoints to consume reports from Muzima Android App.
• Modifying Muzima Android app to display reports to the user.

GSoC Contributions

• GSoC 2018 Patient Clinical Summary Enhancement Changes For reveiew by dilekamadushan · Pull Request #38 · muzima/openmrs-module-muzimacore
• GSoC 2018 Patient Clinical Summary Enhancement Changes For reveiew by dilekamadushan · Pull Request #185 · muzima/muzima-android

Mid Evaluation Presentation

Video Presentation.mp4

Other Resources:

• Project Documentation: https://wiki.openmrs.org/display/projects/Patient+Clinical+Summary+Enhancement
• Talk Discussion: Openmrs Talk Thread
• Blogs: Medium Blogs

Thoughts on GSoC:

It has been a wonderful experience for me for the last 12 weeks to work with OpenMRS and GSoC community. I gained lots of valuable technical knowledge. I had the opportunity to dive deep into Spring and Android in development phase. It was a real pleasure working with the likes of my mentor whom had a lot to offer me 😆.

Though GSoC is coming to an end, my contributions to the open source community starts from this year and I hope to continue it for a long time to come 😅!

OpenMRS Android Client 3.x Project

• Primary mentor: Shivang Nagaria
• Backup mentor:  Avijit Ghosh
• Student: Chathuranga Muthukuda
• Project wiki: https://wiki.openmrs.org/display/projects/OpenMRS+Android+Client+3.x+Project

• Make improvements to the way that charts are being displayed
• Progress Dialog Improvements
• Replace RangedEditText with seekbar
• Use TextInputLayout instead of the normal EditText

• Security Improvements:


• Encrypt the database using the details derived from the username and password of the user
• Password Change detection and log out the user
• Forgot password option

• Application tour

• OpenMRS Analytics tool implementation

Google Summer of Code final report

Project : Trust based routing protocols framework

• Primary Mentor — Tommaso Pecorella (Assistant professor at University of Florence, Italy)
• Backup Mentor — Tom Henderson (Affiliate Professor in Electrical Engineering at the University of Washington in Seattle, WA)
• Student — M. A. Jude Niroshan

NS-3 is a discrete-event network simulator for Internet systems, targeted primarily for research and educational use. NS-3 is a free and open source software which is publicly available for research, development, and use. It has thousands of users which is backed by a active community. NS-3 participated in Google Summer of Code in 2018 and I was privileged enough to contribute to NS-3 with a great passion. I worked on developing a new trust based routing protocols framework to NS-3. I was really lucky enough to be guided by my mentor Tommaso Pecorella and Tom Henderson who is the executive director for the NS-3 Consortium.

Why trust based routing protocols?

Networks are susceptible to attacks by malicious nodes that could easily bring down the whole network. Therefore, it is important to have a reliable mechanism for detecting and isolating malicious nodes before they can do any harm to the network. Usually, routing protocols discover usable multi-hop routes between source and destination nodes. However, some of the routes found and used may not be as reliable or trust-worthy as expected. Thus, finding a trusted route is an important component for enhancing the security of communication.

Trust value will be calculated based on different routing parameters(rreq, rply, err, etc) or routing metrics(bandwidth, cost, etc). Therefore, trust will become a routing metric which can be used to determine the optimal route for forwarding packets. Eventually trust value can be considered as a security factor for making the routing decision.

Trust based routing protocols have great demand and researchers trying out many variations of them. There are quite a lot of research publications have presented on this topic and more are yet to be published. Therefore, it would be beneficial to facilitate for those developers who wish to try out any trust based routing protocol simulations on ns-3. This project has initiated the framework with a basic infrastructure.

Why need a trust based framework?

Trust is a subjective measurement. There are many research papers have published which has various methodologies of calculating the trust value for the same routing protocol.

For e.g.: If we consider AODV routing protocol; following papers have came up with different approaches for trust value calculation.

Li, X., Lyu, M.R. and Liu, J., 2004, March. A trust model based routing protocol for secure ad hoc networks. In Aerospace Conference, 2004. Proceedings. 2004 IEEE (Vol. 2, pp. 1286–1295). IEEE.

Marchang, N. and Datta, R., 2012. Light-weight trust-based routing protocol for mobile ad hoc networks. IET information security, 6(2), pp.77–83.

Pushpa, A.M., 2009, December. Trust based secure routing in AODV routing protocol. In Internet Multimedia Services Architecture and Applications (IMSAA), 2009 IEEE International Conference on (pp. 1–6). IEEE.

Current NS-3 version(ns-3.28) does not welcome trust based routing protocols by default. If someone wants to simulate a trust based protocol in NS-3, there are lot of changes needs to be done in many concrete level classes. This is cumbersome and it’s against the conventions that we follow from the maintenance point of view. NS-3 cannot define only one way of calculating trust value as each of the above mentioned methods/approaches have written to serve specific concerns/issues. Therefore, it’s clear that allowing any custom trust calculation run through a framework is a better move from NS-3. This will help the developers to try out trust based frameworks in NS-3 with minimal amount of coding.

Trust framework has developed with no modifications to the existing protocols and ns-3 core modules. It has been developed as a third-party ns-3 application. Anyone who wish to use the framework can simple use the “trust-routing” module. We have planned to push Trust framework to ns-3 app store and it will be publicly available soon for anyone.

trust-routing/trust framework alone cannot transform a protocol into a trust based protocol. Usually, trust based routing protocols have different favors in terms of the algorithm and trust value calculation. Therefore, framework does provide only the abstract classes and a basic trust table. It is the responsibility of the trust framework consumer to provide a suitable trust protocol implementation to run on it. Trust framework acts as a mediator between a concrete trust based protocol and ns-3 core modules.

As you can see in the diagram, trust-aodv, trust-dsr and trust-dsdv are few of those such implementations provided to trust framework. Implementation modules contains all the different behaviors and how the entire protocol manipulation defined. Some could say that the trust-routing is an umbrella module that facilitates different trust implementations.

trust-routing

Similar to any other NS-3 modules, trust-routing module also have a common module structure. Sphinx documentation is available under the ‘doc’ folder. trust-manager-helper is resides inside the helper folder. Under the model, we have only three classes at the moment. Those are trust-entry, trust-table and trust-manager. Inside the test folder, test case for trust table have written.

trust-entry

Each record in the trust table is represented by a trust-entry instance. This includes only 3 attributes. ns3::Address, double m_trustValue, ns3::Time m_timestamp.

trust-table

trust table contains the trust entry objects which includes the trust values. Intended design is to have one trust table per node in the network. This will be very similar to the routing table except that it has only trust values for different destination route nodes within the network.

trust-table provide basic operations to add, update, remove trust-entry records from the trust table. These methods have been covered from the test case available inside the test folder. There is also another method called AddOrUpdateTrustTableEntry() which in fact taken into discussion whether we could keep this method or not. Because it is simply a combination of AddRecord and UpdateRecord methods in the same class. This has provide for the ease of developers and achieve the task with less number of lines. But this is an controversial with the philosophical point of view of class trust-table.

trust-manager

In order to define the most essential operations for any trust based routing protocol, this manager has been used. It is an abstract class which forces the implementer to provide an implementation to CalculateTrust().

trust-manager -> ns3::Application

It is worth to mention that trust-manager extends from ns3::Application. This allows the developers to simply install any of the trust-manager implementations as an application to different hosts in the network. It made the usage of trust based routing protocol variations a lot easier when it comes to using them in multiple simulation setups.

trust-manager-helper

Helper classes in ns-3 are usually the entry point to install the relevant applications and access other utilities. In trust framework, trust-manager-help does the same actions. This is some what like a replica to ipv4-routing-helper / ipv6-routing-helper. Currently the main usage of this class is to print the trust tables. In future there are other utilities methods can be placed inside this class.

As mentioned above in this post, trust-routing is the trust framework. Framework has developed with the intention of facilitating different types of trust based routing protocol implementations. In order to demonstrate the usage of trust framework, we have also developed a separate trust based routing protocol. We have chosen the well-known wireless routing protocol; AODV.

trust-aodv

Transforming the traditional AODV protocol into a trust based version is implemented in this module. This is an example of how to use the trust framework and the advantages of using it. This implementation has not more focused on developing an optimal trust based routing protocol, but rather it is for the demonstration of the trust framework. Therefore, please feel free to improve it further.

This model was written as an example demonstration for transforming the
traditional AODV protocol into a trust-based AODV protocol which uses trust
to delegate packets within the network. It used trust framework(trust-routing) to access the ns-3 core modules.

trust-aodv has direct dependencies on trust-routing and aodv modules. Class
ns3::trustaodv::SimpleAodvTrustManager is the implementation to
ns3::trustrouting::TrustManager which defined in trust framework. This class includes the trust calculation logic and how the promiscuous callback function should react upon receiving intended packets to network nodes. It also holds trust parameter table which consists of ns3::trustaodv::AodvTrustEntry objects. trust parameter table is a different table to trust table. It contains parameters that can be considered when calculating the trust value. As we can see almost all the trust based routing protocols have different mechanisms to calculate the trust value. Therefore, this table is to manage such attributes for the trust value. Even though we have number of rreq, reply, error and hello counters, in our demonstration we have only used m_rreq and m_rrep.

There are 2 different types of aodv-protocol overriden files are available
under the model folder. ns3::maliciousaodv::RoutingProtocol and
ns3::selfishaodv::RoutingProtocol. These two protocol classes are used
to simulate a malicious node behavior in our provided example. Malicious AODV implementation is able to modify the number of hops which sends out in RREP message. It is done by simply reducing 1 from the available hops counts in a RREP packet. With regard to selfish node behaviors, it will randomly drop RREP packets without forwarding to the next hop.

For each of the above mentioned routing protocol overridden versions we have separate helper classes inside the helper folder. These helpers can be used in any simulation examples. Those have been used in trust-aodv-example simulation to install the intended overridden routing protocols.

10, 000 feet overview on trust-routing & trust-aodv

According to the above design now anyone can implement a new trust based module and plug it into the trust-routing framework to see how it works in a simulation.

trust-routing does have direct compile time dependencies on core and network modules. It is because the manager class that it holds actually inherited from ns3::Application. It helps to install the any concrete trust-manager as an application. (For e.g: SimpleAodvTrustManager)

Example:

If you run the example of trust-aodv-example.cc which is available in trust-aodv module, you can observe the utilization of trust values within the traditional AODV protocol.

We have configured a simulation network setup as shown above. It is available under src/trust-aodv/examples/. As you can see there are 7 nodes and one node which marked in blue color is the malicious node in the network. It manipulates the hops counts of RREP packets that receives to that node(10.0.0.6).

Simulation default configurations are set as 100s for the runtime. It has broken into 2 phases where 1st phase goes from 0–50 seconds. 2nd phase is from 60–70 seconds. 1st phase will send ping messages from one node to rest of the nodes in the network. It will iterate the same for all 7 nodes.

In 2nd phase we make a single ping message from node 0 to node 5. This is where the RREQ and RREP process take place again over the network.

We have observed both routing table and trust table at 55th second and 75th second respectively to cover both phases of the simulation. These table are all from node 0 in different moments in time.

after making a single ping request,

You can see that in trust table, trust value for node 7 (mac address of 04–04–0a:00:00:07) has reduced because of it’s RREP hop count change and random RREP packet drop behaviour.

As this is a pilot demonstration project, it is true that there are some scientific concerns with calculating the trust values based on the AODV control packets. But as we mentioned, this is to demonstration of usage for trust framework.

GitHub repository:

JudeNiroshan/ns-3-dev-git

This is a fork I took from the NS-3 mainline master branch. The release of the new trust framework is yet to be discussed in the community.

Experience:

Google summer of Code is a wonderful program which is hosted by Google. It’s a great honor to be a part of this program. I was so lucky enough that I could work on NS-3 which is really awesome! NS-3 is a reputed open source community among network researchers.

The project I worked on actually initiated with the concept I had. My mentor Tommaso helped me to point out that instead of implementing it as a concrete solution, make it as a framework so that other NS-3 developers will also get benefited out of it. He is the best mentor I’ve ever had.

This is my last time that I could participate in Google Summer of Code. I never worked on such a big C++ project ever and I learnt alot from this project. I also got the opportunity to interact with Tommaso and Tom which is the best part of this GSoC.

I know the framework is still lacking some of the major things. So I want to make it more reliable and people will use it to get their trust based protocols being implemented on NS-3

Overview.

Work still to be done.

Objectives.

• Incorporate JSR 919 mail capability into the OpenMRS Platform

• Add the ability for an administrator to configure the mail functionality via the REST API

• Add users.email to the users table within the Platform along with the ability to set and retrieve a user's email address via the REST API

• Add the ability for a temporary token to be generated for a user that, until it expires, can be used to reset their password. This should be able to be triggered by the user or an admin via the REST API.

• Add support for an email template to be used for password reset messages (should support localization).

• Add support for a REST API method that, given a  valid username and reset token along with a new password, will reset the user's password.

Resources.

Experience. 

Project : FHIR Swagger Codegen Integration and Strategic Improvements

Project Wiki : https://wiki.openmrs.org/display/projects/OpenMRS+FHIR+Module
Mentor :- Harsha Kumara
Backup Mentor :- Sanatt Abrol

Source Code Repository

• https://github.com/openmrs/openmrs-module-fhir

Project Description

The purpose of this project is to expand the capabilities and functions of the OpenMRS FHIR module. OpenMRS has recently undertaken a commitment to implement FHIR in order to ensure better interoperability between healthcare systems. The OpenMRS FHIR module was developed as part of these efforts. FHIR specification is continuously subjecting to several development iterations which improves the usability. Swagger also becoming more popular these days. Swagger provides client side library generation functionality which allows users to quickly build the clients for many languages.

Objectives

• Upgrading HAPI FHIR Library to it’s updated version
• Upgrading DSTU2 resources to DSTU3
• Swagger document generation improvements after library upgrade
• Integrate the swagger codegen library which allow users to generate client with selected languages
• Research on new FHIR resources which can support for OpenMRS
• Improve the test coverage

GSoC 2018 Contributions

1. Upgrade HAPI FHIR Library version

Issue : https://issues.openmrs.org/projects/FM/issues/FM-245

Pull Request : https://github.com/openmrs/openmrs-module-fhir/pull/155

2. Add Swagger SDK generation backend implementation

Issue : https://issues.openmrs.org/projects/FM/issues/FM-246

Pull Request : https://github.com/openmrs/openmrs-module-fhir/pull/156

3. Add Swagger SDK generation frontend implementation

Issue : https://issues.openmrs.org/projects/FM/issues/FM-247

Pull Request : https://github.com/openmrs/openmrs-module-fhir/pull/157

4. Add all language support and tests

Issue : https://issues.openmrs.org/projects/FM/issues/FM-246

Pull Request : https://github.com/openmrs/openmrs-module-fhir/pull/158

5. Add security definition section to swagger definition

Issue : https://issues.openmrs.org/projects/FM/issues/FM-250

Pull Request : https://github.com/openmrs/openmrs-module-fhir/pull/160

New Documentations

• https://wiki.openmrs.org/display/projects/Swagger+SDK+Generation

Blog

• https://medium.com/@amoh.eunice

Midterm Presentation

Pending Works

• Most of the target objectives are achieved as planned in the GSoC. Improving the test coverage is one of area that can further enhance.

Expereince

GSoC 2018 is my first contribution to an open source software. I gain massive experience and it is really an amazing. I got to know about how open source community build a open source project and the open source culture. In these past few months I have improved myself in programming skills, communication skills ans several other skills. I would like to thank my mentor Harsha Kumara and backup mentor Sanatt Abrol for their guidance and support. I would like to thank OpenMRS community for accepting me and helping me. Finally for Google for organizing the GSoC.

 Project : Merge Patient Data From Multiple Installations

Overview

Google Summer of Code final report

Project : Improved Built-in Reports Module

• Primary Mentor — Rafal Korytkowski
• Backup Mentor — Joseph Kaweesi
• Student — Jeyasumangala Rasanayagam

Introduction

The concept of the Built In Reports for OpenMRS Reference applications was initiated during the Google Summer of Code last year(2017) . The objectives achieved in Google summer of code 2017 were,

• Reach out to implementations to determine the most useful reports to include in the module
• Implement various reports using the Reporting module API
• Access those reports through Reporting REST API
• Create a new Basic Reports Open Web App UI
• Add charts to visualize data for some of the implemented reports

Now it is the time to extend the features and improve the usability of this project. We need to improve the existing view of the reports and to add more new reports to this module which are crucial for administrative decisions within a clinical environment. There are some new objectives mentioned in the project scope which are completed during this summer period.

The objectives of this project(Google Summer of Code 2018) are:

• Improve the existing Built In Report OWA issues and fix it to work properly (Headers, Breadcrumbs, and Routers)
• Implement a new view which shows a very detailed view of a patient.
• Add more information to improve the List of providers report. It should able to show the patients who worked with that providers also
• Add improvements to the List of diagnosis report. It should also able to show the patients who affected by the respected diagnosis
• Add improvements to the Number of Patient registrations.
• Add improvements to the Number of Admissions reports.
• Add improvements to the Number of Discharges reports.
• Add improvements to the Number of Transfers reports.
• Add improvements to the Number of Visits reports.
• Add improvements to the Number of Visit notes reports.

I spent time to analyze the existing reports in the Built In reports, and prepared some ideas to improve those reports with some more information. I have added some of those ideas into my project proposal, and I was able to figureout some more ideas during the actual development time.

I am very happy to say. I was able to complete about the 95% of the objectives during the Google Summer of Code — 12 weeks of time.

Demo presentation for the Mid term

This was demonstrated by me for the OpenMRS mid term presentations, and hosted in the You Tube. You can see some of the work which I have completed during the second evaluations in this video presentation.

Implementation

Fix the issues in the Built In Reports OWA to work properly

The existing OWA was implemented with some issues in the headers, breadcrumbs, and the routings. So I have added the following fixes to the OWA,

1. Added logout functionality through the OpenMRS REST services to the logout in the OWA.
2. Added redirection from the My Account label to the OpenMRS account page.
3. Added location switcher functionalities through the OpenMRS REST services to the OWA header. So users will able to switch the location through this OWA also.
4. Added fix to fetch the default active session information from the appui/session to show the active location.
5. Removed the hashRouter from the existing OWA, and replaced with the browserRouter to improve the routing functionalities.

Improvement to the List of Diagnosis report.

The List of Diagnosis report only shows the diagnosis name and the counts of the encounters in the view. So I was assigned to create, once a table row is being clicked, it should redirect to a new view which shows the patients who was recorded as this disease was affected. I have added following changes to this report,

1. Added more information to the List of Diagnosis report(included diagnosis id and Uuid) which wanted to track the respected diagnosis.
2. Added new report called “List of Patients for Diagnosis” which will show the patients who affected by the respected diagnosis.
3. Changed the module — ReportAsTableView component to support the row clicks and auto redirections to the respected pages. So any of the reports in this module can use this customized component for the row click and redirections.
4. Added redirections from the List of Patients for Diagnosis report to the patient dashboard. So the users can easily click on the patient name to go to the patient dashboard which will show more detail about the patient.

Improvements to the Number of Visits Report

The existing number of Visit reports was implemented to show only the total count of visits for the given date period. Actually this report did not contain the sufficient information to achieve the target of this module. So I decided to add more improvements as follows,

1. The report table is customized to show the total number of visits grouped by visit types against the total counts.
2. Location selector is added to this report. So the users can select the location to get the visits respected for that location.
3. Pi chart was added into the bottom of the report to illustrate the table view as the Graph view to the user.
4. Added Active visit switcher support to include the active visits or exclude the active visits into the report. So users can include the active visits which doesn’t have the end date up to the selected date to this report.
5. Fixed the end date selection problem to support up to the end of the current day

Improvement to the Number of visit notes

The number of visit notes report was implemented to show only the total number of visit notes for the given date period. It also not contains the sufficient information for a report. So I have added these following improvements to this report,

1. The report table is customized to show the total number of visit notes grouped by visit types against the total counts.
2. Location selector is added to this report. So the users can select the location to get the visit notes respected for that location.
3. Pi chart was added into the bottom of the report to illustrate the table view as the Graph view to the user.
4. Added Active visit switcher support to include the active visit notes or exclude the active visit notes into the report.

Improvement in the List of providers report

The List of Providers reports was implemented to show the table with Provider and the creation date to the users. It also does not contain the sufficient information for a report and I have decided to add these following new features to this report,

1. Added more fields to the Provider’s report such as Demographics(Family Name, Given Name), Provider Information and Role Name, and Uuid.
2. Added new report called “List of Patients worked with Provider” which can show the top 10 number of patients with their information who recently worked with that provider.
3. Added tabled row hyper links from the List Of provider to the List of Patients worked with Provider report. So users can simply click on the provider name to get the patient list who recently worked with that provider.
4. Added redirections from the List of Patients worked with Provider to the patient dashboard. So the users can easily click on the patient name to go to the patient dashboard which will show more detail about the patient.

Improvements in the Number of Admission report

The Number of Admissions report was implemented to show only the total count of the Admissions on that day. It is also doesn’t contain the sufficient information about the admissions. So I have added these following improvements to this report,

1. The report is restructured to show the total count of the admissions against the locations in the system. So users can able to get the admission’s count with the locations.
2. Added total count of the admissions to the bottom of the table.
3. Pi chart was added into the bottom of the report to illustrate the table view as the Graph view to the user.

Improvement in the Number of Discharges report

The Number of Discharges report was implemented to show only the total count of the Discharges on that day. It is also doesn’t contain the sufficient information about the discharges. So I have added these following improvements to this report,

1. The report is restructured to show the total count of the discharges against the locations in the system. So users can able to get the discharge count with the locations.
2. Added total count of the discharges to the bottom of the table.
3. Pi chart was added into the bottom of the report to illustrate the table view as the Graph view to the user.

Improvement in the Number of Transfers report

The Number of Transfers report was implemented to show only the total count of the Transfers on that day. It is also doesn’t contain the sufficient information about the transfers. So I have added these following improvements to this report,

1. The report is restructured to show the total count of the transfers against the locations in the system. So users can able to get the transfer’s count with the locations.
2. Added total count of the discharges to the bottom of the table.
3. Pi chart was added into the bottom of the report to illustrate the table view as the Graph view to the user.

OpenMRS JIRA Tickets Information

I wanted to work on the two projects which are interconnected to produce the reports. Those are,

1. ReferenceMetaData Module — The report generation module in the OpenMRS back end based on Java.
2. Build In Reports Module — The customized view of the reports based on the React

I have created these following tickets and worked during this project time. All of these tickets are completed by now and the next release is planned to soon after this week. You can find the JIRA project for this module here.

1. BIR-1 — Improve the Diagnosis Report in the Built-in-Reports module
   Pull Request : #2
2. BIR-2 — Change the ReportAsTableclass to support the hyper link for required reports. Built-in-reports module uses the react-data-grid to show the reports as the tables.All reports use a common table class called as ReportAsTable. So it is modified to support with hyper links for some required reports.
   Pull Request : #1
3. BIR-3 — Browser router failed to redirect while refreshing the pages.
   (Built-in-reports module uses Browser Router for the routing. It’s fail while refreshing the web page or pressing back button in the browser. It should be fixed with Hash Router to resolve this issue while we are using the React Router V4.
   Pull Request : #3
4. BIR — 4 -Added More Improvements to the Number of Admissions report.
   Pull Request : #8
5. BIR-5 — Change the view of New patient Registrations view and Number of patient registrations bar chart.
   Pull Request : #5
6. BIR-7 — Add Number of Discharges for all Locations Reports to the Module.
   Pull Request : #12
7. BIR — 8 — Add Number of Transfers Report for all Locations to the Module.
   Pull Request : #13
8. BIR — 9 — Improve Number of Visits with visit type for given location and date report.
   Pull Request : #9
9. BIR — 10 — Improve Number of Visit Notes with visit type for given location and date report
   Pull Request: #10
10. BIR-11 — Improve the List of Providers Report in the Built-in-Reports module.
    ( Once the user clicks on a row in the table of List of Providers report, user should be able to see more detailed page about the provider.)
    Pull Request: #11
11. BIR-13 — Need to add location switcher to the buildin reports OWA header
    Pull Request : #commit
12. RA-1499 — Create Patients affected by Diagnosis report for given Diagnosis ID. It display the information about patients affected by given diagnosis UUID.
    Pull Request : #30
13. RA-1500 — Remove the duplicate data from the List of New Patient Registrations
    (List of New Patient Registrations report shows some duplicate rows in the table view. The SQL query which is used to fetch the data from the database should be attached with grouping query to avoid this issue.)
    Pull Request : #31
14. RA-1501 — Create Number of Registrations for all locations Report.
    Pull Request : #32
15. RA-1505 — Create Number of Discharges for all locations Report.
    Pull Request : #33
16. RA-1506 — Create Number of Transfers for all locations Report.
    Pull Request : #34
17. RA-1508 — Create Number of Visits with visit type for given location and date report.
    Pull Request : #35
18. RA-1509 — Improve Number of Visit Notes with visit type for given location and date report.
    Pull Request : #36
19. RA-1514 — Create List of Patients Report who worked with given Provider.
    ( Create a new report to display the information about the patients who worked with the given provider. It should contain these information)
    Pull Request : #37

Release — Version 1.0.0

The last recent release of the Built-In report module was 0.94 which was considered as the unstable distribution of the module under the development. So we have decided to release the v1.0.0 of the Built-In reports module after the improvements during the GSoC 2018 period.

Now is the time to release the v1.0.0. So I have discussed with my mentors and decided to release on time. The beta version of this release can be found here.

Discussions

OpenMRS Talk discussions

I have used the OpenMRS talk thread to discuss about the project, implementation plans, and updates. Sp you can get more information about the project process and work flow through this talk thread,

GSoC 2018 - Improved built-in reports project

Weekly Blog posts

The following are my weekly blogs regarding my project progress. You can get it on medium.

• Week 1 — GSoC 2018 : Introduction to Built-in Reports module — week 1 [May 14,2018 — May 2
• Week 2 — GSoC 2018 : Introduction to Built-in Reports module — week 2[May 21,2018 — May 27, 2018]
• Week 3- Applying Hash History in Built-in Reports Module.
• Week 4- GSoC 2018 : Week 4 [ June 4, 2018 — June 10, 2018]
• Week 5- GSoC 2018 : Week 5[ June 11, 2018 — June 17, 2018]
• Week 6- Adding More details to Transfers and Discharges reports
• Week 7- Improvements to the Number of Visits Report
• Week 8- Improvements to the Number of Visit Notes
• Week 9- Second Evaluations
• Week 10- GSoC 2018: Week 10[July 16, 2018 — July 22, 2018]
• Week 11- GSoC 2018: Week 11[July 23, 2018 — July 29, 2018]

Experience

Yes!, This is the first time for getting involved into the Google Summer of Code project. I was able to learn much from this amazing program and I was able to improve my potential about the industries. I have worked on React, Java, REST Services, HTML, and CSS for this projects. The learned techniques and the experience are very very helpful for my future.

I feel very excited and I am happy that I was able to travel through the last 3 months without any major issues. Yahh!! I successfully completed my tasks and the major part of the project. My mentor Rafal Korytkowski gave me the feedbacks and reviews quickly and help me to clear my issues regarding this project and other community members in the OpenMRS helped me from the beginning of the GSoC and they helped a lot to complete this project.

I wish thank to all for their wonderful helps and time, specially thanks to my mentor Rafal Korytkowski who gave me this great opportunity and for his guidance and the support and I wish to say a special thanks to Suthagar Kailayapathy who gave me the support and encourage me to achieve this goal for this Project.

In this week i mainly focus on the mock testing with Mokito for Attachment Resource DoSearch() method. I finish the implementation of the do Search method with some modifications such as create separate context independent search method inside the AttachmentResource which will help to fetch the Attachments using AttachmentService based on the given Parameters. And also this Search method was created for help the mock testing implementation since it is context independent.

So Basically inside the Mock Test class, it test the newly added Search method with the different scenarios ( By changing the parameters ) and verify that relevant methods in the AttachmentService is triggered.Since we already developed the unit test for each method in the AttachmentService , we avoided testing the accuracy of the search method again by using Attachments. We just verify that relevant methods in the AttachmentService will triggered when we call the Search method with different parameters. All the new modifications are send to the mentor for review and wait for his feedbacks.

GSoC is ending during this week. I have worked on testing the module and the documentation. I have added project documentation in https://wiki.openmrs.org/display/projects/Swagger+SDK+Generation. I’ll add a detail post soon with final progress update.

Work done

Challenges Encountered

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

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

• [LBAC-14] Add restrictions to the PersonService methods to restrict them by the locations - OpenMRS Issues
• [LBAC-15] Add restrictions to the UserService methods to restrict them by the location - OpenMRS Issues
• [LBAC-16] Failed to restrict the encounters of the patients from other locations - OpenMRS Issues

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.

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.

[RCM-109] Need to add patient verification to return Cohorts objects for the serviceMethods - OpenMRS Issues

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.

Objectives

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 … :-)

Finally I am done with OWA. Feels great to tell you all that now I am done with most of my coding work! Some testing is pending, which i will be doing in this week. Except that, I am now looking forward to get all the documentation of the project ready. Also I will be now working on my final presentation.

Wish me luck for the final evaluation and see you all next week!

Cheers!

Week 12.

Rest webservice.

12th week of Coding

In this week I developed muzima Android app to display patient reports. I had to try out different methods this week. here is a brief description of how I approached my task.

I used the functions of muzima api to call the server. Those middle-ware was developed by muzima developers, so my work was easier 😆! The muzima api calls the server asynchronously, so I had to wait until the report is fetched to muzima app. So I created a background process which listens for the message

When the download is complete I receive the message and then displays the report to the user.

The above code snippet shows how the view is loaded when the message is received. I am hoping to complete the functionality in the coming week 😯!

In this week i did some Modifications to the ATT-24 issue. We mistakenly used includeRetired for includeVoided parameter in the java API implementation. So all the occurrences of includeRetired are modified to the includeVoided.

And I started to research on mock testing for Attachment resource for test the search() method. Because After discussion with my mentor he decided to go for mock Testing which can be used to implement test cases without any dependency.Some existing implementation can be found here ( In Bahmni-core module ). And I did some modifications to the ATT-27 issue and able to close the issue.

Week 11 [July 24, 2018 — July 30, 2018]

Yes, now the time to say Goodbye to the location selector from the OpenMRS Login screen. Just log in with your login credentials such as username and password only!

The actual OpenMRS login page contains the location selector with the login credentials section to assign the users to the location during the login. So the user can select any location from the location selector to enter the OpenMRS. The location will be stored in the session and will be used in the further activities.

Now, I have added the solution to assign the users for a location through the location user property. So the user will have a location property, and it will be automatically fetched from the user property during each login. It will be assigned as the user login location into the session also.

This feature will be executed in these following ways,

• When the user requests the login page, it doesn’t contain the location selector.
• When the user enters the login credentials, then it will check for the location user property
• If the user has the location user property, then the login location will be fetched from that value.
• If the user hasn’t the location user property, then the login page will be redirected to the usual login screen to select the location property again.

If the implementers want to remove this feature form their implementations to have the usual login screen, just need to delete the global property named as “referenceapplication.locationUserPropertyName” form their systems.

So the end would be,

OpenMRS can remember your location now !

During the last week, I finished the below-mentioned objective and send the PR for the review.

1. BIR-8 — Added total number of transfers for all locations reports. This PR contains these improvements for Number of Transfers report,

• Removed the location selector from the report
• Added Total Count to the bottom of the table

2. BIR-7- Added total number of Discharges for all locations reports. This PR contains these improvements for Number of Discharges report,

• Removed the location selector from the report
• Added Total Count to the bottom of the table

And, According to my project, I completed the following tasks up to now.

1. OpenMRS header has to work properly(changing the unit, should reflect the changes in the reports, log out function should work properly, clicking on the OpenMRS logo should navigate to the OpenMRS home page)
2. In the List of Diagnosis report, once a table row is being clicked, it should redirect to a new view which shows the patients who were recorded as this disease was affected. It should also display the severity of this disease spread within the clinical environment. Compared to the other disease numbers.
3. New patient Registrations view and Number of patient registrations view , bar chart should have the flexibility to change the view, Like, see by dates, by weeks, by months etc.
4. Number of Admissions/Discharges/Transfers views should have to change in way to provide more information to the user(come up with your own ideas to visualize data)
5. Number of visit notes/ number of visits views should have to change in a way to provide more information to the user(come up with your own ideas to visualize data)
6. And I just finished the following task, In List of Providers, once the user clicks on a row in the table, user should be able to see more detailed page about the provider. (Who created this provider? Which unit this provider is being assigned to work? Top 10 patients who was recently worked with this provider.)

I have not started the following task, Implement a new view which shows a very detailed view of a given patient. Similar to patient dashboard, but more analytical information such as past recorded diseases, visits, etc.(use graphs in more meaningful ways).

I would like to start the following task in the upcoming week, “Implement a new view which shows a very detailed view of a given patient. Similar to patient dashboard, but more analytical information such as past recorded diseases, visits, etc.”

• BIR-8 Added total number of transfers for all Locations Reports by sumangala028 · Pull Request #13 · openmrs/openmrs-owa-builtinreports
• BIR-7 Added total number of Discharges for all Locations Reports by sumangala028 · Pull Request #12 · openmrs/openmrs-owa-builtinreports

Work done this week.

Hello World! The intern has almost come to an end and this was the most productive week until now. To start with I made a note of what kind of test cases I would be writing for the controllers, later on I wrote stub for a few controllers and tried to use mockito on a sample code. I have planned to finish all the test by this friday and then finally write the documentation over the weekend. Finally later on in the week I added some required error handling in some controllers which would otherwise hamper the user experience with the endpoints. Thats all for the update. Thanks for reading.

GSoC with OpenMRS week 11 was originally published in piyush.kundnani on Medium, where people are continuing the conversation by highlighting and responding to this story.

This week, I revisited my feature and added test case for enhancement that I made in the last week. Since next week is the last week, I’m continue to test the feature and looking for possible improvements that I can make to my feature.

Below is get patients by id operation generated automatically by the swagger SDK generator.

/**
 * Build call for patientIdGet
 * @param id Id of the  Patient resource (required)
 * @param progressListener Progress listener
 * @param progressRequestListener Progress request listener
 * @return Call to execute
 * @throws ApiException If fail to serialize the request body object
 */
public com.squareup.okhttp.Call patientIdGetCall(String id, final ProgressResponseBody.ProgressListener progressListener, final ProgressRequestBody.ProgressRequestListener progressRequestListener) throws ApiException {
 Object localVarPostBody = null;

// create path and map variables
 String localVarPath = "/Patient/{id}"
  .replaceAll("\\{" + "id" + "\\}", apiClient.escapeString(id.toString()));

List < Pair > localVarQueryParams = new ArrayList < Pair > ();
 List < Pair > localVarCollectionQueryParams = new ArrayList < Pair > ();

Map < String, String > localVarHeaderParams = new HashMap < String, String > ();

Map < String, Object > localVarFormParams = new HashMap < String, Object > ();

final String[] localVarAccepts = {
  "application/json",
  "application/xml",
  "application/fhir+xml",
  "application/fhir+json"
 };
 final String localVarAccept = apiClient.selectHeaderAccept(localVarAccepts);
 if (localVarAccept != null) localVarHeaderParams.put("Accept", localVarAccept);

final String[] localVarContentTypes = {
  "application/xml",
  "application/json"
 };
 final String localVarContentType = apiClient.selectHeaderContentType(localVarContentTypes);
 localVarHeaderParams.put("Content-Type", localVarContentType);

if (progressListener != null) {
  apiClient.getHttpClient().networkInterceptors().add(new com.squareup.okhttp.Interceptor() {
   @Override
   public com.squareup.okhttp.Response intercept(com.squareup.okhttp.Interceptor.Chain chain) throws IOException {
    com.squareup.okhttp.Response originalResponse = chain.proceed(chain.request());
    return originalResponse.newBuilder()
     .body(new ProgressResponseBody(originalResponse.body(), progressListener))
     .build();
   }
  });
 }

String[] localVarAuthNames = new String[] {};
 return apiClient.buildCall(localVarPath, "GET", localVarQueryParams, localVarCollectionQueryParams, localVarPostBody, localVarHeaderParams, localVarFormParams, localVarAuthNames, progressRequestListener);
}

Gsoc Week 11,

Extra curricular activities.

To do activities.

11th week of Coding

The GSoC 2018 was reaching its end, so I had to steam in to finish on time 😅. In this week I engaged in displaying the data(MuzimaGeneratedReport) that is fetched from the server.

I first tried to create a view containing a list of the reports of a particular patient. I followed the procedure to create a list as you normally follow in Android.

I created a layout file named report_list_view and created a list as follows.

Then I created an Android Activity named PatientReportListViewActivity and used the following code 😆

As at this moment I was unable to bring patient reports from the server, I created a list of dummy values for now 😅. When a user selects a report name, the report should be loaded. The report is a HTML page. So I am going to load the report using WebView in Android as follows

The PatientReportWebActivity that is triggered on item click takes the user to the WebView where report is displayed.

This was successful 😆. But in muzima-android there is a preferred way to create this work-flow. In the next week I will be doing this in that way. This was just to get my head in 😅. See you next week with more!

The pre final week of GSoC 2018 was a little hectic for me. Placements season is started in our college and thus I had to study for the same. Also I studied about OWA development and discussed with Sanatt about the design and implementation of the OWA. I also did some research on how we can migrate to Spring Security OAuth2 Version 2.x . Although I did worked less this week but I hope I will cover that up in the coming week. Once I get sorted with these two tasks, I would then write tests for the controllers in the coming week.

The final week is here and I hope to finish well!

Happy coding!

10th week of Coding

This week was also a successful week as I completed the job of finalizing the end points in muzimacore module. This endpoint would be used by the muzima android app to download patient reports.

First I had to add a change to the existing database because the design team had requested to add a new field priority to muzima_generated_report. This attribute was set as a tiny_int and the default value was set to 0. So if the user wants to create a report_cohort_config with high priority priority the check box in the following diagram should be ticked, so that priority column in the SQL table is set to one.

Then I worked on the REST endpoint which returns the last patient report created due to a cohort report mapping set to high priority 😃. The endpoint requires the uuid of the patient as the only parameter.

I am hoping to get these reports into muzima android app in the coming weeks 😯.

This week was mostly about continue the implementation of the Bahmni atom feed reader microservice. Currently, it polls the patients’ atom feed and triggers when a new event occurs.

Next week I’ll be working on a webhook to display notifications on the frontend of the application. This works as follows

• Microservice reads a new event and call the relevant endpoint at Bahmni backend (this is a POST call with all event related information)
• Backend triggers the webhook. If webhook is successfully triggered notification is displayed to the user. Otherwise, the event is stored in the DB while the user becomes active.

You can find the current implementation of the microservice here.

In this week I did some modifications in ATT-27 after review of my mentor. I modify separate test cases for upload method ( Attachment upload ) to test attachment upload with encounter , visit and without any encounter or visit.

And most importantly i created my mid term presentation which described the progress of my works in GSOC program. And i continue my research on OWA modification. And I started to implement the doSearch method in Attachment resource which will help to fetch the attachments from the rest services. It fetch the the data using Attachment Java API and user able to fetch ( search) Attachments based on the several parameters such as Patient, encounter , visit etc. And also user will able to fetch the encounter less attachment using rest services.

Week 10[ July 17, 2018 — July 23, 2018]

Assigning the Location to the patient almost done and it’s working as expected. So as the next milestone, I have started to work on assigning the location to the users during the registration process.

Users can be registered from the Manage Accounts page in the OpenMRS Administration page. So there should be a location selector to assign the locations during the registration. Since the location based access control is a separate module from others, I can’t make any direct changes in the Register New User dashboard. So we decided to add the custom fragment support to the Manage Accounts — User management dashboard (in the AdminUI module)which needs to allow the custom fragments to customize the user registration dashboard.

• It should allow the custom fragments with Id as “createUser.manageAccountPersonFragments”, and it should be added to the person sections.

• It should allow the custom fragments with fragment Id as “createUser.manageAccountUserFragments”, and it should be added to the user sections.

Addition to this, the Manage Account dashboard should support the custom view fragments to view this information into the respected dashboard and it should allow editing the properties through the usual ways.

So I have added implementation in Manage Accounts to support the Add/Edit custom fragments and support to the custom view fragments.

Here,

• The person information from the custom fragments will be saved automatically if the type is person attribute. If the custom fragment contains some other different metadata type, then it should handle the save and update actions itself.
• The user information from the custom fragments will be saved automatically if the type is user property. If the custom fragment contains some other different metadata type, then it should handle the save and update actions itself.

These are the tickets which contain the works related to this part,

• [RA-1513] Add new account/Edit account dashboards should allow the extensions to add the custom fragments to the dashboard - OpenMRS Issues
• [LBAC-2] Assign users to the locations on registration - OpenMRS Issues

See you in the next week..!

This past week I researched on how the configuration can be migrated from the current xml-based configuration to java annotation-based. After much of study and efforts in doing this me and Sanatt came to conclusion that it is better to keep the configuration xml-based only for the sake of simplicity. Also wherever required the configuration is done using annotations.

At the end of the week I started my work on OWA which supports the SMART functionality in the reference application. I took the help from Suthagar on getting started with the OWA generator. This week I aim at building an OWA which would do the job. Also I am planning to write tests for the controllers.

That’s all for this week!

See y’all next week.

During the 9th work I started working on the objective “List of Providers, once the user clicks on a row in the table, user should be able to see more detailed page about the provider”. I finished this task on the 10th week of the GSoC 2018.

RA-1514 , BIR-11 — This PR contains the implementation for the Patients who worked with Providers report for given Provider id, Provider Information and top 10 patient information who was recently worked with this provider.

These are the features added in the above mentioned objective.

1. Provider Information in the header (Full name, role, and when created)
2. Top 10 patient information who was recently worked with this provider
3. Link to the patient dashboard from the patient list (Just need to click the row to goto the patient dashboard)
4. Usual bar chart in the bottom of the report (Count of patients vs date)

Following images shows the improvement,

And, According to my mentor’s suggestion on my mid term presentation, I worked on the number of admission report and made few changes. The changes are :

• Removed the location selector from the report
• Added Total Count to the bottom of the table.

Following images show the above mentioned changes in the Number of Admission report.

• BIR-4 Added More Improvements to the Number of Admissions report by sumangala028 · Pull Request #8 · openmrs/openmrs-owa-builtinreports
• RA-1514 Created List of Patients Reprot who worked with given Provider by sumangala028 · Pull Request #37 · openmrs/openmrs-module-referencemetadata
• BIR-11 Added Improvements the List of Providers Report in the Built-in-Reports module by sumangala028 · Pull Request #11 · openmrs/openmrs-owa-builtinreports

Work done this week.

Challenges Encountered.

Handling database Table Ids for Merged Data 😕 

Proposed Solution

Time flew so fast as GSoC is coming to a end after two weeks. I have added my GSoC midterm presentation to youtube. If you interested please watch following video.

During this week I have made an improvement to FHIR module. Swagger definition of FHIR module doesn’t contain security definitions section. This is an issue when Swagger SDK generation. Because basic authentication scheme isn’t present, client can’t invoke with basic authentication headers. I have added the fix in https://github.com/openmrs/openmrs-module-fhir/pull/160.

Then I add demo client which uses generated Java SDK in https://github.com/eunice18/demo-sdk-client. Here is very small piece of code to get patient by id.

package org.openmrs.demo.client;

import io.swagger.client.ApiClient;
import io.swagger.client.ApiException;
import io.swagger.client.api.DefaultApi;
import io.swagger.client.model.Patient;

public class DemoClient {
    public static void main(String[] args) {
        DefaultApi apiInstance = new DefaultApi();
        String id = "892b89a2-6823-403b-899c-d7045c0d9b5e"; // String | The ID of the resource
        try {
            ApiClient apiClient = apiInstance.getApiClient();
            apiClient.setUsername("admin");
            apiClient.setPassword("Admin123");
            apiClient.addDefaultHeader("Authorization", "Basic YWRtaW46QWRtaW4xMjM=");
            apiClient.addDefaultHeader("Accept-Encoding", "*/*");
            apiClient.setBasePath("http://localhost:8080/openmrs/ws/fhir");
            Patient result = apiInstance.patientIdGet(id);
            System.out.println(result.toString());
        } catch (ApiException e) {
            System.err.println("Exception when calling DefaultApi#allergyIntoleranceGet");
            e.printStackTrace();
        }
    }
}

I’m currently working on improvements to this feature.

GSoC 2018: Week 9[July 9, 2018 — July 15, 2018]

Last week was our second evaluation period of the Google Summer of Code 2018. We need to submit the video presentation about our project and it’s information and demonstration in order to pass the second evaluation. I attach my video presentation here,

And I I have already started to work on the following task, List of Providers, once the user clicks on a row in the table, user should be able to see more detailed page about the provider. (Who created this provider? Which unit this provider is being assigned to work? Top 10 patients who was recently worked with this provider.)

This is similar to the Diagnosis report improvements which I done at very first time. So I thought to follow those conventions and elements to improve the List of Providers report also. These are the new elements which will be added into this report,

1. Provider Information in the header
2. Which unit this provider is being assigned to work
3. Top 10 patient information who was recently worked with this provider
4. Usual bar chart in the bottom of the report (Count of patients vs date)

This past week, I completed and passed my second evaluations. We all were needed to submit a presentation to OpenMRS community. I completed both the evaluations and presentation on time. Now the remaining major tasks in the final phase are migration from xml based configuration to annotation based configuration, testing the untested code. Also we are planning to migrate to Spring Security OAuth2 2.x release. As a bonus deliverable, we are planning to build an OWA which will facilitate the functionality of SMART apps to the latest OpenMRS Reference Application. I have started to plan things out and will start working on these in the coming week.

That’s all for now! Happy coding!

Work Done this week

Challenges Encountered

In this week also i worked with the ATT-27 issue which is modify the Attachment REST end point for file upload to Allow the upload attachments based on the specific encounter. And i do some modifictions to the current implementation and add exception handling inside the upload method.

Since my mentor was busy in last week, i was not able to start a new work ( waiting for his review for my previous work). But i dis some research about OWA ( Open Web App ). Because my next task is to Segerate attachment UI to an OWA. Challenges of this task is that integrate OWA to open MRS main dashborad since attachment module need to be displayed in two places in the Open MRS dashboard. ( Clinician Facing Patient Dashboard and on the Visits & Encounters Patient Dashboard)

Week 9 [ July 10, 2018 — July 16, 2018]

According to the Google Summer of Code 2018, Last week was the second evaluations period. So we all need to complete that evaluation within the end of that week to pass the Google Summer of Code program.

Along with the OpenMRS, I need to prepare a Video Presentation which carries the project information and demonstrations of my project. Have a look at my video presentations to get an abstract view of my GSoC project :-)

Project Implementation

Last week, I faced an issue with the Daemon threads in OpenMRS. There are few Daemon threads which are working in the background to carry some workloads of the OpenMRS and those are doing some works like,

1. Manage the schedule works and perform the actions
2. Clean the reports from the instance memory
3. Collect the patient view information and recent encounters

Since the Daemon thread is common for the whole system, OpenMRS defined a Daemon thread user who can work like an actual user to get approval from the OpenMRS access controls. But the Daemon thread user was fixed to create with a given user UUID.

So when the location based access control module tried to catch those requests from the Daemon thread user, it can’t identify the location information for the user. So it blocked the response and send the null response instead of the actual response. So the daemon thread component failed to collect the recent patient view information and the recent encounters.

After some discussions with my mentor Daniel and backup mentor Wyclif, we have decided to skip the location restrictions for the Daemon thread user. So I have added the fixes for those issues and completed that work. Please refer this discussion if you need more information,

Could not fetch the UserContext for a getPatientByUuid() Call from EMRAPI module

View the location information in the patient dashboard

Then I have worked to add the location information to the patient dashboard. The users without administrator privilege couldn’t access the patients from other locations. So they can identify the patient location from the OpenMRS header. But the System Administrator can handle the patients from all locations. So he need the location information for the patients in the Patient dashboard. The final view will be like this,

And then, I have worked on these followin tickets as well,

• [LBAC-12] Indicate the patient location information in the patient dashboard - OpenMRS Issues
• [LBAC-11] Allow system administrator to access all the patients in the system - OpenMRS Issues
• [LBAC-10] Failed to get the location property from the Daemon thread user - OpenMRS Issues

We had the 2nd evaluation this week. By the end of this week I was able to complete the first phase of the project which was to develop subscriptions management module which allows the user to create, modify & delete subscriptions made by the user.

In addition to that I was able to implement a module to read Bahmni atom feed. In the upcoming week I will integerate Java Spark microservice framework with the module so that it can be run as a service which expose endpoints to register and trigger subscriptions.

9th week of Coding

The 9th week of the program was really important as the 2nd evaluation was scheduled. I engaged in improving the scheduled task in muzimacore module which creates summary reports for each patient in a cohort.

I installed reporting compatibility module so that cohorts could be built. Next I had to add a concept dictionary so that I could add Obs for a patient.

Once a report configuration is created by the user(i.e-mapping a cohort with report definition) the scheduled task of creating patient reports take over.

Introduction to the Report Generation Task

1. The process is started everyday at 00:00 hrs, and it first gets all the report configurations from the database and loops through each one of them.
2. It loops through each patient belonging to the cohort of the report configuration.
3. The task then checks for any in-completed reports belonging to that particular patient in the generated reports table. If any are found, the report is generated and saved as a “completed” report(setting the status column to “complete”)
4. The task next checks for new Obs for that patient since 00:00 hrs last day and generates a new report only if any are added.
5. If no previous reports of that patient are found, the task creates a new report (This would happen for the very first run of the task).

Currently I am engaging in testing the scheduled task. I hope to configure the muzima android app so it could consume these reports and render it to the mobile user 😃.

Hello World! This has been a rather interesting week. Happy to let you know that I passed the second evaluation thanks to my mentor. I was lacking behind schedule since I just joined as a full time employee at a company which hardly left me with any time. But thankfully I discussed this issue with my mentor and we were able to trim down some not very important requirements from the project. With whatever time i could spare, I first read a little about testing on the openmrs wiki. Later had a look at the existing test classes used in other openmrs modules. I also finally manually tested the controllers to verify that they were working as expected. Thats all for the update. Thanks for reading.

GSoC with OpenMRS Week 9 was originally published in piyush.kundnani on Medium, where people are continuing the conversation by highlighting and responding to this story.

After the second evaluations, my next target is now implementing the demo client which use generated SDK to invoke the OpenMRS FHIR APIs. I have gone through the code of the generated SDK for Java and understand the APIs which required to be called from the demo client. Now I’m going to start a sample project which wraps the SDK to write the client.

Above diagram shows the interconnections between the components when writing the demo client. I’m planning to complete the demo client by next week.

Mid Term Evaluation

Evaluation.

Success Message

8th week of Coding

The start of this week was a landmark of my project, because I had to complete development in the muzima core module and then move to the development in muzima android app.

I tried to complete the scheduled task to generate reports for patients with in this week. But I ran into a dead end when rendering the output for each report request. The report generation is implemented as an asynchronous task in the reporting module. So waiting until the task report is generated was a problem.

The generated patient reports by the muzima core module should then be displayed in the muzima mobile app. In the muzima app I first tried to add the following interface changes.

I must thank in heaps to my mentor Samuel Mbuga and Bernard Mokaya who helped a lot to begin working in the muzima app.

GSoC 2018: Week 8[ July 3, 2018 — July 8, 2018]

During the last week, I completed the following tickets.

1. RA-1508, BIR-9 — Create and Improve Number of Visits with visit type for given location and date report. It is improved with some features.

• Users should able to get the visit report for all locations or a given location.
• Bar chart should be added into the bottom of the report as usual.
• Add support to include the active visits into the report
• Total Number of visits grouped by visit types.

And I worked on the task “ Number of visits notes views should have to changed in way to provide more information to the user.”

1. RA-1509, BIR-10 — Create and improve Number of Visit Notes with visit type for given location and date report. I added some improvements for the visit notes report.

• User can get the total Number of visit notes grouped by visit types.
• Users should able to get the visit notes report for all locations or a given location.
• Bar chart added into the bottom of the report as usual.
• Users can include and exclude the active visits in the visit notes report
• Changed the end Date selection to support current day end. So users can get the reports up to current day end including active visits

• RA-1509 Improved Number of Visit Notes report by sumangala028 · Pull Request #36 · openmrs/openmrs-module-referencemetadata
• BIR-10 Added improvements to the Visit Notes report by sumangala028 · Pull Request #10 · openmrs/openmrs-owa-builtinreports

Check in with another report!.

Week 8 [Jul 03, 2018 — July 09, 2018]

I have successfully completed the following tasks and the pull requests were merged with the main repository.

1. LBAC-4 : Create basic module structure for the project
2. LBAC-3 : Assign patients to locations on registration

And started to work on LBAC-5 : Allow to edit the patient’s locations through the patient dashboard. The user can assign the locations to the patient through the patient registration dashboard. Since there is no way to edit the patient location directly. So we decided to provide an action method which can be triggered from the patient dashboard to edit the patient location.

There will be a link called “Edit Patient Location”, listed in the General Actions section in the patient dashboard. The user can click that link to edit the patient location attribute. When he enters to the edit location section,

• The existing location value will be selected by default if the patient already contains a location attribute
• The session location will be selected by default if the patient doesn’t contain a location attribute.

The edit location section will be useful for these reasons,

1. To switch the patient location from one location to another location
2. To assign the patient location for the existing patients

You can follow this talk forum to get more discussions about this section since I faced some issues while working on this sample.

How to create a fragment which can support to edit from Patient Dashboard?

After this ticket, I started to work on these following tickets,

1. LBAC-7 : Select the session location as default to the fragment location selector.
2. LBAC-8 : Failed to filer the patients who listed in the findPatients page before searching.

So here comes the good news, I am successfully able to run SMART apps from SMART apps gallery. After some bug fixes and code changes, now the module is properly able to run SMART apps from SMART gallery. Me and Sanatt thought of  successfully migrating the module to Spring Security OAuth2 2.x version before the second evaluations but for now we have postponed the plan. I am now ready for my second evaluations and I will be now preparing a presentation for the OpenMRS community regarding the work I have done, so far, on the module. Also I am aiming now at making configuration changes and writing tests for the code. Then looking forward to give time to Bonus deliverables.

Wish me luck for the second evaluations and see you all next week!

This week I involved in completing all frontend and backend operations related to the subscription management. In addition to adding new subscriptions, users can modify existing subscriptions as well.

Following are the UIs implemented related to subscription management.

At the 3rd phase(final phase) of the project, I will be implementing a microservice to read the atom feed and trigger in-app notifications.

In this week i worked with the ATT-27 issue which is modify the Attachment REST end point for file upload to Allow the upload attachments based on the specific encounter.Main tasks of this ticket is

1. ensure that it would be possible to specify an encounter parameter to choose which encounter to hook the attachment to.

2. If both the visit and encounter parameter are provided together then an IllegalRequestExceptionshould be thrown if the encounter does not belong to the visit.

And i created a required unit test for test the modified attachment REST end point.

GSoC 2018 : Week 6 [ June 18, 2018 — June 24, 2018]

Last week I finished some PR,

1. Create number of discharges for all locations report. (RA — 1505)
2. Create Number of transfers for all locations report. (RA-1506)
3. Adding number of Discharges for all locations report. This contain the implementation for number of discharges.
4. Adding Number of Transfers for all locations report.

At the begin of the week, I tested my Previous implementation “Search by Error Registration by Error type” on OpenMRS version 1.11.5. So I just step up my testing environment with OpenMRS core version 1.11.5 on my machine with my mentor help. After doing that I just configured Muzima core module with muzima forms, in that configurations, I had face unable to upload Muzima forms due to some bug on the current module. Finally, I upload a form with the guide of my mentor. I just note down what are the steps I did for the setup testing/development environment, I think it would help to the new developers who are the developers engaged with muzima core development in the future.

After setting up the environment I tested my implementation for my mentor’s DB dump. As my mentor said there was duplication in my implementation. So I tried hard to fixed this issue. And make some changes as the guide my mentor. Even that not fixed, So I just move my next ticket.

My next implementation is “Adding button for the Error Registrations as Direct to the Merge UI” from this implementation user can move from error UI into merge UI for merging conflicted patient registration or create another new patient registration. This merge button if Patient Error registration error occurred by merge conflicted. Otherwise, there is no merge button on the error UI. It will prevent confused user when it appearing for other data. When I implementing those feature  I used Angularjs technology as my mentor advice. When starting work with Angularjs, It little bit hard to work on it, because this is the first time I work with Angularjs. However, Angularjs has several inbuilt advantages. When the registration error happened by a patient with similar characteristics user can see the merge button as shown on the figure.

After finishing that implementation, I start my implementation on another ticket which is Initial Patient Merge UI. Next week I’ll work on this issue. There are three major implementations,

• Retrieve Successfully Registered Patient registration from OpenMRS table (by considering merge conflict error).
• Data shows on two different UI.
• Adding functionality for UI.

Pull request for “Adding button for the Error Registrations as Direct to the Merge UI“, https://github.com/muzima/openmrs-module-muzimacore/pull/34

Work done this week