HL7 ADT_A30 (Merge Person Information) | Integration Soup HL7 Reference Guide

HL7 ADT_A30 Merge Person Information

An older MPI-style person merge event, mostly kept for compatibility.

HL7 message structure ADT_A30 groups and segments from HL7 v2.5.1 Hide structure

These are the generated groups and segments for the version selected at the top of the page. The article explains the workflow, and this panel follows the chosen HL7 version.

Message Structure

Segment	Name	Required	Repeatable
MSH	Message Header	Yes	No
SFT	Software Segment	No	Yes
EVN	Event Type	Yes	No
PID	Patient Identification	Yes	No
PD1	Patient Additional Demographic	No	No
MRG	Merge Patient Information	Yes	No

ADT_A30 is the legacy merge-person-information event. It was used for MPI-style person merges, where a person record was duplicated and one identity needed to survive. In modern v2 interfaces, more specific patient identifier list merge messages are usually preferred.

If you still receive A30, treat it with the same caution as any identity merge. It can affect patient search, demographics, document indexing, encounter correlation, and any cross-reference table downstream.

A small A30 example

MSH|^~\&|MPI|CITYHOSP|EHR|CITYHOSP|20260715143500||ADT^A30^ADT_A30|ADT300001|P|2.5.1 EVN|A30|20260715143400 PID|1||E123456^^^ENTERPRISE^PI||Smith^Jane^Anne^^Ms^^L||19800314|F MRG|E999888^^^ENTERPRISE^PI

What systems do with it

The sender is usually an MPI or enterprise identity service. Receivers interpret PID as the target identity and MRG as prior identity information, subject to the local profile's exact merge semantics.

Because A30 has been retained for backward compatibility, many current receivers either do not support it or translate it internally into a more precise merge workflow before applying it.

How to read the structure

The structure is short: MSH, optional SFT, EVN, required PID, optional PD1, and required MRG. There is no required visit group because the event is aimed at person identity, not a specific encounter.

Implementation traps

The trap is accepting a broad legacy merge without profile rules. Require assigning authority, identifier type, and merge direction to be clear. If a trading partner can send A40 instead, that is usually easier to reason about and test.

Reference notes

HL7 terminology marks A30 as deprecated, and older v2 chapter text says A30 was retained for backward compatibility. The local v2.5.1 data includes the structure so legacy feeds can still be documented.