The MRG segment carries the prior (incorrect or duplicate) patient and visit identifiers that are being merged into, or replaced by, the surviving identity. It always travels with a PID segment: PID names the patient that survives, MRG names the identifiers that should be retired and pointed at the survivor. Every downstream system reads MRG to reconcile its own records to the correct patient.
Purpose
MRG exists for one job: reconciliation. When two records describe the same person, or an identifier was issued in error, the message states the surviving identity in PID and the prior identity in MRG. Receivers use the prior patient identifiers, account number, and visit numbers to find their local records and re-link them to the PID identity. MRG never appears on its own — it is meaningful only as the "from" side of a merge paired with a PID "to" side.
Used in
MRG appears in ADT patient-merge events: merge patient identifier (A18), merge patient information (A30), unlink/merge patient information (A34), and merge patient — patient identifier list (A40). These events deliver a PID/MRG pair so the receiver can collapse the prior identity into the surviving one. See ADT.
Field-by-field reference
Source: the Vorro HL7 segment database (extracted from the official v2-to-FHIR IG). R = required (cardinality min ≥ 1). Repeat = field may repeat. Length is not carried by the FHIR source and is shown as —.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| MRG-1 | Prior Patient Identifier List | CX | — | R | Y | — | The prior patient identifier(s) being merged away. |
| MRG-2 | Prior Alternate Patient ID | CX | — | R | Y | — | Prior alternate patient identifier(s) retired by the merge. |
| MRG-3 | Prior Patient Account Number | CX | — | O | — | — | Prior account number to re-link to the survivor. |
| MRG-4 | Prior Patient ID | CX | — | O | — | — | Single prior patient identifier (legacy form). |
| MRG-5 | Prior Visit Number | CX | — | O | — | — | Prior visit/encounter number being merged. |
| MRG-6 | Prior Alternate Visit ID | CX | — | O | Y | — | Prior alternate visit identifier(s). |
| MRG-7 | Prior Patient Name | XPN | — | O | Y | — | Prior patient name(s) for verification. |
Most-used fields
- MRG-1 Prior Patient Identifier List is the field that matters in nearly every merge: it is the identifier the receiver searches on to find the record to retire and re-point at the PID identity.
- MRG-3 Prior Patient Account Number drives account-level merges and is the only MRG field with a published FHIR target.
- MRG-5 Prior Visit Number lets a receiver reconcile a specific prior encounter, not just the patient, to the surviving identity.
- MRG-7 Prior Patient Name is used defensively — receivers compare it to the prior record's name to confirm they are retiring the right one.
Version differences (2.3 to 2.8.2)
- 2.3: MRG-4 Prior Patient ID and MRG-7 Prior Patient Name present; early merge events (A18, A30, A34) defined.
- 2.3.1/2.4: MRG-5 Prior Visit Number and MRG-6 Prior Alternate Visit ID added for visit-level reconciliation; A40 merge by identifier list introduced.
- 2.5+: identifier fields settle on
CX; MRG-4 retained mainly for backward compatibility as MRG-1 (the list form) becomes the primary identifier carrier. - 2.7+: field set is stable; receivers built for 2.3 ignore the trailing visit fields they do not recognize.
Common mistakes
- Treating MRG as standalone — it is only meaningful paired with the PID that names the surviving identity.
- Confusing direction: PID is the survivor (the "to"), MRG is the prior record (the "from"). Reversing them merges the wrong way.
- Reading only the first repetition of MRG-1 when several prior identifiers must all be retired.
- Merging on patient identity but ignoring MRG-5, leaving orphaned prior visits unreconciled.
- Dropping MRG-3 and failing to re-link the prior account, so balances stay on the retired record.
Examples
Minimal valid MRG (only the required prior identifier):
MRG|MR99999^^^MERCYGEN^MR
Fully-populated MRG:
MRG|MR99999^^^MERCYGEN^MR~MR99998^^^MERCYGEN^MR|ALT99999^^^MERCYGEN^ALT|ACC55555^^^MERCYGEN^AN|MR99999|V0099^^^MERCYGEN|AV0099^^^MERCYGEN|DOE^JON^Q
Annotated breakdown of the fully-populated example:
MRG ← segment ID
MR99999^^^MERCYGEN^MR~... ← MRG-1 Prior Patient Identifier List (repeats)
ALT99999^^^MERCYGEN^ALT ← MRG-2 Prior Alternate Patient ID
ACC55555^^^MERCYGEN^AN ← MRG-3 Prior Patient Account Number
MR99999 ← MRG-4 Prior Patient ID
V0099^^^MERCYGEN ← MRG-5 Prior Visit Number
AV0099^^^MERCYGEN ← MRG-6 Prior Alternate Visit ID
DOE^JON^Q ← MRG-7 Prior Patient Name
In-context inside an ADT^A18 (merge patient information), PID = survivor, MRG = prior:
MSH|^~&|REG|MERCYGEN|EHR|MERCYGEN|20260609120000||ADT^A18^ADT_A18|MSG201|P|2.5.1
EVN|A18|20260609120000
PID|1||MR12345^^^MERCYGEN^MR||DOE^JOHN^Q||19800101|M
MRG|MR99999^^^MERCYGEN^MR|||MR99999
In-context inside an ADT^A40 (merge patient — patient identifier list):
MSH|^~&|REG|MERCYGEN|EHR|MERCYGEN|20260610081500||ADT^A40^ADT_A39|MSG202|P|2.5.1
EVN|A40|20260610081500
PID|1||MR12345^^^MERCYGEN^MR||DOE^JOHN^Q||19800101|M
MRG|MR99998^^^MERCYGEN^MR~MR99997^^^MERCYGEN^MR|||MR99998|V0099^^^MERCYGEN
FHIR mapping
Primary target resource: Account. The published ConceptMap maps only one field, with the segment's presence driving the Account status: MRG to Account.
| MRG field | FHIR target (Account) |
|---|---|
| MRG (segment present) | Account.status (fixed unknown) |
| MRG-3 Prior Patient Account Number | Account.identifier (CX → Identifier) |
Unmapped fields: MRG-1, MRG-2, MRG-4, MRG-5, MRG-6, and MRG-7 have no published target on Account. They carry prior patient and visit identity that a v2-to-FHIR pipeline typically handles as a link/merge operation against existing Patient and Encounter resources (for example, marking the prior Patient with link of type replaced-by) rather than as fields on Account. That linkage is not expressed in the official MRG-to-Account ConceptMap.
Engine considerations
- Required in practice: MRG-1 (and often MRG-2) must be present; engines should reject a merge event whose MRG carries no prior identifier.
- Always process MRG together with the PID in the same message — never queue or route them apart, or the merge direction is lost.
- Preserve all repetitions of MRG-1, MRG-2, MRG-6, and MRG-7 as arrays; a single merge may retire several prior identifiers.
- Make the re-link idempotent: a merge may be re-delivered, and applying it twice must not corrupt the surviving record.
- Decompose
CXso assigning authority and identifier-type components survive when matching local records.
How Vorro parses and produces MRG
Vorro treats an MRG/PID pair as a single merge transaction: PID identity is the survivor, every MRG-1/MRG-2 repetition is resolved to a local record, and prior account (MRG-3) and visit (MRG-5/MRG-6) numbers are re-linked to the surviving patient and encounter. On the FHIR side Vorro sets Account.status and maps MRG-3 to Account.identifier per the official ConceptMap, and additionally emits Patient.link (replaced-by) so the retired identities point at the survivor. Merges are applied idempotently so redelivery is safe.
Related pages
- PID — names the surviving patient the merge resolves to.
- PV1 — the visit context whose prior numbers MRG-5/MRG-6 reconcile.
- ADT messages — where MRG drives the A18, A30, A34, and A40 merge events.
