Testing HL7 v2 MRG-3: What Prior Alternate Patient ID Actually Needs to Handle
A patient merged in the EHR can still have an orphaned record sitting in a lab or scheduling system, because MRG-3's alternate ID never made it into that system's reconciliation logic.
MRG-3 holds a secondary identifier that belonged to the losing patient record, separate from the primary MRN carried in MRG-1. It exists because a duplicate record can be known to more than one system under more than one ID scheme — a feeder lab system, a legacy scheduling platform, a regional HIE. When present, MRG-3 tells downstream systems which of their own local identifiers now needs to be pointed at the surviving patient.
What this field contains
Example
This synthetic example omits MRG-3 to show a common real-world case — many merge messages leave it blank because the losing record had no alternate ID from an external system.
Where this trips people up
Because MRG-3 is empty far more often than it's populated, some integrations never build a code path to handle it at all — until a merge involving a patient with a legacy feeder-system ID arrives and the alternate identifier is dropped on the floor. The system of record updates cleanly, but the feeder system never learns its own local ID is now stale. Test coverage should deliberately include a populated MRG-3 alongside the far more common blank case.