So currently on the O3 frontend we determine the “Active Visit” for a patient by looking for the most recent active visits that started today (we also filter those to only those without a stop date time, which is actually redundant). This hacky way to determine the active visit doesn’t really work for all implementations as it basically makes it impossible to have a multi-day visit that the O3 frontend recognises. However, there are some valid use cases where it only makes sense to consider visits that happened on the same day and to regard visits from previous days as implicitly, if not explicitly closed.
I would like to replace this logic with something more sensible and flexible. However, I think it would be a good idea to try to figure out what the requirements are around this.
For example, is it safe to assume that a patient only has one active visit at a time (i.e., we don’t support overlapping visits)? How can we enable individual implementations to support their own custom logic to determine what should be the active visit? Or do we need to always prompt the user to select a visit to make active and only regard the patient as having an active visit once the visit has been selected (I think O2 worked in this way)?
Very interested in anyone’s comments or opinions!
(Not really sure who I should tag here… @grace could you help me out?)
I completely agree this is too hacky, and we need something more flexible & soft-coded.
But @ibacher can you first clarify: What is driving this concern for you? Is there a production use-case?
Woah - thanks for the link to actual code. I did not realize this was defined and so hard-coded in esm-core. I thought the only place making this decision was the esm-active-visits-app. Both the logic of esm-active-visits and the app itself was always meant to be a temporary placeholder until the better Service Queues UI / Home Dashboard UI is completed.
Tagging a few people who I’d love to hear from:
@corneliouzbett - I remember around Dec while I was visiting, you unblocked a major performance issue due to how the O3 RefApp was originally defining Active Visits (or maybe it was only specifically the esm-active-visits-app). What was the logic that you use at Ampath?
@eudson - I know at OHRI you folks have some concerns around
@slubwama how are “Active Visits” defined in UgandaEMR?
@ddesimone & @tanderson have you encountered varying “Active Visits” definitions across the different sites PIH serves? How so?
Re. Requirements, and to answer your questions:
I see 3 main use cases:
A) Outpatient*
B) Outpatient who gets admitted: Came for a short visit but was so sick they get transferred to an inpatient ward. I assume this is usually considered the same visit, right @ball? Or would you end the “Clinic Visit” and start a “Hospital Visit”?
C) Inpatient: @ibacher have we checked how Bahmni is handling this?
@gurpreet or @akhilmalhotra any thoughts?
*Note: to accomplish the outpatient-ness of visits without forcing users to click “end visit”, many OMRS teams have a script that automatically ends visits every night at midnight (I believe I’ve heard this from at least @corneliouzbett and @ddesimone). Even ignoring the click-work, often it’s almost logistically impossible to have someone click “end visit” manually, eg if the patient goes from the clinician’s office straight to the pharmacy and then leaves - who is supposed to stop that patient just to click a box?
This makes sense to me. Even if an inpatient is transferred to a new department (eg from a Medical Floor to the Oncology Ward), it’s all the same “visit”, just a different “encounter”. @ball made a really helpful video explaining this that I still refer to: (Skip to 6:14 for the Visits vs Encounters explainer)
(@eudson this video actually nicely explains what I’ve mentioned before about Encounters vs Visits, especially at the 8minute-mark)
It feels like we should have an explicit, standard spot somewhere in code where this is defined. So that part of your Config exercise defines an “Active Visit”. Maybe this is even literally in a file in the parent config file. Maybe just with SQL. @dkayiwa what do you think? Have you seen an approach like this before?
IMHO: No!! And actually @slubwama showed me how UgEMR already handles this automatically: when a clerk clicks “Check-In” in the UgEMR Queue workflow, it does 2 things: 1) starts a relevant Visit type for that area, and 2) starts an encounter-type relevant to the queue the patient is sent to. This means any time the patient is moved to a new area (eg from triage to clinician to dentist to pharmacy etc), that encounter type is closed, and the next one is started, automatically. (This also helps UgEMR track encounter-specific wait-times, so that the relevant area can learn they need to improve.) So in Use-Case B) above, if we did want to start a different visit when an outpatient becomes admitted, clicking something like “Admitted” should be able to end “Clinic Visit” and start “Hospital Visit”.
Just some of my opinions and notes on what we do in the PIH EMR:
An Active Visit is always a visit without an visit end date. I feel like this should be the logic everywhere. Each implementation can handle how they close visits.
At PIH we close visits with an automated script that is constantly running. It has some edge cases but essentially it closes all visits for which there has been no activity (no obs or encounters, I think) in the past 12 hours EXCEPT for visits with an admission without a discharge. It closes them as of the last time of activity. This means that outpatient visits will close each day and inpatient visits will not close until someone explicitly discharges them. We have a discharge encounter for this.
Yes, if a patient starts at an outpatient location and then is admitted, that is the same visit. They can be transferred around between inpatient locations within that visit.
It’s not a bad idea to have a check-out function that will close the visit in real-time. I can see some facilities having this part of the patient workflow - to visit a check-out desk that may include billing, referrals etc… But I don’t think the system should totally rely on that to close visits. I think wherever visits are used, there should be an automated way to close them.
The system should not allow overlapping visits. I.e. check-in or “start a visit” functions should be available to a patient with a current active visit.
We do sometimes have issues with admitted patients not being discharged on the system when they are actually discharged. (then when the patient shows up a month later for a follow-up the system thinks they are still admitted) We need to do a better a job with monitoring this data. Tools for this could be 1) reporting or an inpatient dashboard showing all admitted patients along with how long they have been admitted 2) perhaps logic in the automation script to close even admitted patients after a certain amount of time (30 days?) 3) tools to manipulate visits manually such as “merge visits” (which we have on our EMR) and “split into multiple visits” (which we do NOT currently have but which would be nice)
multiple encounters on the same day get counted as visits in the non-technical sense for analytics.
many MOH supported hospitals use visits, but not systematically.
We intend to add visits as part of inpatient which get completed by either a discharge form or after x hours (often >24) from the last encounter on the visit. Currently something like this for discharges exists in the billing functionality, but it does not use the built-in OpenMRS functionality. Something done there that may be helpful to copy is that certain encounters/forms automatically start visits.
In every case where the system can infer what to do, we shouldn’t bother the user – if an implementation always adds encounters to the open visit or always creates a separate visit for certain types of encounters, then we shouldn’t be prompting the user to do what the system should know to do.
Visits do more than simply group encounters. They may be used for accounting or other purposes which may vary by implementation, so we can’t come up with one business rule that will meet every implementation’s needs. We can implement the most common approach, but implementations should be able to override it.
While it may be reasonably safe to assume a patient can’t have more than one active inpatient visit (hospitalization) at the same time, I don’t think we can universally say a patient can’t have an outpatient visit during an inpatient visit or multiple concurrent outpatient visits. We might adopt these approaches out of the box, but our code shouldn’t assume there can never be more than one active visit.
There are two related business rules here:
When should a visit be opened or closed.
Which visit should this encounter be associated with.
Our original intent was to have an implementation-overridable business rule (API method) to get the current visit for a given encounter. The method could return an existing visit, return an empty list (if a visit must first be created manually), or two or more visits if the corresponding visit is ambiguous.
The simple rule is create a visit when there’s a new encounter and no open visit and return the open visit(s) if any are open.
