Following a discussion about modeling with programs here, I wanted to start a thread specifically to discuss ideas that @burke brought up about ways to improve programs.
Specifically, I’ve often hear about how Programs might relate or evolve into something similar to Episodes of Care and/or Care Plans.
Having whatever we do to evolve OpenMRS be informed strongly by FHIR makes a lot of sense.
I also feel like one of the biggest gaps with using Programs for data (similar to what @mksd brought up) is that there is no linkage between them and other parts of the OpenMRS data model.
In my experience, implementations use programs the majority of the time to represent a patient’s enrollment in a clinical chronic care program - HIV Programs being the most common. Workflows and states are often then added to track slow-moving data points that are constant over time and are conceptually considered a “status” of the program. Treatment status is by far the most common “Active, not yet on treament”, “Active on treatment”, “Lost to follow-up”, etc. But I’ve also seen it used for tracking other program-attribute-type data (program group assignment for the patient), diagnostic information, and other status information.
One gap that I’ve often experienced is that the enrollment in a given program is often associated with a particular encounter. For example, enrolling in the HIV program often starts with an HIV Initial encounter and this encounter collects history and surveillance data that is not captured on each subsequent HIV Return encounter. Depending on the way things are modeled, state changes may also be triggered/associated by an encounter. For example, a Transfer Out encounter might be associated with Program completion and a state change of “Transferred Out”.
In these cases it could be valuable to have the ability to (optionally) associate encounters with a program. Something like having:
- patient_program.enrollment_encounter_id
- patient_program.completion_encounter_id
- patient_state.start_enrollment_id
- patient_state.previous_state_id
In FHIR, it seems like the closest analog is that Encounter references an Episode of Care. So maybe the most straightforward thing for us would be just to add an optional new field to the encounter table:
- encounter.patient_program_id
We can likely determine the role the encounter played in the program based on the Encounter Type, though if there are ways to make this explicit as the first option, that could be helpful.
This will give us the ability to associate an arbitrary large and complex amount of data with a particular Program enrollment (as Obs on an associated enrollment encounter). Most of us do this today already but have to make inferences based on overlapping date ranges of encounters and program enrollments, or other logic which is not particularly robust.
Interested in thoughts out there on how we might support this.
Best, Mike