The use-case would looks like this; “We need to have the most recent Vitals list data entered outside the Vitals form”
The Vitals html form fed through Capture Vitals link on the clinician’s facing patient dashboard in the reference by default is restricted to require only Vitals Encounter type at:
that can for-example receive its value from:
However as defined in the above sample use-case, people would love to have most recent Vitals entered through other places/forms.
My first thought if this is not currently achievable through configuration is piloting either a hack from another module or add this configurable support to coreapps itself. Which one of these options are more users/implementers/developers here more comfortable with!!!
The solution in my simple plan would before throwing IllegalStateException("encounterTypeUuid app config parameter required"); read a GP value which if set expectantly would trigger skipping the Vitals Encounter Type filter and retrieval each of these most recent Vitals through the Observations API and else proceed with the throwing
However the whole of this controller seems to be encounter based such as populating Vitals into the html Vitals form view at:
I wonder whether these are the right places to look at etc and i don’t want to disable and regenerate the whole Vitals section in my module without giving the community the extra advantage to tapping into it by default from coreapps!!!
This is one of those most asked for configuration points. In your proposal, how would you like to identify vitals obs? Do you want to fetch all obs as vitals?
the above method returns observations based on patient and concept, each of the vitals such as height is finally stored inside OpenMRS as an observation with a concept and value numeric or coded concept answer or etc.
after returning observations around a concept such as height for a patient the same way i would get all heights for a patient observed, i can loop sort them to obtain the most recent and such a value is what i would have for each of such a vital item
I understand the API. But i have not yet understood your proposal. Currently, an encounter type is used to locate vitals. So what do you want to replace this with?
I personally don’t see why we should restrict the vitals to a given encounter type, the ref app comes with CIEL therefore we should be fetching the most recent vitals by concept and patient regardless of the encounter type.
One of our client was asking for this as well.
We started the development of a widget whose obs list could be configured via a config file.
The widget would look like the current one but would display the latest value of each obs. Then clicking on the obs’ line would expand a quick 24h chart under it, a further hyperlink set in the bottom edge of the quick chart would take the user to the Chart Search for that obs.
Unfortunately this development was put on hold for reasons that are out of this thread. Just to say that yes: the current vitals widget could definitely be more configurable, and provide more meaningful clinical information than the read-only snapshot of the last recorded vitals encounter form.
I have instead re-written a fully similar Vitals section that uses patient observations to fill its Vitals; enabling it disables the default Recent Vitals section and disabling it Enables the Default one