HL7 MRG Merge Patient Information
HL7 field reference MRG fields from HL7 v2.5.1 Show fields
These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.
Fields
| Field | Name | Required | Repeatable | Type | Table |
|---|---|---|---|---|---|
| MRG.1 | Prior Patient Identifier List | Yes | Yes | CX | 0061 |
| MRG.2 | Prior Alternate Patient ID | No | Yes | CX | 0061 |
| MRG.3 | Prior Patient Account Number | No | No | CX | 0061 |
| MRG.4 | Prior Patient ID | No | No | CX | |
| MRG.5 | Prior Visit Number | No | No | CX | |
| MRG.6 | Prior Alternate Visit ID | No | No | CX | |
| MRG.7 | Prior Patient Name | No | Yes | XPN |
MRG carries the prior patient, visit, account, or alternate identifiers used in merge, change, and unlink events.
The standard describes MRG this way: The MRG segment provides receiving applications with information necessary to initiate the merging of patient data as well as groups of records. It is intended that this segment be used throughout the Standard to allow the merging of registration, accounting, and clinical records within specific applications. The assigning authority, the fourth component of the patient identifiers, is an HD data type that is uniquely associated with the assigning authority that originally assigned the number. A given institution, or group of intercommunicating institutions, should establish a list of assigning authorities that may be potential assignors of patient identification (and other important identification) numbers. The list will be one of the institution's master dictionary lists. Since third parties (other than the assignors of patient identification numbers) may send or receive HL7 messages containing patient identification numbers, the assigning authority in the patient identification numbers may not be the same as those of the sending and receiving systems identified in the MSH. The assigning authority must be unique across applications at a given site. This field is required in HL7 implementations that have more than a single Patient Administration application assigning such numbers.
Patient-administration segments add detail around the person, visit, account, diagnosis, procedure, insurance, merge, death, disability, and grouping state carried by the message.
These fields often drive matching, billing, encounter routing, reporting, and front-desk workflow. Separate patient identity, visit identity, account identity, and clinical facts carefully.
The v2.5.1 structures show MRG in ADT_A06 - Change an outpatient to an inpatient, ADT_A18 - Merge patient information, ADT_A30 - Merge person information, and ADT_A39 - Merge person - patient ID, and 3 other message structures. That tells you where it can appear, but the implementation guide still decides which optional fields are meaningful.
For practical interface work, read the generated field panel for datatype, required, repeatable, and table details, then use the notes below to decide what the field should mean in the receiving workflow.
MRG-1 identifies the Prior Patient Identifier List for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
If there are several identifiers, use repetitions deliberately and make each repeat self-explanatory rather than relying on position alone.
MRG-2 identifies the Prior Alternate Patient ID for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
If there are several identifiers, use repetitions deliberately and make each repeat self-explanatory rather than relying on position alone.
MRG-3 is used for reconciliation. The receiver may compare it with the segments, batches, messages, rows, or items actually received, so do not populate it from a stale estimate.
The generated panel links this to HL7 table 0061; many real interfaces narrow that list further, so follow the receiver's implementation guide.
MRG-4 identifies the Prior Patient ID for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
MRG-5 identifies the Prior Visit Number for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
MRG-6 identifies the Prior Alternate Visit ID for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
MRG-7 identifies a person, provider, staff member, or contact involved in this patient-administration workflow. Use the structured name or provider datatype instead of flattening everything into display text.
When more than one person is sent, repeats should carry role or identifier context so the receiver can tell who did what.
Related links
- PID - Patient Identification
- PD1 - Patient Additional Demographic
- PV1 - Patient Visit
- PV2 - Patient Visit - Additional Information
- DG1 - Diagnosis
- DRG - Diagnosis Related Group
- PR1 - Procedures
- IN1 - Insurance
- IN2 - Insurance Additional Information
- IN3 - Insurance Additional Information, Certification