HL7 v2 MRG Segment Guide: Fields, Format, and Testing Gotchas
MRG carries the identifiers of the patient record being erased, not the one surviving the merge, and a surprising number of integrations get that direction backwards on the first pass.
MRG (Merge Patient Information) shows up in patient-merge ADT messages, most often an A34 or A40, and it holds the old identifiers of a duplicate record that's being folded into the patient described by the message's own PID segment. Everything in MRG points at the record being retired; everything in PID points at the record that survives. Mixing that up is the single most common way MRG handling breaks.
The fields that actually matter in practice
Example
A synthetic MRG segment showing a retiring MRN, alternate ID, and account number folding into the surviving patient named in the same message's PID segment — invented for this example, not from any real patient or facility.
Where this trips people up
The direction of a merge is implicit in segment placement, not stated anywhere in plain language: MRG describes the loser, PID describes the winner. Test suites that build MRG messages by copying a PID segment and renaming it often get this backwards, and code that reads MRG-1 expecting the surviving MRN will silently retire the wrong record. A second, quieter failure mode is incomplete cleanup — a receiving system updates the patient index but leaves orders, results, or scheduled visits still pointing at the old identifier from MRG-7 or MRG-4, because those field values only mattered for the duration of the merge event and nothing forces a system to trace every downstream reference.