Has anyone configured the ability to have multiple visits (not encounters) occurring at the same time within OpenMRS? So one patient - 2+ visits with multiple encounters under each visit - during the same / overlapping time period.
@mseaton / @mogoodrich / @ball I know that EMR API is designed that way, so that thereās only one active visit at a time. I wonder if you ever faced a use case that would require to change this, or at least to make this configurable?
No. We havenāt come across this use case, but we donāt allow it either.
@janflowers Whatās your use case?
@janflowers, when I built that part of the data model, the intention was for visits to be a collection of encounters. IE, an inpatient stay is a visit, and that stay consists of multiple clinical encounters.
I canāt imagine how a person would be able to be a part of multiple visits. Maybe some examples? 
Hi, an example from AMPATH (@jdick can correct if I have this wrong):
Visit are being used to control what clinical encounters (forms) users can select from. Visit are nested under programs. This means,
If a patient is being seen within a clinical appointment for both HTN (HTN program) and HIV (HIV program), they would be using encounters across two programs and two visit types.
If a patient is being seen within a clinical appointment for both an HIV Adult return visit, as well as a Nutrition visit, they would be using encounters from one program, but two visit types.
1 Like
Looking at how FHIRās handling this, it allows for encounters to be nested.
It also splits the appointment (schedule) and the clinical encounter into separate resources.
https://www.hl7.org/fhir/appointment.html
Appointment resources are used to provide information about a planned meeting that may be in the future or past. The resource only describes a single meeting, a series of repeating visits would require multiple appointment resources to be created for each instance. ā¦ This definition takes the concepts of appointments in a clinical setting and also extends them to be relevant in the community healthcare space, and to ease exposure to other appointment / calendar standards widely used outside of healthcare.
https://www.hl7.org/fhir/encounter.html
As stated, Encounter allows a flexible nesting of Encounters using the partOf element. For example:
The Encounter resource is not to be used to store appointment information, the Appointment resource is intended to be used for that. Note that in many systems outpatient encounters (which are in scope for Encounter) and Appointment are used concurrently. In FHIR, Appointment is used for establishing a date for the encounter, while Encounter is applicable to information about the actual Encounter, i.e., the patient showing up. ā¦ As such, an encounter in the āplannedā status is not identical to the appointment that scheduled it, but it is the encounter prior to its actual occurrence, with the expectation that encounter will be updated as it progresses to completion. Patient arrival at a location does not necessarily mean the start of the encounter (e.g. a patient arrives an hour earlier than he is actually seen by a practitioner).
ā¦
- A patient is admitted for two weeks - This could be modeled using a single Encounter instance, in which the start and length are given for the duration of the whole stay. The admitting doctor and the responsible doctor during the stay are specified using the Participant component.
- During the encounter, the patient moves from the admitting department to the Intensive Care unit and back - Three more detailed additional Encounters can be created, one for each location in which the patient stayed. Each of these Encounters has a single location (twice the admitting department and once the Intensive Care unit) and one or more participants at that location. These Encounters may use the partOf relationship to indicate these movements occurred during the longer overarching Encounter.
- During the last part of the stay, the patient is visited by the members of the multi-disciplinary team that treated him for final evaluation - If relevant, for each of these short visits, an Encounter may be created with a single participant. Since these took place during the last part of the stay, the partOf element can be used to associate these short visits with either the third patient movement or the bigger overall encounter.
These can be coordinated via a Care Plan CarePlan - FHIR v5.0.0
Absolutely @gschmidt, this arises from cross-programs situations, at least thatās the use case that we are required to cover.
@paul just to be clear, OpenMRSā data model doesnāt prevent this, but this is enforced in EMR API.
1 Like
@gschmidt yes, thatās the exact same situation here. How did you all handle that at AMPATH?
@mksd is correctā¦ this is enforced by the EMR API module, but not the data model. The primary reason itās enforced by EMR API is so that EMR API can assume there is only one active visit at any one time, and provide some utility functionality around thatā¦ for example thereās functionality to associate any created encounters with the active visit.
At PIH we donāt really use visit type, because of this restrictionā¦ in fact we have only a single visit type.
Take care, Mark
Interesting. If there are three implementers (that we know of from this thread) all doing work-arounds to accomplish a similar use case, does that constitute the need to modify the EMR API as part of the core community efforts (edited because I was misunderstood here, sorry about that)?
@janflowers EMR API is a module, and itās not a platform module
@mogoodrich, from the top of your head, is expanding EMR API in the direction of supporting concurrent active visits -if configured to do so- a reasonable development or a complete game changer for that module?
@janflowers, @jdick, @gschmidt, and @mksd, do we think that modeling this requirement out as multiple overlapping visits is the right way to model this, or is it what groups have chosen because itās a workaround in lieu of a more correct design?
In terms of configuration and control, I would love for us to have some more formalized configuration constructs that allow us to represent valid combinations of Programs, Encounter Types, Forms, Patient Identifiers, Visit Types, Attributes, etc and to build workflows and UI/UX around these. We certainly have done this ourselves, though using older, hackier mechanisms. Still, Iām not sure that overlapping visits that contain a subset of encounters is the best model.
Some possible alternative ideas to consider with the existing data model:
- Store 1-N visit attributes on a single visit (eg. Reason For Visit), and check those to determine what types of encounters are allowed within that visit.
- Store 1-N observations on 1-N encounters within a single Visit (eg Reason for Visit). Check those observations to determine what can/should happen within that Visit.
I assume you donāt have this use case, but letās say you have a Vitals encounter that is independent of program. You canāt have 1 encounter connected to 2 visits. So how do you represent that this Vitals encounter is part of both your HIV visit and your NCD visit? Even if this doesnāt happen today, is this plausibly something youād want to support in the future (eg. in an Integrated Care Clinic?)
@mksd, I donāt know the answer but am curious to hear from @paul, @burke and @darius around their thoughts/recollection of whether validating was deliberately kept out of core and put in emrapi to keep this option open, or if there were other intents.
Mike
1 Like
Iād have to look to refresh my memory in more detail, but, to clarify, I probably should have used different terminologyā¦ I donāt think that EMR-API necessarily enforces a single encounter, but if you use the methods it provides it ensures a single visit at one time. Itās the core apps module that expects a single visit at any one time, and, if perhaps you end up with multiple active visits it can end up stack trace if you try to open the visit dashboardā¦ weād need to identify the places where this occurs and fix this upā¦ but thereās also is likely a question in some of these cases of what is exactly supposed to happen (from a UI perspective, among other things) if a patient has two active visitsā¦
Take care, Mark
Clever, but not the intended use of these objects. 
Yeah, I donāt know how you would prevent 1-to-many simultaneous visits within the data model. But the concepts of visit and encounter were initially an attempt to describe āreal lifeā clinical settings. IE, a person can often times interact (have an encounter with) multiple health workers during a specific visit (contiguous period of time where a person goes to a location ).
So, at some level the data model has to be opinionated about such thingsā¦ and this was the choice we made (and validated against HL7 v2ās conventions) when we built the data model back in 2004-2005.
This comment relates to this:
Iām just the old codger to this conversation, but when we conceived OpenMRS, we believed pretty strongly in conventionsā¦ ie, the data model was meant to support clinical care in as much detail as possible to avoid drift in how people stored data. In this thread, weāve seen a couple of examples of that drift, which is kinda hard to totally avoid.
I wonder if weāve lost sight of the definitions of the objects, or maybe not made it clear to implementers what the conventions were?
https://guide.openmrs.org/en/Getting%20Started/openmrs-information-model.html
Thereās lots of pages out there like this one that I think do a pretty good job of distinguishing visits from encounters. What role do we have as a community to help make those conventions known, and more importantly, what should we do to support cases where implementations become stuck once those conventions are misunderstood or broken?
That help you understand my perspective?
I always had the same mental model as Paul, that a visit was meant to represent a contiguous block of time that the patient is interacting with the care system, in a single physical or virtual location.
I would consider it invalid to have overlapping visits at the same location.
I did assume weād someday have to support overlapping visits at distinct locations in the location hierarchy, if it happens that one OpenMRS database is storing data for multiple care providers. But these seem like corner cases.
Examples:
- patient does a āphone visitā teleconsultation with an external doctor while theyāre in the middle of a clinic visit
- patient is in a hospital visit, and they are taken to some independently-run and administered specialty clinic on the same campus (and for some political reason this doesnāt count as a discharge from the hospital).
IIRC the emrapi module supports having multiple visits as long as the locations of those visits are in distinct areas of the location hierarchy. (But itās been years since I looked at that.)
But those examples are really supposed to be the 1% use case, not the common case.
For the described use case (cross-program care with a single real-life visit to the facility) I agree with Mikeās suggested approach, i.e. use visit attributes to indicate what care the patient is supposed to have. This can drive the UI too. Encounters will be the record of what actually happened.
So coming back to this conversation because itās still unclear to me how to accomplish what the implementer needs to track. Hereās the story they are solving:
- patient comes into the clinic and is part of the program A. While the patient is there, they also go and see a provider in program B, and then afterwards, returns to a provider in program A.
Right now, from what I understand when using EMR API, you can start a visit for the patient as part of program A, but then you would have to end the visit and start a new visit for that patient to be seen in program B, and then end a start a new visit to go back to program A. That doesnāt seem correct since it technically is all the same visit - but just across service areas. Instead: Weād like to be able to have a visit, and encounters for the programs they are involved in during that visit.
Is the only way to accomplish that to do the start/end visit pathway - and run up 3 visits instead of the actual single visit they do? Or is this the same story other implementers are trying to accomplish with these workarounds you all have wrote out here? If itās the same or similar - shouldnāt we look at what @mseaton suggested and find a better design that allows some configuration? @paul since this is actually an enforcement from EMR API, does this still fit the data model that was selected or is this too far of ācreative useā like you mentioned to @gschmidt?
@janflowers EMR-API enforces that a patient has one active visit at one time, but it does not enforce that there is a one-to-one mapping between programs and visitsā¦ I believe that some implementations have standardized a one-to-one mapping between programs and visit types and use visit types to control what forms are available, so if a patient is seen for multiple programs within a single actual āvisitā they would need to create two or more visitsā¦ but that it nothing that is enforced (or implemented) in the core Ref App modules.
Take care, Mark
So are you saying that because the program and visit type is mapped, that they must end the visit and start a new one to change programs? Is this something in the EMR API that is enforced? Or is this something custom configured/created?