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.
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.
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.
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 https://www.hl7.org/fhir/careplan.html#CarePlan
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.
@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.
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?
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.
- 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?