Bahmni Admin UI OWA Styling

[danfuterman (Daniel Futerman)]

Is there consensus/preference for how OWAs for Bahmni Admin functionality should look (and where links should appear)?

The context for this is the work that @isuranga is doing on the Bahmni - Notification on Patient Events project for GSoC 2018. One of the deliverables for the project is developing a new React OWA to manage notification subscriptions and in-app notifications. Intially, I suggested adding a new link to the Admin page, and a few new UIs (see mockups from this thread below).

But I see in this thread there’s discussion on using the OpenMRS RefApp styling (that’s packaged with the OWA generators) for Bahmni Admin UIs. This also means that page links appear on the OpenMRS admin page, rather than in the Bahmni UI, and this seems to be the route that was taken for the bedmanagement module.

I don’t think it’s in scope for @isuranga to develop OWA styling for Bahmni Admin UIs, but he could take a pass at implementing something that’s in line with this, or he could stick with using the RefApp styling for the app.

@danfuterman

This would consist of adding a new Notifications app to the Admin section in Bahmni:

The app itself would consist of Subscription and Notification management sections.

In the Subscriptions management section, users can manage their notification subscriptions, and assign individual patients to each subscription:

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.

[mksd (Dimitri R)]

For Bed Management UI we just followed the Ref App styling. The idea was that it didn’t matter so much to style it as Bahmni since it was never going to be a clinical set of screens.

So the underlying assumption is:

• Clinical: Bahmni styling.
• Admin: Ref App/default styling.

And yes clearly this was the easiest and quickest way because of the way those OWAs are generated.

[danfuterman (Daniel Futerman)]

Thanks for clarifying, @mksd. For this case, although some of these are administrative screens, the functionality is designed more for clinical users than admins/implementers, so it would better suited to be managed through the Bahmni UI/styling (similar to the Change Password feature - not a clinical screen but for clinical users to manage their profile).

Thinking it through though, the Admin section is probably not the best place to put this app, if clinical users are restricted from that section. Alternatively, the Notifications app link could be added directly to the home page (concerned about cluttering up the home page though), or as a link to the User dropdown, i.e.:

[angshuonline (Angshuman Sarkar)]

I think this is relevant to the ideas of how we think of extensions in Bahmni - visual and interactive perspective.

1. personalized-drop down : an easy place to do so if just a link, with some possible additional information like number of events. (Notifications 5). Or support the way we already do for custom controls.
2. the top header area can similarly be addressed.

The other aspects is about interactivity - e.g. how will a provider while using the app, get notified of a notification relevant to an individual or appointment etc? how will the rules of ‘subscriptions’ kick in? for example, in the mocks @danfuterman shared, how will ‘TB patient visit’ be defined?

To make this work with both ref-app and bahmni, I am guessing we will have to think of such extensibility both on the server and client side, given any given combo for a particular implementation.

[darius (Darius Jazayeri)]

Trying to scope this for a GSoC project, and keeping in mind that this would be used by clinical users during their standard work process, I would suggest:

• building this so that it integrates in the Bahmni EMR UI (via extension as Angshu mentions)
• have look and feel of the Bahmni EMR UI

[danfuterman (Daniel Futerman)]

Thanks all. @isuranga - confirming that you’ll need to look at adapting the UI work you’re busy with to support the Bahmni EMR UI look and feel.

@angshuonline

The other aspects is about interactivity - e.g. how will a provider while using the app, get notified of a notification relevant to an individual or appointment etc? how will the rules of ‘subscriptions’ kick in? for example, in the mocks @danfuterman shared, how will ‘TB patient visit’ be defined?

For this project, notifications are limited to in-app notifications, likely shown as simple alerts in the header, with a link to a UI to view/manage the notifications. To start with, a few simple event types will de defined, such as ‘patient visit’, ‘lab result ready’ and/or ‘abnormal lab result’, and a service will be added to read the atom feeds for events of this type. ‘TB Patients Visit Alert’ would be defined by adding a new subscription using the ‘patient visit’ event type, and then selecting applicable patients enrolled in a TB program or receiving treatment for TB. In other words, it’s not a ‘smart’ selection, but up to the user to define appropriate subscription names and select individual patients applicable to this. In future, this would hopefully leverage functionality such as cohorts or patient sets for bulk adding patients to a subscription, allowing for ‘smarter’ rules/mechanism for selecting applicable patients.

This is all open to discussion though - the priority is building something that meets the need of end-users/implementations (within scope of a GSoC project).

[isuranga (Isuranga Perera)]

Thanks all. @danfuterman I used the Ref App/default styling for the UI. Will work on to adapt them to Bahmni EMR UI look and feel.

[mksd (Dimitri R)]

Is there any plan to integrate this Bahmni styling with the appropriate Yeoman generator(s)?

[danfuterman (Daniel Futerman)]

It’s not an explicit deliverable for the GSoC project, but I’ve asked @isuranga to document the steps he takes to align with the Bahmni styling, so it can be used as the basis for adding Bahmni styling support to an owa generator.