OpenMRS currently allows to collect person observations, but not person encounters.
A couple of our implementations need to collect person encounters so all the person observations for the same encounter can be grouped. For example, person screening encounter form - this is to record test results whether the person is positive or negative. Before someone is confirmed positive and enroll into care, we don’t consider them as patients so we need a way to record the person encounter.
Would like to request OpenMRS to consider supporting Person Encounters. Thanks!
That’s interesting, in particular because obs actually are defined for a person and not a patient. But… obs can be saved outside of an encounter and perhaps this was the reason: just to cover that encounter-less case.
There could be ways to define the enrolment into care in a way that would rather split your patients in two groups:
Those not yet enrolled.
Those enrolled.
And the latter ones would be the “real” patients, those that are actually receiving care.
Is this something that you could consider, or you have come to the conclusion already that those persons must really not be OpenMRS patients?
I believe we allowed obs for a person because PIH had a use case where they could get lab results reported for a person prior to registering the person as a patient in their system. Or maybe it was b/c PIH wanted to collect observations on non-patients. I recall PIH driving the data model change, but not the specifics.
We’ve wanted to have encounters for groups of patients (cohort encounters), which would align with FHIR, but haven’t had anyone to drive that change (still trying to get cohort enhancements into core to align with FHIR and serve as a foundation for our needs for lists & groups of patients).
When design issues come up like this, we look to FHIR, since our goal is to eventually converge with FHIR’s model. While FHIR’s Observation.subject links to a Patient, their Patient doesn’t require a medical record like ours does. So, it’s technically possible. Though, if we did make changes, I would insist on not doubling-down on our mistake of assuming patient & person are the same (share a UUID).
My biggest concern would be the affect on all the existing code (modules, applications, API clients) that assume encounters are for patients. And to align with FHIR, we actually wouldn’t be making encounter for persons; rather, relaxing the registration requirement for patients… which might be a bigger can of worms.
As you know most implementations start with enrolling patients into care (e.g. HIV), OpenMRS is being used to collect patient specific encounter/obs data. As time goes, more and more implementations expand to implement screening programs (e.g. HTS, Index Case’s related persons screening, Cancer Screening, etc.). Let’s use the Index Case’s related person screening program as an example. Index Case Patient is being asked all his/her related persons’ information so the program can contact those individuals for screening. The relationship between the Index Case Patient and those related individuals are being set up via Relationship Features in OpenMRS (e.g. name, age, gender, person attribute types, etc.). When the individuals are being contacted for screening, we need to store the “screening encounter” for the screening observations (e.g. individual is being found or not, if being found, individual agree/disagree with screening, if agree, testing result, etc.) We would like to be able to group related observations as a person.encounter since those individuals are not patients yet (not enrolled into care yet). If they turn out to be positive and agree to enroll to care, we can convert those individuals into patients so all the data collected prior to enrollment will still be available.