Hi all,
At ICRC, we need to record session data that isn’t linked to a specific patient. Ideally, we’d like to leverage the features provided by the OpenMRS encounters/observations and create a form for these sessions. However, the saved encounter should not tied to an individual patient.
A workaround would be to create a dummy patient to store encounters relative to these sessions, but this doesn’t seem an ideal approach.
Do you have any suggestions on how we can better address this issue?
Could you say more about the use-case here? Encounters and obs without a patient context seem… not very useful.
This reminds me of the Facility Data module which doesn’t seem to have much activity lately:
https://openmrs.atlassian.net/wiki/spaces/Archives/pages/25461910/Facility+Data+Module
This is a great point and reminder @ball.
Collecting non-patient data is sufficiently outside of the core purpose of an EMR to be done, at the very least, in an add-on module. Especially if the FHIR spec seems to not provide any support for this.
This is needed for the mental health program because they do a lot of training and capacity building sessions. The idea would be for them to capture these sessions in a very simple form where they can put the number of training and capacity building sessions done, so they use only one app to capture all their work.
So, unfortunately, the OpenMRS data model makes fairly strong assumptions about, e.g., encounters being tied to an individual patient, observations being part of an encounter and also tied to a specific individual. So if you’re using those parts of the core data model for this, I can’t really see any solution that doesn’t involve some sort of dummy patient.
An earlier version of the cohort module attempt to provide a mechanism for recording encounter- and observation-like data structures tied to Cohorts instead of individual patients; however, this functionality was not actively maintained and has been removed in the 3.0.0 overhaul of that module. That older functionality, though, does provide a model for how data similar to encounters and observations could be implemented by a module; it also provided basic support for the HTML Form Entry engine (although, again, this functionality has not been actively maintained in years so it may or may not work).
For simpler use-cases, it may be sufficient to implement a substantially simpler data model. The current React form engine is exploring implementing extensible FormProcessors which could be used to write the data from forms to any custom data model (including one like the one that used to be provided by the Cohort module). This means that if you had a backend module that provided the requisite data model you would be able to use a custom FormProcessor to pass the necessary data to it.
Unfortunately, I’m not currently aware of any out-of-the-box functionality that completely supports this kind of use-case, but hopefully those pointers are useful.
From your point of view, is this feature interesting for other organizations or is it really custom to our use case ? we could imagine updating this cohorts module and to let it be O3 compatible ( we will try to evaluate the workload :)). In FHIR standards I suppose that the same assumptions is made: encounters are tied to an individual patient. We will need to have this feature available offline and include in the Android Application.
I certainly think that the ability to record data about cohorts is a useful thing beyond just the ICRC case. If nothing else, anyone else running mental health services on OpenMRS is likely to need to capture the same kind of data for the same reasons.
FHIR is more generous than we are. Encounters can be recorded with a subject pointing to a Patient, a Group, or missing altogether, and you can actually submit a QuestionnaireResponse about any resource whatsoever. That said, the FHIR2 module is subject to the same restrictions as OpenMRS in general, so our version of Encounter requires a patient (though this is overrideable).