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