(feat) Core support for O3-2242: Separate 'active visit' and 'current visit' #738
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
3 tasks
|
Size Change: -209 kB (-8%) ✅ Total Size: 2.28 MB
ℹ️ View Unchanged
|
|
So, technically, the code here is great. I've got a conceptual niggle with this, though. Technically, it's a configurable option whether overlapping visits are allowed or not (and, by default in the RefApp, we allow overlapping visits). That means, its perfectly plausible for a patient to have two "active" visits and a user might need to switch between them. The use-case for multiple active visits is cases where a user switches between services; e.g., a patient on a mental health ward may have a medical issue and be admitted to a clinical care unit; they haven't ended their mental health visit, but also the clinical care visit is separately managed care because when they are discharged from the clinical care unit, they are being discharged back to the mental health ward. The simplicity of having a "current" visit kind of allows us to hide those details, but it does mean that when existing "retrospective" mode, we need a way for the user to be put back in the state they were in before. Could we do something with, e.g., a stack of visits maybe so when you exit retrospective mode it pops the retrospective visit, and the current visit now points to an active visit? Or alternatively, prompting users? Because so many OpenMRS facilities are run as HIV clinics, this isn't a common case across the community, but there are implementations that provide mental health services that have exactly the concern I outlined above. |
|
Yeah that makes sense @ibacher . However we don't really have UI support for multiple active visits and so I'm not inclined to build anything specific for that in Core until we have some vague idea of how we actually expect users to interact with them. Right now there's not even a way to enter RDE mode (that I'm aware of) when the patient has an active visit. The content of this PR seems like a safe bet to me though. Current visit sets the user context. Active visit seems likely to become an array "active visits" in the future. But we can jump that hurdle when we get to it. Does that seem like a fine approach, or are there changes you would like to see that you think are reasonable to include in the scope of this PR? |
ibacher
approved these changes
Jul 26, 2023
|
It's a good point. We should keep the scope here as limited as possible. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Requirements
For changes to apps
If applicable
Summary
Creates separate "active visit" and "current visit" returns from
useVisit. This will allow us to have the user go between retrospective entry and entry on an ongoing visit.Screenshots
Related Issue
https://issues.openmrs.org/browse/O3-2242