(feat) O3-3847 - Ward App - implement patient search to admit patient #1426
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
chibongho
requested review from
mseaton,
mogoodrich,
denniskigen,
vasharma05,
ibacher and
usamaidrsk
|
Size Change: -11.4 kB (-0.16%) Total Size: 7.22 MB
ℹ️ View Unchanged
|
chibongho
force-pushed
the
ward-patient-search
branch
from
d7d343d to
3ff36ca
Compare
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
Summary
This PR implements basic patient search in the ward app to admit a patient. It handles cases (albeit not very gracefully) when the patient already has an admission, a pending admission request, or no active visits.
Some things that would have been nice, but not implemented in this PR:
For a patient with active visit in the search result, there should ideally be a button to perform the "admit patient" action. (If the backend bed management module is installed, the user is prompted for the bed to assign patient to; else, the patient is admitted directly.) Instead, clicking on the patient (an unlabeled button) brings the user to a separate workspace with the "admit patient" button. There is ongoing redesign work to make the search result patient unclickable, but include labeled actions to perform.
When clicking on a patient with no active visit in the search result, there should ideally be a way for the user to start a new visit along with admitting the patient. However, with ongoing discussions around RDE, any visit-dependent workflow (such as adding patient to ward, adding patient to queue) will likely change. Instead, this PR just shows a message telling user to create a visit first.
After clicking on a search result patient, the "Back to search result" button should ideally go back to the previous search result. Instead, it opens another search patient workspace with no results and no (previously entered) search term. The service queues app actually have this implemented, but does so is a bit convoluted (duplicate states across components / extensions). I filed O3-4300 to refactor it along with getting this to work in the ward app.
Screenshots
Happy path to add a patient with no admission or pending admission request:
https://github.com/user-attachments/assets/12611bee-cad1-4852-8cd3-4ffc51f4a4a8
Searching for a patient that is already admitted in the current location. The admit button is disabled:
https://github.com/user-attachments/assets/8c10605d-de6e-4ebf-996b-5aa8a5f3abb6
Searching for a patient with an admission elsewhere and a pending admission request. (Those 2 things are independent; this patient just happens to have both). The admit button is enabled, but shown with inline warning notifications.
https://github.com/user-attachments/assets/17989d16-72af-4bcb-b9bd-6207ab4e7e4a
Searching for a patient with no active visit. User is prompted to create visit for patient first:
https://github.com/user-attachments/assets/8e5f4d8f-9456-46ea-9552-c637c5a92992
Related Issue
Other
This PR is rebased on top of #1424, which fixes some unit tests with bad test data that failed in the new year.