I’m working on Bahmni - notifications on patients events module. After going through ideas for the UI design on doc[1] I can see that there are 2 options for the UI implementation.
Have a separate app to handle notifications
Add subscription buttons on each module(ex. 1) In order page, next to lab orders - have an option “notify me for results” 2) inpatient dashboard - have an option “notify me when a visit is opened”)
AFAIK former approach has some advantages such as
1) Can centrally manage all notifications and events.
2) Easy to subscribe to group notifications
3) Easy to enable/disable the module based on user preference
To clarify for others, this is for the GSoC 2018 project Bahmni - Notification on Patient Events, with the aim of providing a way for healthcare providers to subscribe/unsubscribe to notifications of specific patient-related events in Bahmni.
There are two concerns when considering the approach here:
Limiting project scope (and prioritising features) to make sure the objectives are achievable within the GSoC timeline.
Ensuring the design takes into account feedback from the Bahmni community, so that the solution is practical/valuable for end-users.
Personally, I think having an app to centrally manage notification rules, subscriptions and assignments is a good starting point, that could be extended later with in-module subscription options - I expect this would be really valuable to end-users to add notifications ‘on the fly’, rather than doing this through a central notification app. For the GSoC project though, my suggestion is to focus on the central app approach for now, but let’s see if others have thoughts on this.
I’d also suggest sharing some of the relevant UI mockups you’ve worked on - that may help others better understand (and feedback on) the approach.
@danfuterman Thanks for the feedback.
I propose we use a similar UI as in patient registration where users can search search subscriptions made by him and create if the subscription doesn’t exist. As a initial approach I’ll assume events are predefined.
Here are some of UI mock-ups for subscription search and create new subscriptions.
UI to create new subscriptions by adding patients.
Looking at the wording here, it looks like you’re proposing that subscriptions are associated at the user level. I agree with this approach - events are global but subscriptions are not. Rather, each user has their own set of subscriptions.
I’m not sure how many subscriptions each user would end up adding, but it might be useful to show a list of these on the Manage Event Notifications page, rather than a search field to find existing subscriptions. I know personally I’d likely forget the names of each subscription I added, it would be useful to see a list of these.
It’d be good to add a Description field to this.
We’ll still need to settle on UI layout/naming conventions, but for now it’s worth looking at existing UIs/conventions to guide you. For example, The ‘Subscribe’ button is probably better named as ‘Save’.
It’s not clear from this how patients are selected/added. Are you proposing that patients are added individually, using a ‘patient search’ type feature. Or that patients are added in groups, using predefined cohort rules?
What do you expect the UI to look like when editing/updating an existing Event Notification? Specifically, how would a user remove/void one of these - through this page, or on the page showing the list of these on the Manage Event Notifications page (that I suggested above)?
I know you’re still going to look at the third project objective to manage the notification mechanism (e.g. email, SMS, in-app notification etc.), but one thought that comes to mind here - how would users specify notification type parameters? E.g. if the subscription type is email, where is the email address specified? Or if the subscription type is SMS, where is the cell num specified? And should this be defined at the user level, or the event notification level? This may turn out to be a non-issue depending on the notification mechanism that is chosen for the project. One of the early steps should be to get community feedback on a preferred mechanism.
Yes, subscriptions are associated with user level.
What if we use a table like structure with a description for each subscription. However we can start with this and change the appearance later. Functionality will be same (each subscription with a description etc. only the visual appearance may need to be changed.)
+1
I suggest we add patients one by one to achieve a higher flexibility. It will be useless to group patients beforehand as there will be lots of combinations.
This will be done via a table which provides subscription manage functionalities or we can use the same structure as above(subscription with desertion etc.)
We can start with in app notifications which may not require much information. Anyway we will have to get community feedback when introducing new mechanisms.
For adding individual patients, can you add a UI mockup or description for searching/selecting patients on this form.
Adding groups of patients would be very useful, but we may want to limit the prototype to selecting individual patients. To see examples of how selecting groups of patients could work, have a look at Cohort queries in the OpenMRS reporting module, or patient lists in Bahmni.
Before deciding to start with in-app notifications, it would be best to first try get community feedback on this, to check that this is actually a preferred mechanism. Otherwise, if you are leaning towards in-app notifications, it would be good to support this with mockups/suggestions on how you think notifications should appear in the app.
As discussed, below are a set of initial mockups to help guide the design of some of the components of the project, based on the proposed scope of the MVP:
Being able to subscribe/unsubscribe to notification one patient at a time
The Notifications management section provides a central solution to view notifications and ‘mark as read’, supplemented by an in-app alert mechanism added to the UI header:
These mockups are open to input and discussion from the community though. I think central in-app notifications are a good starting point for further extensibility in adding support for other notification mechanisms. Similarly, I think central management of subscriptions provides a good base, that would benefit from future work to allow for direct assignment of individuals to a subscription from a patient dashboard, and leveraging cohorts or patient lists for bulk assignment of patients to a subscription.
Thanks @isuranga, I’d recommend browsing through the following two threads for some background understanding on using the OpenMRS OWA generator for Bahmni apps, and bundling an OWA within a module (which seems to make sense for this project):
I used npm run build:deploy command. Maybe there are some unattended lint errors. However, I was able to deploy module on OpenMRS SDK using the above command. Will try fixing lint errors.
Resolving the lint errors (and/or any other issues) when compiling the OWA.
I’ve tried to use the compiled owa that you sent, but couldn’t get it to run. Haven’t had a chance to troubleshoot the issue but it seemed like there might be a missing bootstrap lib.
Bootstrap lib was previously used in the project. However, it is no longer needed.
Issues with lint errors have been fixed. Now you can use npm run build:prod to build the distribution without any error.
In addition to those changes, I completed all the tasks due for this week including
Project structure for the backend
Create new database tables
Implement DAO entities
Some of the tasks related to next week were also implemented
Rest API for add subscriptions
Rest API for update subscriptions
We can update the task list so that there are 2 milestones
Milestone 1 - Complete frontend and all backend operations related to the frontend (eg. manage subscriptions etc.)
Milestone 2 - Microservice along with its related backend features.
Appreciate your suggestions on this.
Couldn’t attend this issue yet. But I will be able to complete this task before the end of this week as well. Appreciate if you can provide some repositories which use Bahmni styling with react.
Thanks @isuranga, I’m able to compile and run the OWA now.
Nice, I see you’ve added api and omod folders to the existing repository. Just to note you should also look at openmrs module conventions in this case, e.g. the repository will need to be renamed from ‘owa’ to ‘module’, and the root folder README should also be updated so it’s not owa-specific.
I’m not aware of any other than the ones I’ve already shared. I’d suggest posting a new thread in Talk to see if anyone else has more to share.
One other point to remember for the frontend (I think I’ve shared this link before), is to try align with the Airbnb React/JSX Style Guide.
I’ve sent an invite to join the Trello board that we can use to track progress going forward.
Also, @arjun pointed out that Trello has revamped their notifications feature - just had a look and it’s really cool - some great inspiration for this project
Hi @danfuterman, Since major tasks of susbcriptions manangement module is completed by now we can move to the microservice.
There we need to consider few things
Microservices Framework - I did a research on available microservices framewroks and we have several options each with different pros and cons. (Spring Boot, Spark etc.). In my last year GSoC project I worked with WSO2 MSF4J [1] which is an another microservice framework.
Initial Phase - My suggestion is to use a graph database to store relationships among subscriptions and their relevant properties (one subscription may associated with patients while another associated with both patients and lab results.). In addition to that by using a graph DB we can support more complex events with minimum overhead (preprocessing etc.) However at the initial phase I suggest instead of using a database we directly send parsed feeds to the Bahmni backend to be processed.
Event definitions - At the initial phase of the project there will be predefined events. But we can allow users to define events in JSON or some other format (there should be a event parser in this case).
