Visits that spans across multiple days

Hello,

I’m trying to understand what’s OpenMRS 3 status regarding allowing “multiple day visits”. Currently, by looking at the way the active visit is determined on esm-core, it seems that visits must start and end within the same day.

Is there currently any development being done or planned in order to support having an active visit span across multiple days?

Not sure who to tag here. @grace @ibacher any feedback on this will be appreciated. Thanks!

Thank you @icrc.psousa for kicking this off. Pulling in @dennis - can you help here with the frontend piece, and @dkayiwa can you help w/ the backend context?

My initial reaction was that O3 should handle multi-day visits exactly the same as any other OMRS platform since we’re all on the same backend.

But then I’m a bit surprised by the stopDatetime condition you discovered in esm-core. I suspect the only reason for this is because @vasharma05 needed a way to limit/daily refresh the patients showing up in the Active Visits list so that it didn’t become super long; or perhaps because @corneliouzbett found that trying to maintain this list caused ++ compute cost - because you see @icrc.psousa many sites do not use the “End Visit” feature, so many outpatient implementations have logic that auto-ends visits at midnight. Of course that doesn’t make sense for inpatient care.

I agree we should not be blocking folks from multi-day visits, and having that blocker in esm-core feels wrong to me - @dennis what do you think?

The backend allows you to have multiple day visits. Configuring Visits · GitBook

1 Like

A while ago we had > 6.4 million active visits list. The ActiveVisit app tried to load these records but it always crashed, so we limit the active visits list per location and “today’s” visits. I’d agree we should be supporting multiple-day visits. However, I’d recommend leveraging the backend paging in favor of data-table pagination.

1 Like

Agreed

Auto-ending visits (just like deciding which visit a new encounter belongs) is an implementation-specific business rule. As such, we won’t be able to come up with one rule that meets everyone’s needs. Instead, the backend would ideally implement the most common approach using a strategy pattern so implementations can easily override the behavior with their custom business rules.

1 Like

@dkayiwa do you mean that if we don’t check the “Start auto close” option we should be able to create multi-day visits ? I check our configuration and it’s not checked

The backend supports multi-day visits, but the hook @icrc.psousa points to makes it so those visits are effectively “invisible” to the frontend.

Basically, to echo what @burke said, we probably need an API endpoint that can be called with a patient and return the active visit(s) for the patient, but allowing an implementation to supply whatever logic it wants to use to determine the “active” visit (the current “includeInactive” basically excludes visits where the stopDatetime is prior to the moment the query is run—which brings up another class of valid visits our current frontend would be unable to “see”, namely those that are active but with a scheduled end time).

PS This broader support for “the current visit for the current patient” is orthogonal to the “Active Visits” list. There is some additional frontend logic necessary, e.g., to support useVisit correctly returning the current visit, even if that’s a past visit (to support retrospective data entry).

To be clear, I did not mean to imply that implementations come up with their own definition of active visits (visits are still active until end date is set and in the past); rather, that implementation business logic be used to auto-end visits (i.e., optionally set the end date on visits either in a scheduled task and/or when active visits are requested).

We should still be able to rely on judging active visits by the start & end dates.

Well, I’m actually thinking there may be context-specific ways for implementations (who care about it) to determine the “active” visit for a patient based on implementation-specific logic. The way we ended up with this hook (AFAICT) is that AMPATH uses visits, but mostly without any end-dates. Consequently, most visits are (from the perspective of our default logic) “active”. However, since AMPATH services are generally outpatient settings, the only relevant visit is that from the current day, hence the logic currently embedded in the frontend. My suggestion is more for having a way to enable implementations to make these context-sensitive decisions without the current hard-coding we have. (See also Bett’s remark about having 6.4 million “active” visits).