HL7 ADT A34 Message: Merge Patient Information, Patient ID Only, Structure, Segments & Examples

The HL7 A34 message is an Admit, Discharge, Transfer (ADT) event historically used to communicate a patient identifier merge. Known as ADT A34: Merge Patient Information, Patient ID Only, it belongs to the HL7 Version 2 patient administration message family.

A34 addresses situations in which two patient identifiers have been assigned to the same individual and an authorized identity management workflow determines that one identifier should replace the other. For example, a hospital may discover that a patient was registered under two different identifiers. Once the duplicate identity is confirmed, the registration system can communicate the approved identifier merge to connected applications.

An important distinction is that A34 is a legacy merge event. Later HL7 Version 2 specifications introduced more precise merge events, including A40, for merging patient identifiers. New integrations should use the event required by the agreed HL7 version and interface specification.

This guide explains HL7 A34 message structure, PID and MRG fields, examples, Mirth Connect implementation, acknowledgment handling, troubleshooting, and best practices.

What Is an HL7 ADT A34 Message?

An HL7 ADT A34 message communicates the merging of patient information based on the patient identifier. The event was designed for situations in which duplicate patient identifiers needed to be reconciled across connected healthcare applications.

The receiving application identifies the surviving patient identifier and the prior identifier involved in the merge. It then applies the authorized identity reconciliation workflow.

A34 should not be treated as a routine demographic update or as permission to combine unrelated clinical records. Understanding legacy merge events alongside modern HL7 ADT messaging is important when maintaining older healthcare interfaces.

Purpose of the HL7 A34 Event

A34 communicates an approved patient identifier merge. Receiving applications use the notification to reconcile duplicate identifiers and preserve the relationship between the prior and surviving patient identities.

When Is an ADT A34 Message Generated?

An A34 notification may be generated when an authorized registration or identity management workflow confirms that two patient identifiers belong to the same individual and approves their consolidation.

Which Healthcare Systems Receive A34 Messages?

Legacy EHRs, patient registration systems, master patient indexes, billing platforms, and other healthcare applications may receive A34 messages when their interfaces support this merge event.

Why Is A34 Considered a Legacy Event?

A34 belongs to an earlier HL7 merge model. Later specifications provide more explicit events, including A40, to distinguish patient identifier merging from other identity changes.

Why Accurate A34 Processing Matters

Incorrect patient identifier merging can associate clinical information with the wrong individual. Reliable integration requires identity verification, correct merge direction, authorization, and detailed audit records.

HL7 ADT A34 Message Structure and Segments

An HL7 ADT A34 message uses the pipe-delimited format of HL7 Version 2. The principal information required for an identifier merge includes the message header, event information, the surviving patient identifier, and the prior identifier being merged.

In A34 implementations, PID identifies the surviving patient, while MRG carries prior patient identity information. The exact message structure, field definitions, and required segments depend on the HL7 version.

Important: A34 is retained here as a legacy interface topic. The sample below uses HL7 v2.3 conventions rather than presenting A34 as a standard v2.5 merge workflow.

MSH Segment: Message Header

MSH identifies the sending and receiving applications, message timestamp, control identifier, trigger event, and HL7 version. MSH-9 identifies A34 as the patient ID merge event.

EVN Segment: Event Information

EVN records information about the merge event, including its timestamp. Receiving systems can use this information to investigate the sequence of identity reconciliation operations.

PID Segment: Surviving Patient Identification

PID identifies the patient record that remains after the merge. PID-3 carries the surviving patient identifier. In HL7 v2.3, PID-2 is a separate external patient ID field and should not be confused with PID-3.

MRG Segment: Prior Patient Identification

MRG carries information identifying the prior patient record involved in the merge, with the prior patient identifier in MRG-1. Correct mapping is essential because reversing the merge direction can cause serious identity errors.

Version-Specific Segment and Field Requirements

A34 implementations should follow their actual HL7 version and interface guide. Field names, data types, and repetition rules for PID and MRG changed between HL7 releases, so do not assume that a mapping written for one version applies unchanged to another.

HL7 ADT A34 Message Example With Field Explanation

The following example illustrates a legacy HL7 A34 patient identifier merge using HL7 v2.3 conventions. The scenario involves a fictional patient with two identifiers. The authorized registration system has determined that the prior identifier should be consolidated into the surviving identifier.

In this format, PID-3 carries the surviving patient identifier and MRG-1 identifies the prior patient identifier. These positions matter: MRG-2 is the prior alternate patient ID and PID-2 is the external patient ID, and mapping either one as the merge identifier is a common source of failed or incorrect merges.

Complete HL7 ADT A34 Sample Message

MSH|^~\&|REGISTRATION|HOSPITAL|MPI|MAIN|20261014110000||ADT^A34|MSG34001|P|2.3
EVN|A34|20261014105500
PID|1||P340001^^^HOSPITAL^MR||MILLER^ROBERT||19750316|M
MRG|P340002^^^HOSPITAL^MR

All patient information is fictional. In this example, P340001 is the surviving patient ID and P340002 is the prior patient ID.

The exact placement and population of identity fields must be checked against the legacy implementation guide. This example is intended to explain merge direction, not serve as a universal production message template.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies REGISTRATION as the sender and MPI as the receiver. ADT^A34 identifies the legacy patient ID merge event, and MSH-12 specifies HL7 version 2.3.

EVN Segment Explained

EVN identifies A34 and records the event timestamp. This information helps integration teams investigate when the identifier merge was communicated.

PID-3: Surviving Patient ID

PID-3 identifies the surviving patient ID, P340001, together with its assigning authority. Receiving applications must interpret this field according to the supported HL7 version.

MRG-1: Prior Patient ID

MRG-1 identifies the prior patient ID, P340002. The destination uses this information to locate the identity being merged into the surviving record.

Understanding Merge Direction

The intended operation merges the prior identifier into the surviving identifier. Reversing these values may create incorrect identity relationships and should be prevented through validation.

Important HL7 ADT A34 Fields and Mapping

HL7 A34 field mapping requires special attention because patient identifier definitions changed across HL7 Version 2 releases. A34 identifies the surviving patient in PID-3 and the prior patient in MRG-1, but neighboring fields such as PID-2 and MRG-2 carry different identifiers and are easy to map by mistake.

The receiving system must validate the sender's version, confirm the identifier domains, and determine which identifier survives. A34 should not be translated directly into A40 without reviewing the identity model and field semantics. Clear HL7 v2 integration specifications are essential when modernizing legacy patient identity interfaces.

MSH-9: Identifying the Legacy Merge Event

MSH-9 identifies A34 as the trigger event. Integration engines should route it through a version-aware patient ID merge workflow rather than a routine demographic update.

PID-3: Identifying the Surviving Patient

PID-3 identifies the surviving patient ID. Receiving applications should validate the identifier and its assigning authority against the authoritative identity management system.

MRG-1: Identifying the Prior Patient

MRG-1 identifies the prior patient ID. Correct mapping, and not confusing it with MRG-2, helps prevent accidental reversal or misdirection of the intended merge.

MSH-12: Selecting the Correct HL7 Version

MSH-12 identifies the HL7 version. It is particularly important for A34 because patient identifier fields and supported merge events differ across versions.

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 reconciliation events.

How HL7 ADT A34 Messages Work in Healthcare Integration

An HL7 ADT A34 workflow begins when an authorized registration or identity management application identifies duplicate patient IDs. The source determines which identifier should remain authoritative and generates a merge notification. An integration engine receives the message, validates its HL7 version and field mappings, and routes the request to the destination.

The receiving application locates the surviving and prior patient identities, verifies the merge, and applies its supported reconciliation workflow. Because the operation can affect clinical and administrative relationships, production processing must preserve record integrity and maintain an audit trail.

Step 1: Duplicate Patient IDs Are Confirmed

An authorized identity management process determines that two patient identifiers belong to the same individual. The workflow establishes the surviving and prior identifiers.

Step 2: Generate the Legacy A34 Notification

The source application generates an A34 message using its supported HL7 version. The notification includes the identifiers needed for the merge.

Step 3: Validate Version and Identifier Mapping

The integration engine checks the message type, HL7 version, surviving identifier, and prior identifier. Invalid or ambiguous notifications enter an exception workflow.

Step 4: Apply the Authorized Identity Merge

The receiving application confirms the identity relationship and applies its approved merge procedure. Clinical and administrative references must remain associated with the correct individual.

Step 5: Acknowledge and Audit the Result

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

How to Implement HL7 ADT A34 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route legacy HL7 A34 messages between patient registration systems, enterprise master patient indexes, EHRs, and healthcare applications. A typical implementation receives an A34 message through an MLLP listener, checks the HL7 version, extracts the surviving and prior patient identifiers, and sends a controlled merge request to the destination identity management service.

Legacy interfaces require additional care because field definitions differ across HL7 versions. A transformer designed for A40 messages should not be reused for A34 without verifying every identifier mapping. Organizations can use Mirth Connect development services to support these migrations and integrations.

Configure the Mirth Connect Source Connector

Create a channel using an MLLP Listener and configure the inbound data type for HL7 v2.x. Set the parser and validation rules to match the actual legacy message format.

Filter HL7 ADT A34 Messages

Use a JavaScript filter to identify A34 notifications and ensure that the message is processed through the correct legacy merge workflow.

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

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

var hl7Version =
    msg['MSH']['MSH.12']['MSH.12.1'].toString();

return messageType === 'ADT' &&
       triggerEvent === 'A34' &&
       hl7Version === '2.3';

This filter illustrates a channel configured specifically for HL7 v2.3 A34 messages. Other versions or local profiles require their own validated routing rules.

Extract the Surviving and Prior Patient IDs

Use a transformer to extract the patient identifiers and message metadata. The following example reads the surviving identifier from PID-3 and the prior identifier from MRG-1, as shown in the sample message.

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

    var fieldNode = msg[segment][fieldName];

    if (fieldNode.length() === 0) {
        return '';
    }

    return fieldNode[0][partName]
        .toString()
        .trim();
}

var messageType = component('MSH', 9, 1);
var triggerEvent = component('MSH', 9, 2);
var hl7Version = component('MSH', 12, 1);

// Surviving patient: PID-3 (first repetition)
var survivingId = component('PID', 3, 1);
var survivingAuthority = component('PID', 3, 4);

// Prior patient: MRG-1 (first repetition)
var priorId = component('MRG', 1, 1);
var priorAuthority = component('MRG', 1, 4);

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

if (messageType !== 'ADT' ||
    triggerEvent !== 'A34' ||
    hl7Version !== '2.3') {
    throw new Error(
        'Unsupported message type or HL7 version'
    );
}

if (!survivingId || !priorId) {
    throw new Error(
        'A34 missing surviving or prior patient ID'
    );
}

if (survivingId === priorId &&
    survivingAuthority === priorAuthority) {
    throw new Error(
        'Cannot merge a patient ID into itself'
    );
}

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

var mergeEvent = {
    eventType: 'A34',
    hl7Version: hl7Version,
    survivingPatientId: survivingId,
    survivingAuthority: survivingAuthority,
    priorPatientId: priorId,
    priorAuthority: priorAuthority,
    messageControlId: controlId,
    eventTimestamp: eventTimestamp
};

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

Implementation note: This example demonstrates the intended extraction pattern, not a complete production transformer. It reads only the first repetition of PID-3 and MRG-1. Confirm the exact Mirth Connect XML representation, legacy field definitions, identifier repetitions, and assigning authorities before deployment.

Transform A34 Into a Controlled Merge Request

A destination-specific JSON payload can communicate the merge intent to an authorized patient identity management service. The destination must validate both identities before processing.

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

var request = {
    eventType: 'A34',
    action: 'requestPatientIdentifierMerge',

    survivingPatient: {
        identifier: event.survivingPatientId,
        assigningAuthority: event.survivingAuthority
    },

    priorPatient: {
        identifier: event.priorPatientId,
        assigningAuthority: event.priorAuthority
    },

    processingStatus: 'pending_identity_validation',

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

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

This payload is illustrative and is not a standardized HL7 API. A production implementation should include any additional identity context required by the receiving application.

Validate Both Identities Before Merging

Confirm that both identifiers exist in their intended domains and refer to the same individual. The destination must independently authorize the merge and detect conflicting identity relationships.

Configure Acknowledgments and Exception Handling

Configure ACK behavior according to the interface agreement. Route unknown identifiers, invalid versions, conflicting identities, and unsuccessful merges into monitored exception workflows.

HL7 ADT A34 ACK Message Examples and Error Handling

HL7 acknowledgments allow the sending application to determine whether an A34 message was accepted or rejected under the configured processing mode. A typical acknowledgment contains MSH and MSA segments. The ERR segment can provide additional information about application errors.

In original acknowledgment mode, AA indicates application acceptance, AE indicates an application error, and AR indicates rejection. Because A34 can initiate a significant identity change, the interface specification should clearly define whether an acknowledgment represents message acceptance or completed identity reconciliation.

Successful ACK Response: AA

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

MSH|^~\&|MPI|MAIN|REGISTRATION|HOSPITAL|20261014110001||ACK|ACK34001|P|2.3
MSA|AA|MSG34001

Application Error Response: AE

An AE acknowledgment indicates an application error. An unknown prior patient ID, missing surviving identity, or failed validation may prevent processing.

MSH|^~\&|MPI|MAIN|REGISTRATION|HOSPITAL|20261014110002||ACK|ACK34002|P|2.3
MSA|AE|MSG34001|Prior patient identifier not found

Application Rejection Response: AR

An AR acknowledgment indicates rejection by the destination. Unsupported message versions, unauthorized sources, or invalid merge requests may result in rejection.

MSH|^~\&|MPI|MAIN|REGISTRATION|HOSPITAL|20261014110003||ACK|ACK34003|P|2.3
MSA|AR|MSG34001|Unsupported merge request

Correlate ACK Responses With Merge Events

MSA-2 contains the original message control identifier. Integration teams use this value to correlate acknowledgments, retries, and downstream processing outcomes.

Handle Duplicate and Failed Merge Notifications

Check the destination's current identity relationships before retrying a failed message. Duplicate A34 notifications must not create additional merges or reverse the surviving identity.

Common HL7 ADT A34 Integration Errors and Troubleshooting

HL7 A34 integration problems often arise from version mismatches, incorrect patient identifier fields, reversed merge direction, and inconsistent identity records. Reusing mappings without checking the HL7 version and field definitions can result in incorrect identifiers being extracted.

Other failures occur when a destination cannot locate the prior patient ID or when the surviving record has conflicting demographic information. Troubleshooting should examine the original message, HL7 version, PID and MRG fields, acknowledgment responses, and authoritative identity history. Accurate HL7 parsing and data mapping helps reduce these errors.

Incorrect HL7 Version or Message Profile

The destination may expect a different HL7 version or merge event. Verify MSH-12 and the agreed interface specification before changing mappings.

PID and MRG Fields Are Mapped Incorrectly

Mapping PID-2 or MRG-2 instead of PID-3 and MRG-1 extracts the wrong identifiers. Confirm the surviving and prior identifier positions using the actual version-specific message definition.

Surviving and Prior Identifiers Are Reversed

Reversed merge direction can associate information with the wrong identity. Validate both records and confirm the intended surviving identifier before processing.

Prior Patient Identifier Cannot Be Found

The destination may not recognize the prior ID or may have already merged it. Review identity history, identifier domains, and existing alias relationships.

Duplicate Merge Notifications Cause Conflicts

Repeated A34 messages may arrive because of transport retries. Apply idempotency controls and verify the current merge state before attempting another operation.

HL7 ADT A34 vs A30, A35, A39, and A40

HL7 Version 2 includes several merge events with different scopes and historical meanings. A34 represents a legacy patient ID merge. A30 concerns merging person information, while A35 and A39 address other legacy patient and account merging workflows.

A40 is the later, more explicit event for merging patient identifiers in the patient identifier list. These events should not be treated as interchangeable. The correct message depends on the HL7 version, identity model, and agreed interface requirements.

A34 vs A30: Patient ID and Person Information

A34 focuses on a legacy patient ID merge, while A30 communicates merging person information. Their identity scopes and field requirements should be interpreted using the supported HL7 version.

A34 vs A35: Patient and Account Identifiers

A34 concerns patient ID merging, while A35 concerns account-number merging in the legacy event model. These operations should use separate identifier validation and reconciliation rules.

A34 vs A39: Different Legacy Merge Workflows

A34 and A39 belong to different historical merge definitions. Integration teams should review the relevant HL7 release before mapping one event to another.

A34 vs A40: Legacy and Later Patient Identifier Merging

A34 represents an older patient ID merge event. A40 provides a later patient identifier list merge model and is generally the relevant event for newer interfaces that follow that model.

Best Practices for Reliable HL7 A34 Integration

Reliable HL7 A34 integration requires version-specific field mapping, accurate identity validation, and controlled processing of patient identifier merges. Organizations maintaining legacy interfaces should document the precise HL7 release, supported identifier fields, and merge direction.

They should also establish rules for handling records that have already been merged, conflicting patient identities, and duplicate notifications. When modernizing an A34 interface, teams should evaluate whether the destination supports A40 and whether a controlled migration is appropriate.

Document the Exact HL7 Version

Record the HL7 version and local implementation profile used by each A34 interface. Avoid applying field mappings from another version without validation.

Validate Identifier Domains and Merge Direction

Confirm the surviving and prior identifiers, including their issuing authorities where available. Reject ambiguous or conflicting merge requests.

Preserve Clinical and Administrative Relationships

Use the destination's approved merge functionality to maintain associations with encounters, orders, results, and billing records. Avoid direct database updates that bypass application integrity rules.

Implement Duplicate Detection and Audit Logging

Track message control identifiers and merge outcomes. Maintain an audit history of both identities and the authoritative decision that approved the merge.

Plan Legacy Interface Modernization Carefully

Evaluate A40 compatibility when replacing older A34 interfaces. Confirm the destination's identity model, mapping requirements, and supported event semantics before changing message types.

Frequently Asked Questions About HL7 ADT A34 Messages

HL7 A34 integration raises questions about legacy patient ID merging, version-specific identifier fields, and differences between older and newer HL7 merge events. Healthcare developers need to understand which patient identifier survives, where the prior identifier is carried, and whether an existing A34 interface should be migrated to A40. The following answers address common implementation questions. Exact requirements depend on the HL7 version and interface specification.

Need Help With HL7 ADT A34 Integration?

Legacy patient identifier merges require accurate field mapping and careful coordination between healthcare identity management systems. Taction Software supports HL7 interface development, Mirth Connect configuration, patient identifier reconciliation, and healthcare application integration.

Our engineers can help organizations maintain legacy A34 interfaces, validate merge mappings, investigate processing errors, and plan transitions to supported patient identifier merge workflows. Whether you are maintaining an older registration interface or modernizing a master patient index integration, reliable identity reconciliation helps protect the integrity of connected healthcare records.

Legacy HL7 Merge Interface Support

We help organizations analyze and maintain older HL7 merge workflows, including A34 message parsing, identifier validation, and destination mapping.

Mirth Connect Development and Migration

Our engineers configure Mirth Connect channels for legacy identity messages, including version-aware transformations, secure routing, and exception handling.

Master Patient Index and EHR Integration

We support patient identifier reconciliation between registration systems, EHRs, and enterprise master patient indexes using approved identity management workflows.

Production Monitoring and Troubleshooting

We help investigate failed merge messages, incorrect mappings, acknowledgment errors, and inconsistent downstream identity relationships.

Need help with HL7 patient identifier merging? Explore our HL7 interface messaging services to discuss your requirements.