@janflowers I think we should attempt to not have multiple concurrent visits and rather achieve what @mseaton suggested above: multiple concurrent encounters within the same visit (one per program, perhaps also some that are transverse… etc).
1 Like
Something custom configured/created… there’s no relationship between programs and visits in EMR-API or Core (as far as I can remember).
What @mksd says is what we do at PIH… a patient might have an HIV encounter and an NCD encounter within a single visit. Encounters have a single point-in-time and there can be as many as you want within a visit.
Take care, Mark
2 Likes
I totally agree, but wasn’t sure we could accomplish that with the use of EMR-API. You would know better than I would on that front…?
Yes, this is not a limitation of the EMR API module, it must be custom code for that implementation.
If someone is locked into having program:visit mappings, then one possible workaround would be to configure the location hierarchy such that there are parallel visit locations for different programs. E.g.
Hospital X
/ \
HIV Program TB Program
Locations* Locations* * = tagged as Visit Location
/|\ /|\
HIV Rooms TB Rooms
This is obviously hacky, and would require two visits (one for HIV one for TB), but that’s unavoidable if someone is locked into using visit types to control program-specific UIs. The visits would be allowed to overlap in time because neither visit location has the other as an ancestor. (At least, if I remember the code correctly. There’s also a chance that EMR API allows this, but Core Apps breaks, but that would be a quick and desired fix.)
Exactly. (Also, fwiw, Encounters are at point in time, with a single encounter_datetime, so thinking of encounters as concurrent isn’t exactly correct… though you can have as many encounters as you want with the same encounter_datetime)
I would hope that this could be avoided… 
Take care, Mark
Can you model it as follows?
Hospital X | Visit / \ HIV Program TB Program / | \ / | \ Encounters Encounters
If this is possible, can the encounter be automatically assigned to the correct program based on either the form that is used or the location of the encounter? The real goal here is to be able to have analysis of care given under each program, even though a patient may utilize care from multiple programs during a single visit.
@mksd I’m not sure if a patient would ever have multiple concurrent encounters unless they were doing telemedicine or remote monitoring in some way? At least not physically. So we should be able to do a single visit with multiple encounters. The question here would be how to tie it to the appropriate program since my understanding from the dialogue across the thread above is that Visit is hierarchically underneath Programs.
Yes this is will not happen, I also forgot that an encounter was not recording its own duration. As Mark said:
Encounters have a single point-in-time
There will be multiple encounters happening during the same visit, some associated to a program, some to another program, some to no programs at all.
That’s what we want to achieve, certainly. The entity patient-program has a location member (see here), but that doesn’t mean that every encounter that occurred at that location belongs to that program though…
I don’t know how we know that the data recorded during a given encounter is associated to a program or another, or none. One could argue to look at the patient, and see in which program he/she was enrolled at the datetime of the encounter, but again, a patient might be enrolled in multiple programs at the same time…
@janflowers taking a step back, it’s hard to answer your question because I’m assuming that the implementer has some (self-inflicted) constraint that is limiting them, and I assume it’s that they are using Visit Type to drive a program-based UI. In that speculative scenario I suggested a hacky workaround which would allow them to record 2 visits instead of 3 (for what’s really 1 visit).
But none of these limitations come from the shared OpenMRS model, and in the EMR API module. They both allow you to record what you’re trying to record in a straightforward way, i.e. you have a visit, and it can include both an HIV followup encounter and a Diabetes followup encounter.
In the OpenMRS data model (and in EMR API) visits and encounters are not linked to a Programs. Often an encounter type would be named to be part of a program, and someone might write their reports as if it belongs, but that’s outside the OpenMRS data model. Likewise someone might write a custom UI that ties a Visit Type to forms/screen for a particular program. But again, that would be in their custom code, not in OpenMRS core or EMR API.
As far as OpenMRS goes, sort of. You can have a Visit a the Hospital level, and you can have encounters from 2 programs in it. But “HIV Program” and “TB Program” are not actually part of the same logical hierarchy, so OpenMRS wouldn’t represent those nodes.
Whether or not EMR API currently supports it, Visits can definitely overlap. For example, a stable hospitalized patient may be taken to an outpatient clinic during their hospitalization to avoid missing an outpatient appointment, resulting in an outpatient visit coincident with an inpatient visit. Also, visit boundaries can be fuzzy (e.g., steps to close the visit may be deferred until the end of the day). Patients traveling a long way to a clinic may very likely arrange multiple visits on the same day for convenience and we cannot guarantee each preceding visit will be closed before the next begins. I think it would be fair to say two visits for the same type of visit in the same care setting would not overlap.
As far as automatically assigning encounter to visits, our intent was to support this auto-assignment in a manner that could be adapted to meet local needs, since the logic for automatically assigning encounters to a visit is not universal. Ideally, this algorithm would be isolated (not spread throughout multiple parts of the codebase) and would respond with an array of possible visits – i.e., in the happy path, you’d get back one visit, but if the algorithm lacked the information to decide between 2 or more open visits, it could handle the ambiguity by passing the list of candidates and forcing the client to pick amongst them.
OpenMRS Visit-Encounter Model
For OpenMRS, we came up with this model:
Encounter is an interaction between patient and healthcare system at a point in time.
Visit represents an event that can include one or more encounters and occurs over a span of time. Typically, an outpatient clinic visit or an inpatient hospitalization.
Episode of Care is a collection of encounters and/or visits that belong to a logical grouping and may span across visits. This could be all visits/encounters relating to a pregnancy or a course of TB treatment.
Program was created to represent a care program (like HIV Treatment Program or TB Treatment Program) or a study protocol. It might seem similar to an Episode of Care; however, there are distinct differences: patient are enrolled in a Program, may have a program-specific identifiers, go through states of a program, etc. Episode of Care is just a logical grouping that does not involve enrollments or states. If we had implemented Episodes of Care, they would have likely linked either to a condition or program as the “topic” for the episode of care. As it stands, if/when we want to implements Episodes of Care, we’ll be better off aligning with FHIR’s EpisodeOfCare resource.
| OpenMRS | FHIR |
|---|---|
| Encounter | Encounter |
| Visit | Encounter |
| Episode of Care | EpisodeOfCare |
| Program | PlanDefinition |
| PatientProgram | CarePlan |
3 Likes