HL7 ADT A30 Message: Merge Person Information, Structure, Segments & Examples

The HL7 A30 message is an Admit, Discharge, Transfer (ADT) event used to communicate the merging of person information records in healthcare systems. Known as ADT A30 or Merge Person Information, it helps connected applications reconcile duplicate person records when an authorized identity management workflow determines that they represent the same individual.

A30 belongs to the HL7 Version 2 patient administration message family. It is particularly relevant to enterprise master patient indexes, patient registration systems, and applications that maintain person-level information independently of individual visits.

Correct implementation matters because an incorrect merge can associate clinical or administrative information with the wrong person. This guide explains HL7 A30 structure, PID and MRG segments, message examples, Mirth Connect processing, acknowledgments, troubleshooting, and best practices.

What Is an HL7 ADT A30 Message?

An HL7 ADT A30 message communicates the merging of person information from one identity record into another. The event is used when an authorized source system identifies duplicate person records and establishes which identity should remain authoritative.

The receiving application uses the message to identify the surviving person record and the prior record involved in the merge. The precise treatment of identifiers, demographics, and associated information depends on the interface specification.

A30 is distinct from an A28 person creation event or an A31 person information update. Understanding these differences within the broader HL7 ADT messaging framework helps prevent incorrect identity processing.

Purpose of the HL7 A30 Event

A30 communicates an authorized person information merge between two identity records. Receiving applications use the event to reconcile duplicate identities according to their supported merge workflows.

When Is an ADT A30 Message Generated?

An A30 notification may be generated after identity management staff or an approved master patient index workflow confirm that two person records represent the same individual.

Which Healthcare Systems Receive A30 Messages?

Enterprise master patient indexes, EHRs, patient registration applications, and healthcare data platforms may receive A30 notifications when they support person-level identity merging.

How A30 Supports Patient Identity Management

A30 helps connected systems maintain consistent person identities after duplicate records have been reconciled. Correct processing reduces fragmented demographic information and inconsistent patient searches.

Why Accurate A30 Processing Matters

An incorrect merge can associate information with the wrong person and create significant patient safety risks. Reliable integration requires authoritative identifiers, merge authorization, and detailed audit controls.

HL7 ADT A30 Message Structure and Segments

An HL7 ADT A30 message follows the segment-based format defined by HL7 Version 2. In HL7 v2.5, the A30 trigger event uses the ADT_A30 message structure.

The key segments are MSH, EVN, PID, and MRG. MSH identifies the merge event and source application, EVN records event metadata, PID identifies the surviving person record, and MRG identifies the prior person record involved in the merge.

Additional segments may appear depending on the applicable HL7 version and implementation profile. Receiving systems must interpret PID and MRG consistently so the merge direction is not reversed.

MSH Segment: Message Header

MSH identifies the sender, receiver, message timestamp, control identifier, and HL7 version. MSH-9 identifies A30 as the merge person information trigger event.

EVN Segment: Event Information

EVN contains event metadata, including the recorded timestamp. Receiving applications can use it to audit the merge and investigate the sequence of identity changes.

PID Segment: Surviving Person Identification

PID identifies the person record that remains after the merge. The receiving application should match its complete identifier and assigning authority before processing.

MRG Segment: Prior Person Identification

MRG identifies the prior person record being merged into the surviving record. Correct interpretation of MRG-1 is essential to preserving merge direction.

Optional Segments and Implementation Profiles

Some interfaces carry additional demographic or administrative context. Receiving applications should process optional fields only as defined by the agreed HL7 implementation guide.

HL7 ADT A30 Message Example With Field Explanation

The following HL7 ADT A30 example illustrates the merging of two fictional person records. The message uses HL7 v2.5 conventions and identifies ADT^A30^ADT_A30 in MSH-9.

PID-3 contains the surviving person identifier, while MRG-1 identifies the prior record being merged. The example assumes that an authorized identity management process has already confirmed that both records belong to the same individual.

Receiving applications should verify the identifiers, preserve an appropriate audit history, and reconcile associated information according to the destination's approved merge workflow.

Complete HL7 ADT A30 Sample Message

MSH|^~\&|MPI|HOSPITAL|EHR|MAIN|20261013160000||ADT^A30^ADT_A30|MSG30001|P|2.5
EVN|A30|20261013155500
PID|1||P300001^^^HOSPITAL^MR||BROWN^MICHAEL||19820912|M
MRG|P300002^^^HOSPITAL^MR

All patient information is fictional. In this example, P300001 is the surviving identifier and P300002 is the prior identifier. The intended operation is to merge the prior person information into the surviving person record.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies MPI as the sending application and EHR as the receiver. ADT^A30^ADT_A30 identifies the merge event and message structure.

EVN Segment Explained

EVN identifies A30 as the event and records its timestamp. Integration teams can use this information to investigate when the merge was initiated.

PID-3: Surviving Person Identifier

PID-3 contains the surviving person identifier, P300001. Receiving applications should match this identifier accurately before applying the merge.

MRG-1: Prior Person Identifier

MRG-1 contains the prior person identifier, P300002. The destination should recognize this as the record being merged into the surviving identity.

Understanding Merge Direction

The merge direction is from the prior identifier in MRG to the surviving identifier in PID. Reversing this relationship can cause incorrect patient identity consolidation.

Important HL7 ADT A30 Fields and Mapping

Reliable HL7 A30 integration depends on correct merge direction, complete patient identifiers, and consistent handling of related records. MSH-9 identifies the merge event, MSH-10 supports message tracking, PID-3 identifies the surviving person record, and MRG-1 identifies the prior record. EVN-2 provides event timing information.

Receiving applications should validate assigning authorities and identifier types rather than comparing identifier values alone. They should also define how aliases, demographics, encounters, and other associated information are reconciled. Clear HL7 v2 integration specifications reduce the risk of merging unrelated identities.

MSH-9: Identifying the Merge Event

MSH-9 identifies A30 as the trigger event. Integration engines should route the message through person merge processing rather than deletion or demographic update workflows.

PID-3: Identifying the Surviving Person

PID-3 identifies the person record that remains authoritative after the merge. Receiving systems should validate the complete identifier and assigning authority.

MRG-1: Identifying the Prior Person

MRG-1 identifies the record being merged. Incorrect mapping of this field can reverse the intended merge and associate information with the wrong identity.

MSH-10: Tracking the Merge Notification

MSH-10 contains the message control identifier. Integration teams use it for acknowledgment correlation, duplicate detection, and auditing of identity merge events.

EVN-2: Recording Merge Timing

EVN-2 records the event timestamp. Receiving applications can use it to investigate delayed merge notifications and conflicts with subsequent identity changes.

How HL7 ADT A30 Messages Work in Healthcare Integration

An HL7 ADT A30 workflow begins when an authorized identity management application confirms that two person records represent the same individual. The source application identifies the surviving and prior records, then generates an A30 notification. An integration engine validates the message and routes it to connected applications.

Receiving systems locate both identities, confirm that the merge is valid, and apply the approved consolidation rules. These rules may affect identifier aliases, demographics, and relationships with other records. Because identity merges can have lasting consequences, reliable processing requires accurate matching, event sequencing, acknowledgment handling, and auditability.

Step 1: Duplicate Person Records Are Confirmed

An authorized identity management process determines that two person records represent the same individual. The workflow identifies which record will remain authoritative.

Step 2: Generate and Validate the A30 Message

The source creates an A30 notification containing the surviving and prior identifiers. The integration engine validates the event, identifiers, and message metadata.

Step 3: Match Both Person Records

The destination identifies the surviving record from PID-3 and the prior record from MRG-1. Ambiguous matches should stop automatic processing.

Step 4: Apply the Authorized Merge

The receiving application applies its supported person merge workflow, preserving required clinical and administrative relationships while maintaining the correct surviving identity.

Step 5: Acknowledge and Audit the Outcome

The destination returns an acknowledgment according to the configured processing mode. Audit records should document the original identifiers, merge direction, and outcome.

How to Implement HL7 ADT A30 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route HL7 ADT A30 notifications between enterprise master patient indexes, EHRs, registration systems, and other healthcare applications. A typical integration receives an A30 message through an MLLP listener, identifies the merge event, extracts surviving and prior identifiers, and forwards the request to an authorized patient identity management service.

Because patient identity merges can affect clinical information, production channels must enforce authorization, validate merge direction, detect duplicates, and maintain an audit trail. Mirth Connect should not directly merge database records without the destination application's approved identity reconciliation workflow. Mirth Connect development services can support these requirements.

Configure the HL7 Source Connector

Create a Mirth Connect channel using an MLLP Listener or another supported transport. Configure HL7 v2 parsing, authenticated connectivity, acknowledgment handling, and appropriate message retention settings.

Filter HL7 ADT A30 Messages

Use a source filter to identify A30 notifications. Keep person merge events separate from patient information updates, record deletions, and unrelated identity management workflows.

Mirth Connect JavaScript filter:

var messageType =
    msg['MSH']['MSH.9']['MSH.9.1'].toString();

var triggerEvent =
    msg['MSH']['MSH.9']['MSH.9.2'].toString();

return messageType === 'ADT' &&
       triggerEvent === 'A30';

This filter only identifies the message event. The production interface must separately verify that the sending application is authorized to initiate person merges.

Extract Surviving and Prior Person Identifiers

Use a JavaScript transformer to extract the identifiers from PID and MRG. Validate assigning authorities and confirm that the two records are distinct.

Mirth Connect JavaScript transformer:

function getComponent(segment, field, part) {
    var fieldName = segment + '.' + field;
    var partName = fieldName + '.' + part;

    return msg[segment][fieldName][partName]
        .toString()
        .trim();
}

var survivingId = getComponent('PID', 3, 1);
var survivingAuthority = getComponent('PID', 3, 4);
var survivingType = getComponent('PID', 3, 5);

var priorId = getComponent('MRG', 1, 1);
var priorAuthority = getComponent('MRG', 1, 4);
var priorType = getComponent('MRG', 1, 5);

var controlId = getComponent('MSH', 10, 1);
var eventTimestamp = getComponent('EVN', 2, 1);

if (!survivingId || !priorId) {
    throw new Error(
        'A30 requires surviving and prior identifiers'
    );
}

if (!survivingAuthority || !priorAuthority) {
    throw new Error(
        'A30 requires both assigning authorities'
    );
}

if (!controlId) {
    throw new Error(
        'A30 missing message control identifier'
    );
}

var survivingKey = [
    survivingAuthority,
    survivingType,
    survivingId
].join('|');

var priorKey = [
    priorAuthority,
    priorType,
    priorId
].join('|');

if (survivingKey === priorKey) {
    throw new Error(
        'A30 cannot merge an identity into itself'
    );
}

var mergeEvent = {
    eventType: 'A30',
    survivingPerson: {
        identifier: survivingId,
        assigningAuthority: survivingAuthority,
        identifierType: survivingType
    },
    priorPerson: {
        identifier: priorId,
        assigningAuthority: priorAuthority,
        identifierType: priorType
    },
    messageControlId: controlId,
    eventTimestamp: eventTimestamp
};

channelMap.put(
    'mergeEvent',
    JSON.stringify(mergeEvent)
);

This example assumes Mirth Connect has parsed the HL7 message into XML. Production implementations should support repeating identifiers, complete assigning-authority components, and the destination's specific matching rules.

Transform A30 Into a Person Merge Request

Create a destination-specific payload identifying the surviving and prior records. The destination should independently validate that the merge has been authorized and that both records refer to the same person.

Example JSON transformation:

var event = JSON.parse(
    channelMap.get('mergeEvent')
);

var mergeRequest = {
    eventType: 'A30',
    action: 'requestPersonMerge',

    survivingPerson: event.survivingPerson,
    priorPerson: event.priorPerson,

    processingStatus: 'pending_validation',

    sourceEvent: {
        messageControlId:
            event.messageControlId,
        eventTimestamp:
            event.eventTimestamp
    }
};

channelMap.put(
    'jsonPayload',
    JSON.stringify(mergeRequest)
);

This JSON payload is illustrative rather than a standardized HL7 API. The receiving identity management service must implement its own authorization, conflict detection, and merge processing.

Validate the Merge Before Destination Processing

Confirm that both records exist, represent the same person, and are eligible for consolidation. Reject ambiguous matches, conflicting identifiers, and merge requests that would reverse an existing identity relationship.

HL7 ADT A30 ACK Message Examples and Error Handling

HL7 acknowledgment messages communicate whether an A30 notification was accepted or rejected under the configured acknowledgment mode. An acknowledgment commonly contains MSH and MSA segments. ERR can provide additional error details.

In original acknowledgment mode, AA indicates application acceptance, AE indicates an application error, and AR indicates rejection. For identity merge workflows, the interface agreement should define whether an acknowledgment confirms message acceptance, successful validation, or completion of the destination merge. An AA response should not be interpreted as proof that every downstream application has finished reconciling its records.

Successful ACK Response: AA

An AA acknowledgment indicates application-level acceptance under the configured processing mode. MSA-2 references the original A30 message control identifier.

MSH|^~\&|EHR|MAIN|MPI|HOSPITAL|20261013160001||ACK^A30^ACK|ACK30001|P|2.5
MSA|AA|MSG30001

Application Error Response: AE

An AE response indicates an application processing error. Unknown identifiers, conflicting identity relationships, or failed validation may prevent the merge from being completed.

MSH|^~\&|EHR|MAIN|MPI|HOSPITAL|20261013160002||ACK^A30^ACK|ACK30002|P|2.5
MSA|AE|MSG30001
ERR|||204^Unknown Key Identifier^HL70357|E

Application Rejection Response: AR

An AR acknowledgment indicates rejection by the receiving application. Unsupported events, unauthorized sources, or invalid message profiles may cause the destination to reject the merge notification.

MSH|^~\&|EHR|MAIN|MPI|HOSPITAL|20261013160003||ACK^A30^ACK|ACK30003|P|2.5
MSA|AR|MSG30001

Correlate ACK Responses With Merge Notifications

MSA-2 references the original message control identifier. Integration teams use it to associate acknowledgments, retries, and destination processing outcomes with the corresponding A30 event.

Handle Duplicate and Failed Merge Requests

Apply idempotency controls and verify the current identity state before retrying. A lost acknowledgment must not cause a second merge or reverse the intended surviving identity.

Common HL7 ADT A30 Integration Errors and Troubleshooting

HL7 A30 integration problems commonly involve reversed merge direction, missing identifiers, incorrect assigning authorities, and conflicts between existing identity relationships. A receiving application may reject the merge because one person record does not exist or because the prior identifier has already been consolidated into another record. Another failure occurs when a destination treats A30 as a routine demographic update.

Troubleshooting should examine the original HL7 message, PID and MRG mappings, identity histories, acknowledgment responses, and destination merge rules. Accurate HL7 parsing and data mapping is essential.

Surviving and Prior Identifiers Are Reversed

Incorrect PID and MRG mapping can reverse the intended merge direction. Verify that PID identifies the surviving record and MRG identifies the prior record.

One Person Record Cannot Be Found

The destination may not recognize one of the identifiers. Check assigning authorities, identifier types, and whether an earlier merge or deletion changed the record's status.

Conflicting Patient Identity Relationships

A record may already be linked or merged with another identity. The receiving application should investigate conflicts before applying additional consolidation.

Duplicate A30 Notifications

Repeated merge notifications may arrive after successful processing. Use message identifiers and current identity relationships to prevent repeated or contradictory merges.

Merge Completes in One System but Fails Elsewhere

Downstream applications may retain outdated identifiers after a merge. Use reconciliation reports, destination monitoring, and controlled retries to restore consistency.

HL7 ADT A30 vs A28, A29, A31, and A40

HL7 patient administration events distinguish person creation, deletion, updates, and identity merging. A28 adds person information, A29 deletes person information, and A31 updates existing person information. A30 communicates a person information merge, while A40 specifically addresses merging patient identifiers in the patient identifier list.

Although A30 and A40 both concern identity consolidation, they belong to different event models and may have different destination processing requirements. Receiving applications should follow the supported HL7 version and interface implementation guide rather than treating all merge events as interchangeable.

A30 vs A28: Merge and Creation

A28 introduces person information, while A30 consolidates existing person identities. Receiving applications should verify both records before processing a merge.

A30 vs A29: Merge and Deletion

A29 communicates person deletion, while A30 merges person information. A merge should preserve the approved surviving identity and associated relationships.

A30 vs A31: Merge and Demographic Update

A31 updates information associated with an existing person. A30 changes the relationship between identities and therefore requires more extensive validation and auditing.

A30 vs A40: Person and Patient Identifier Merging

A30 communicates person information merging, while A40 focuses on merging patient identifiers. The correct event depends on the supported HL7 version and identity management workflow.

Best Practices for Reliable HL7 A30 Integration

Reliable HL7 A30 integration requires careful identity validation, controlled merge direction, and consistent processing across connected healthcare systems. Organizations should define which application can authorize merges, how surviving identities are selected, and how downstream records are reconciled.

Interfaces should validate complete identifiers, detect conflicting relationships, and prevent duplicate or out-of-sequence processing. Because identity merges can affect clinical information, appropriate audit trails and correction procedures are essential.

Verify the Surviving and Prior Identifiers

Confirm that PID and MRG reference the intended records. Validate assigning authorities and identifier types before changing identity relationships.

Require Authorized Identity Reconciliation

Process A30 messages only from approved source applications. The destination should independently enforce merge permissions and identity matching requirements.

Preserve Clinical and Administrative Relationships

Ensure the approved merge workflow accounts for encounters, orders, results, and other associated records. Avoid direct database updates that bypass application integrity rules.

Prevent Duplicate and Out-of-Sequence Merges

Use message control identifiers, event history, and current identity state to prevent repeated merges or older notifications overwriting newer relationships.

Maintain Audit Trails and Correction Procedures

Record both identifiers, merge direction, source application, and processing outcome. Establish procedures for investigating and correcting incorrectly merged identities.

Frequently Asked Questions About HL7 ADT A30 Messages

HL7 A30 integration raises questions about merge direction, patient identifiers, and the differences between person merging and other patient administration events. Healthcare developers must understand how PID and MRG identify the surviving and prior records, how acknowledgments work, and what happens when a destination cannot safely complete a merge. The following answers address common implementation questions using HL7 Version 2 conventions. Exact requirements depend on the supported version and implementation guide.

Need Help With HL7 ADT A30 Integration?

Person information merging requires accurate identity matching and dependable coordination between healthcare applications. Taction Software supports HL7 interface development, Mirth Connect configuration, patient identity mapping, and enterprise master patient index integration.

Our engineers can help organizations implement A30 merge workflows, validate surviving and prior identifiers, manage downstream synchronization, and establish reliable acknowledgment and monitoring procedures. Whether you are connecting registration systems to an EHR or modernizing existing identity interfaces, properly designed merge processing helps maintain consistent person information across connected applications.

Custom HL7 Person Merge Interfaces

We develop HL7 A30 interfaces based on source and destination requirements, including identifier validation, merge direction, authorized routing, and acknowledgment handling.

Mirth Connect Channel Development

Our engineers configure Mirth Connect channels for identity merge notifications, including JavaScript filters, transformations, secure connectivity, and exception management.

Enterprise Master Patient Index Integration

We help organizations connect EHRs, registration systems, and enterprise master patient indexes through controlled patient identity reconciliation workflows.

Production Monitoring and Support

We support HL7 interfaces through monitoring, failure alerts, mapping updates, and reconciliation procedures that help maintain dependable identity management messaging.

Need help with HL7 person merge integration? Explore our HL7 interface messaging services to discuss your requirements.