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:
A doctor requests lab tests for patients and wants to be notified as soon as the results are ready (or perhaps only if there are abnormal results) A doctor wants to know if one of their patients is revisiting the facility (to provide follow-up care, because the patient is participating in a research study, etc)
Objectives
The main objective of this project is to provide the 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
-
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.
-
(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.
-
(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 the notified, (4) the doctor advises nurse on what action the to take
-
(1) the 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 the ck down patient.
Project Design
This project is composed of 2 major components.
- 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 a notification whenever the event happens.
- Microservice to read Bahmni atom feed — This module keeps polling the Bahmni atom feed and determines whether anything notifiable has happened.
Subscriptions Management Module
Subscription management module expose UI 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
-
OWA — Frontend of the application. Expose relevant UIs to manage subscriptions.
-
API — Dao entities and service layer of the application. Expose a set of APIs
-
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.
-
Layer 01 - Filter new notification based on subscriptions. The notification which is not relevant (No user has subscribed to these notifications) are rejected. Only those relevant events are directed to the next filtering layer (Layer 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.
-
Layer 03 - 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
- Java
- JavaSpark Framework
- Hibernate
- 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
Subscription management module project repository
Microservice project repository
Project Description