When voiding an Encounter object, all top level Obs and Orders are also voided with same reason; when unvoiding a voided Encounter, all the Obs and Orders which were voided along with Encounter are also supposed to be unvoided. The problem is this:
Suppose there's an encounter X with Observations A, B and C.
- C was voided with reason "Duplicate".
- Later, it was found that Encounter X was also a duplicate, thus it was voided with reason "Duplicate".
- The data operator later came to know that Encounter X was a false positive, so he unvoids it.
- Now, Obs A and B should be unvoided but C should remain voided (because it was a valid void)
What's happening is that – I found out while digging in – the unvoidEncounter method in EncounterServiceImpl checks for "Reason" alone, and does not take the Date voided into account.
We could do something like:
This approach should match with more precision exactly which Observations to unvoid.
I only observed unvoiding encounters, this fix may require thorough review of other entities.