Why are patient dashboard concepts displayed in random order?

mksrom · July 25, 2015, 10:31am

Hi there,

I think that there is a problem with the Patient Dashboard 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 ?

darius · July 25, 2015, 5:51pm

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

mksrom · July 26, 2015, 2:17am

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

darius · July 28, 2015, 12:56am

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

mksrom · July 28, 2015, 5:18pm

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 ?

darius · July 28, 2015, 6:56pm

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

github.com

PIH/openmrs-module-mirebalais/blob/4d1f50efc9a6f2ccf7fb11db55088e62ec20a9c8/api/src/main/java/org/openmrs/module/mirebalais/apploader/CustomAppLoaderUtil.java#L351


}


static public void addFeatureToggleToExtension(Extension ext, String featureToggle) {
    ext.setFeatureToggle(featureToggle);
}


static public void registerTemplateForEncounterType(EncounterTypeDescriptor encounterType, Extension template, String icon) {
    registerTemplateForEncounterType(encounterType, template, icon, null, null, null, null);
}


static public void registerTemplateForEncounterType(EncounterTypeDescriptor encounterType, Extension template, String icon,
                                                    Boolean displayWithHtmlForm, Boolean editable,
                                                    String editUrl,  // note that if editUrl is null/empty, the standard Html Form link is used by default--that's why we don't specify this is most cases
                                                    String primaryEncounterRoleUuid) {


    Map<String,Object> extensionParams = template.getExtensionParams();


    if (!extensionParams.containsKey("supportedEncounterTypes")) {
        extensionParams.put("supportedEncounterTypes", new HashMap<String,Object>());
    }

mksrom · July 30, 2015, 2:26am

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

mksrom · August 13, 2015, 10:35am

(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 ?

mogoodrich · August 13, 2015, 1:23pm

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.

mksrom · August 14, 2015, 8:16am

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