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