Currently the ObsAcrossEncounters widget on the clinicianfacing dashboard shows Obs if they are part of the latest specified number of encounters here in the app JSON with the default of 4 if not specified
Challenge is when I want to display Obs which were captured in an encounter which is not part of the latest Encounters: I get back none despite passing in a maxAge that includes the obs
Prosal one is to probably alter the name of the widget to reflect what it says such as ObsAcrossLatestEncounters
Prosal two is to alter the rest call of the current widget to be based on latest obs rather than latest encounters
Prosal three is to build another widget to address this challenge
@dkayiwa @mksd @ibacher
Just to try to understand your use case fully, why is it that you could not use the ‘Latest Obs For Concept List’ widget?
@mksd Am looking at it further and see though my guess would be that i then cant see an evolving trend of the obs on that given concept since the latest only is returned
And coming back to ‘obs across encounters’, how is it that you could not identify all the encounters where your target obs is being recorded?
The encounter that has the obs of interest is out of scope of the latest encounters returned(by default the latest 4 latest encounters are returned)…implying if my obs is in the fifth then it is not return…
Am going ahead with ‘Latest Obs For Concept List’ for now…Thanks for the insights @mksd
FWIW, the new parameter nLatestObs added to ‘Latest Obs For Concept List’ has been able to satisfy my usecase…
@ruhanga will be happy to know
Great that nLatestObs was of help.
I am just pinging on this thread, seems like this widget is currently broken and does not show any data
Just found this in UgandaEMR and also on the OpenMRS demo, any ideas
Found the root cause and opened an issue here https://issues.openmrs.org/browse/RA-1864 because the encounterType is required even if its defined as optional
I think the wiki is not properly documented there. Either
encounterTypes must be configured. But in isolation each one of them is optional.
I haven’t looked at your ticket yet (on my phone currently).
@mksd noted, however that constraint was never included in the initial design of the widget, since a user does not have to restrict to specific encounter types but be able to search the whole database
There’s been some messing up for sure, especially around the time of the introduction of a new
encounterTypes (plural) config param.