Why are patient dashboard concepts displayed in random order?

Ask OpenMRS
1

Hi there,

I think that there is a problem with the Patient Dashboard :neutral_face: All the observations of any encounter type, any Form are all messed up.

For example, the Vitals on the online demo server: I’ve entered 2 times the Vitals:

Should I create a ticket for that ?

2

Could you explain what is “all messed up” about those screenshots?

3

Hi Darius,

Sorry that may not be obvious since I brought it to a minimum for the example. By “all messed up”, I mean " not in the right order ".

Concepts are not displayed in the same order than they are recorded on the form. And it is always a different order.

I’ve changed the title

4

This is a fundamental issue in OpenMRS: the observations in an encounter are not naturally sorted.

If you want to get these to display consistently you need to associate an encounter display template with the encounter type. (Sorry, offhand I don’t remember where you do this.) If this form is an HTML Form then there’s a quick way to render it using the HTML Form Entry module’s existing code (but I don’t remember how to do this offhand either).

1 Like
5

Thanks. This form is an HTML form yes. Could you explain me a little more that second option you are talking about: “Render it using the HFE module’s existing code” ? Or redirect me to the person who could help me ?

6

You will have to reverse-engineer from Java code to what the JSON would have to look like, but an example is here:

7

Thanks @darius for the tip, I’ll look into that asap. (I think I start to get a grasp on the way that works)

8

(Sorry to come back 2 weeks late. I have more time to look at it now)

There is the referenceapplication module that extends the defaultEncounterTemplate in encounterDisplay_extension.json (1).

[
{
	"id": "referenceapplication.defaultEncounterTemplate",
	"extensionPointId": "org.openmrs.referenceapplication.encounterTemplate",
	"type": "fragment",
	"extensionParams": {
		"templateId": "defaultEncounterTemplate",
		"templateFragmentProviderName": "coreapps",
		"templateFragmentId": "patientdashboard/encountertemplate/defaultEncounterTemplate",
		"supportedEncounterTypes": {
                "d7151f82-c1f3-4152-a605-2f9ea7414a79": { // Visit Note
                	"icon": "icon-stethoscope",
                	"editable": true
                	},
                   	...
                }
            }
}
]

If I add "displayWithHtmlForm": true in this JSON, that works perfect, my encounter will be displayed with HFE form.

Now I would like to do this changes with my own module.

Is it possible for me to create my own myEncounterDisplay_extension.json that would add more supported encounter types on top of what’s already extended with the referenceapplication module ? So can the defaultEncounterTemplate be extended 2 times ?

If not, do I need to disable the first one to be sure mine is used instead ?

9

I don’t know think that you can extend the default encounter template, but you could create a new encounter template that uses the same fragment, I believe, like:

[
{
	"id": "referenceapplication.**myCustomEncounterTemplate**",
	"extensionPointId": "org.openmrs.referenceapplication.encounterTemplate",
	"type": "fragment",
	"extensionParams": {
		"templateId": "**myCustomEncounterTemplate**",
		"templateFragmentProviderName": "coreapps",
		"templateFragmentId": "patientdashboard/encountertemplate/defaultEncounterTemplate",
		"supportedEncounterTypes": {
                "**my-custom-encounter-type-uuid**": {
                	"icon": "icon-stethoscope",
                	"editable": true,
                   "displayWithHtmlForm": true 
                	},
                   	...
                }
            }
}
]

This should get what you want, I believe… the only issue is if you wanted to override the template for the visit note encounter type as defined by the reference application.

Right now there are generally two use cases–users that use the reference application out of the box, and that don’t use the reference application (ie, don’t install the reference application module) but have their own “setup” modules that do all the setup for their implementation. It does seem like it would be valuable to allow overriding… so implementations that wanted to generally use the reference app but make minor modifications could do so.

10

Thanks @mogoodrich

I had to change a little the JSON provided above to make it work:

"templateId": "defaultEncounterTemplate",

(since I want to use the existing template)

That works. Thanks a lot.

But as you said, it won’t let us override the config of an encounter type (already set up in the refapp encounterDisplay_extension.json) and we do use some of the existing encounter types.

Therefore the solution for us would be to maintain a fork of the refapp module and use it as a base for our future customization.

Thanks for your help