We’ve recently been discussing program workflows in O3, and while looking into this I noticed what seems to be a gap in how programs relate to clinical data. find the context here Slack
Today, we can:
- Enroll a patient into a program using the Care Programs widget.
- Track program enrollment, workflow states, and enrollment dates.
- View all patient visits, encounters, and completed forms.
However, there doesn’t appear to be a standard way to answer questions such as:
- Which visits belong to a specific program?
- Which encounters were performed as part of a particular program enrollment?
- Which forms were completed during a patient’s enrollment in a given program?
For example, consider an HIV Care and Treatment program. A patient may have multiple enrollments over time and also have encounters unrelated to HIV. From a clinical and reporting perspective, it would be useful to distinguish encounters and forms that were part of that HIV program from those that were not.
From the discussion with @ibacher , it sounds like this is because OpenMRS currently associates patients with programs and separately records visits and encounters, but does not define a standard relationship between a program enrollment and the visits or encounters that occur during it.
I also understand that AMPATH addresses this through configuration that maps:
Program → Allowed Visit Types → Allowed Encounter Types
This works for their implementation, but it is implementation-specific and depends on carefully controlled visit and encounter types rather than a platform-level association.
This made me wonder whether the community should consider defining a more standard approach.
Some questions I’d love to hear thoughts on:
- Should OpenMRS provide a standard mechanism for associating visits or encounters with a program enrollment?
- If so, should that association be explicit (for example, storing a program enrollment reference on visits or encounters), or should it continue to be inferred through configuration and encounter types?
- How should forms fit into this model? Should a program be able to expose only forms relevant to that enrollment and later present a program-specific history of completed forms?
- Are there existing implementations besides AMPATH that have solved this problem in different ways?
I’m interested in understanding whether this is a gap worth addressing at the platform level, or whether it should remain an implementation-specific concern. I’d appreciate hearing how others have approached this and what a community-supported solution might look like.