Details
-
New Feature
-
Status: Closed
-
Must
-
Resolution: Fixed
-
None
-
Low
-
Order Entry 1.10 Iteration 5
Description
Orders are technically immutable, merge patients moves orders to the preferred patient by setting them as the patient on the orders that previously belonged to the loser which is we need to stop and in any case this would fail in 1.10.
We don't have and won't do this in 1.10 but the correct way is to clone the unvoided orders and associate the cloned orders to the preferred patient and then void the original unvoided ones. So the user has to be asked explicitly to first move the orders to the new patient in which will do the voiding and cloning of the unvoided orders to the preferred patient, this could still happen in merge patient
TODOs:
- Merge patients should fail loudly if the losing patient has any unvoided orders, the voided orders should never be moved.
- Update unit tests and ensure they still pass
- Create a follow up ticket to update PatientService.mergePatients to do the correct thing in the future
Extra credit:
- Update the merge patient to inform the user and disable the merge button whenever a patient is selected as not preferred and has any unvoided orders.
Gliffy Diagrams
Attachments
Issue Links
- is depended on by
-
TRUNK-4336 Disable Hibernate cascading for Encounter.orders and Obs.order
-
- Closed
-