Context-specific Dashboards via Core Apps

Development
1

Hello all–

As part of adding support for programs to the reference app, we’ve started thinking about the idea of “context-specific” dashboards. Specifically, for some of our programs, like HIV, we’d like to have a special dashboard that displays HIV-related functionality.

At it’s simplest level, this a “context-specific” dashboard could just be an instance of the clinician-facing dashboard, but with a different set of display elements in the two columns, and a different set of actions and visit actions (or no actions at all).

I was starting to think today about a way to implement this, and I realized there’s a rather simple way to provide the basic underlying functionality. All one really needs to do is make the extension points on the patient dashboard parameterizable. For instance, currently in PatientPageController we set up the extensions as follows:

List<Extension> firstColumnFragments = appFrameworkService.getExtensionsForCurrentUser("patientDashboard.firstColumnFragments");
Collections.sort(firstColumnFragments);
model.addAttribute("firstColumnFragments", firstColumnFragments);

We could simply make this parameterizable via a request parameter called “dashboard”, ie:

List<Extension> firstColumnFragments = appFrameworkService.getExtensionsForCurrentUser(dashboard + ".firstColumnFragments");
Collections.sort(firstColumnFragments);
model.addAttribute("firstColumnFragments", firstColumnFragments);

Of course, there would be further complexities on top of this: we’d need to make sure we can configure breadcrumbs correctly, we’d need to make sure returnUrls are properly configured, we’d probably want to add some sort of header so that the end user realizes what context they are is, and, of course, we’d have to build some widgets that provide entry points to different contexts (my thought is that in our case the program lists widget would provide this).

But it would be easy to set up the above functionality as a first step, and then start to add other functionality in as needed. And it should be completely backwards compatible by using the default extension points if no custom context is passed in.

Any thoughts or objections to this approach? I will continue to do some exploration…

Take care, Mark

2

I seem to like this. Looking forward to see more results from your exploration! :slight_smile:

3

@mogoodrich Do you have any progress updates to share on this - very interested as this has come up for UgandaEMR too

4

Thanks for the reminder @ssmusoke, I never followed up here, but it was implemented as part of this ticket:

And, no, it hasn’t been documented yet (though it isn’t super complex if you want to look at the code and see what it does). Suggestions of where documentation for this should live?

Take care, Mark

5

@mogoodrich Where can I see an example usage as that would compliment the code?

I am still in a dilemma over where the documentation would belong see Best Practice for location of module documentation - this is a good example that would not find a good place on the WIKI but would need to be at a module level