HL7 ADT A36 Message: Merge Patient ID and Account Number, Structure, Segments & Examples

The HL7 ADT A36 message is a patient administration event used to communicate the merging of patient identification information and patient account numbers. Officially called Merge Patient Information - Patient ID and Account Number, A36 was designed for situations where both identifiers change as part of a patient record merge.

It is retained for backward compatibility in modern HL7 Version 2 implementations. Since HL7 v2.3.1, A40 and A41 are the preferred events for patient identifier and account merges, respectively. This guide explains A36 message structure, PID and MRG segments, practical examples, Mirth Connect integration, acknowledgments, and troubleshooting.

What Is an HL7 ADT A36 Message?

HL7 ADT A36 communicates a merge involving both patient identification and account information. Healthcare systems may encounter this event when duplicate patient records and their associated account identifiers need to be reconciled. For example, a patient might have been registered under two identifiers, with separate account numbers associated with the records.

A legacy master patient index or registration system may generate an A36 notification to consolidate the information. Receiving applications must identify the surviving patient and account identifiers, locate the previous identifiers, and apply the approved merge rules. A36 is a legacy event. New integrations should generally use A40 and A41 where supported. See the HL7 ADT messages guide for the full event family.

Purpose of the HL7 A36 Event

A36 communicates changes to both patient identity and account identifiers resulting from a merge. It allows connected systems to reconcile records and prevent duplicate patient or account information.

When Is an ADT A36 Message Generated?

An A36 message may be generated when a legacy registration system or patient identity management application merges duplicate patient records and associated account numbers.

Which Healthcare Systems Receive A36 Messages?

EHRs, patient accounting applications, laboratory systems, radiology platforms, health information exchanges, and master patient index applications may receive A36 notifications through existing HL7 interfaces.

Why A36 Is Retained for Backward Compatibility

A36 remains defined to support older implementations. HL7 recommends A40 for patient identifier list merges and A41 for patient account number merges in newer interface designs.

Why Accurate A36 Processing Matters

An incorrect merge can associate clinical records, results, or charges with the wrong patient. Receiving systems must verify identifier domains, merge direction, and authorization before changing records.

HL7 ADT A36 Message Structure and Segments

In HL7 Version 2.5, A36 uses the ADT_A30 message structure. The essential segments are MSH, EVN, PID, and MRG. PD1 and SFT are optional in the relevant message profile. Unlike a typical admission or transfer message, the A36 structure does not require PV1.

The PID segment identifies the surviving patient, while MRG carries the prior identifiers involved in the merge. The distinction between surviving and prior identifiers is essential. Reversing these values could merge valid records into an incorrect identity.

HL7 ADT A36 Message Structure

MSH
[{SFT}]
EVN
PID
[PD1]
MRG

This represents the core HL7 v2.5 A36 structure.

MSH Segment: Message Header

MSH identifies the sending application, receiving application, timestamp, message control identifier, and HL7 version. MSH-9 contains ADT^A36^ADT_A30.

EVN Segment: Event Information

EVN records administrative information about the merge event, including when it was registered. It supports tracking, troubleshooting, and audit history.

PID Segment: Surviving Patient Information

PID identifies the patient record that remains after the merge. The surviving patient identifiers should be populated according to the agreed legacy interface profile.

MRG Segment: Prior Merge Information

MRG identifies the previous patient and account identifiers that are being merged into the surviving record. Correct interpretation of MRG is critical to maintaining patient identity.

Optional PD1 Segment: Additional Demographics

PD1 may provide additional demographic information when supported by the sender and receiver. It is not the primary source of merge direction.

HL7 ADT A36 Message Example With Field Explanation

Consider a hospital that discovers duplicate records for the same patient. The correct record uses patient identifier MRN360001 and account number ACC360001. A duplicate record uses patient identifier MRN360099 and account number ACC360099. After confirming that both records belong to the same person, the authorized registration team performs a merge. The registration system generates an A36 message to notify connected applications that the duplicate patient and account identifiers should be consolidated into the surviving record.

Complete HL7 ADT A36 Sample Message

MSH|^~\&|REGISTRATION|HOSPITAL|EHR|MAIN|20261022150000||ADT^A36^ADT_A30|MSG36001|P|2.5
EVN|A36|20261022150000
PID|1||MRN360001^^^HOSPITAL^MR||WILSON^EMILY||19880215|F||||||||||ACC360001
MRG|MRN360099^^^HOSPITAL^MR||ACC360099

All patient information is fictional. In this example, the PID segment identifies the surviving patient and account, while the MRG segment identifies the previous patient and account information.

Merge previous identifiers into the surviving record.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies the source and destination. The message type ADT^A36^ADT_A30 indicates an A36 merge using the ADT_A30 structure.

EVN Segment Explained

EVN provides the administrative timestamp of the merge. Receiving systems can use it to reconstruct the sequence of patient identity changes.

PID-3: Surviving Patient Identifier

PID-3 contains the surviving patient identifier. This is the patient identity that receiving applications should retain after the approved merge.

PID-18: Surviving Patient Account Number

PID-18 identifies the surviving account number in the legacy A36 merge. It should be mapped according to the destination's account management rules.

MRG-1 and MRG-3: Previous Identifiers

MRG-1 identifies the previous patient identifier, while MRG-3 identifies the previous account number. These values tell the destination which identifiers are being merged.

Important HL7 ADT A36 Fields and Mapping

An A36 merge involves two identity levels: the patient identifier and the patient account number. Both must be interpreted together, and both require explicit direction. The PID segment represents the surviving identity, while the MRG segment identifies the previous values.

In practice, an interface should also consider assigning authorities, identifier types, downstream references, and historical records. A36 is especially sensitive because a mistaken merge can affect multiple encounters, clinical documents, laboratory results, and billing transactions. Our HL7 parsing and data mapping team can document identifier mapping across every receiving system.

PID-3: Surviving Patient Identifier

PID-3 identifies the patient record that remains after the merge. Use the complete identifier, assigning authority, and identifier type to avoid collisions between different registration systems.

PID-18: Surviving Account Number

PID-18 identifies the account number associated with the surviving record. Receiving applications should confirm that the account belongs to the intended patient and follows the approved reconciliation workflow.

MRG-1: Prior Patient Identifier

MRG-1 contains the patient identifier being retired or merged. The destination must preserve historical references to this identifier so previously received records remain traceable.

MRG-3: Prior Account Number

MRG-3 identifies the previous account number. It supports account reconciliation and helps receiving systems locate transactions associated with the duplicate account.

MSH-10: Message Control Identifier

MSH-10 uniquely identifies the notification within the agreed messaging scope. It supports acknowledgment correlation and prevents repeated delivery from applying the same merge more than once.

How HL7 ADT A36 Patient Merge Workflows Operate

A patient merge should begin with an authorized identity reconciliation process, not merely the arrival of a message. Registration staff or a master patient index system determine that two patient identities belong to the same person. They select the surviving identifiers and identify the duplicate values.

The source application generates A36 for a legacy interface. An integration engine validates the message and routes it to downstream applications. Each destination applies its supported merge operation and returns an acknowledgment. Any unresolved records require controlled reconciliation.

Step 1: Identify Duplicate Patient and Account Records

The registration or identity management team investigates potential duplicates using patient demographics, identifiers, encounter history, and the organization's established verification process.

Step 2: Select the Surviving Identifiers

The authorized team determines which patient identifier and account number will remain. The merge direction must be explicit and consistent across every connected system.

Step 3: Generate the A36 Message

The source creates an A36 message containing the surviving values in PID and the previous values in MRG. The message is transmitted through the configured interface.

Step 4: Validate and Route the Merge

The integration engine validates message structure, identifier completeness, assigning authorities, and approved source systems. Invalid or ambiguous merges should be quarantined.

Step 5: Reconcile Downstream Records

Receiving applications update supported references, preserve audit history, and reconcile affected records. Acknowledgments and application-level reconciliation results should be monitored separately.

How to Implement HL7 ADT A36 Using Mirth Connect

Mirth Connect can receive legacy A36 messages, validate patient and account identifiers, transform the information, and route the event to approved destination systems. Because A36 changes identity relationships, it requires stronger safeguards than a routine demographic update.

The integration must confirm the surviving and previous identifiers, prevent reversed merge direction, and detect repeated events. For new implementations, A40 and A41 should be considered instead of introducing A36 unnecessarily. The source and destination must agree on the merge workflow before production deployment.

Configure the Mirth Connect Source Connector

Create a channel using an MLLP Listener with HL7 v2.x inbound data type. Configure trusted senders, secure transport, acknowledgment behavior, and restricted access to merge-message logs.

Filter HL7 ADT A36 Messages

Use the following JavaScript filter for an HL7 v2.5 interface.

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

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

var structure =
    msg['MSH']['MSH.9']['MSH.9.3'].toString();

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

return type === 'ADT' &&
       event === 'A36' &&
       structure === 'ADT_A30' &&
       version === '2.5';

Extract Patient and Account Merge Identifiers

The following transformer extracts the surviving and previous identifiers. It also validates that the source and destination identifiers are different.

function getComponent(segment, field, number) {
    if (segment[field].length() === 0) {
        return '';
    }

    return segment[field][0][field + '.' + number]
        .toString().trim();
}

var msh = msg['MSH'];
var pid = msg['PID'];
var mrg = msg['MRG'];

if (mrg.length() === 0) {
    throw new Error('Missing MRG segment');
}

var event = getComponent(msh, 'MSH.9', 2);

if (event !== 'A36') {
    throw new Error('Unexpected ADT event');
}

var survivingPatientId =
    getComponent(pid, 'PID.3', 1);

var previousPatientId =
    getComponent(mrg, 'MRG.1', 1);

var survivingAccount =
    getComponent(pid, 'PID.18', 1);

var previousAccount =
    getComponent(mrg, 'MRG.3', 1);

var controlId =
    getComponent(msh, 'MSH.10', 1);

if (!survivingPatientId ||
    !previousPatientId ||
    !survivingAccount ||
    !previousAccount ||
    !controlId) {
    throw new Error(
        'Missing required merge identifiers'
    );
}

if (survivingPatientId === previousPatientId) {
    throw new Error(
        'Patient identifiers must differ'
    );
}

if (survivingAccount === previousAccount) {
    throw new Error(
        'Account identifiers must differ'
    );
}

var mergeEvent = {
    eventType: 'A36',

    operation: 'mergePatientAndAccount',

    survivingPatientId: survivingPatientId,
    previousPatientId: previousPatientId,

    survivingAccount: survivingAccount,
    previousAccount: previousAccount,

    messageControlId: controlId,

    status: 'pending_validation'
};

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

This example assumes a single agreed identifier domain. Production implementations must validate complete CX identifier values, assigning authorities, and account-number namespaces. Comparing only the first component is insufficient for cross-domain patient identity management.

Transform A36 Into a Controlled Merge Request

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

var request = {
    operation: 'validatePatientAccountMerge',

    survivingPatientId:
        event.survivingPatientId,

    previousPatientId:
        event.previousPatientId,

    survivingAccount:
        event.survivingAccount,

    previousAccount:
        event.previousAccount,

    approvalRequired: true,

    sourceMessageId:
        event.messageControlId
};

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

This JSON is an illustrative destination payload, not an HL7-defined API. It deliberately requests validation rather than executing an irreversible merge.

Validate Merge Direction and Authorization

Before applying the merge, verify that both identifiers belong to the same person and that the source system is authorized to initiate identity changes.

Monitor Merge Processing and Reconciliation

Monitor failed acknowledgments, missing patient records, account mismatches, duplicate messages, and downstream reconciliation results. Preserve an auditable history of the original identifiers.

HL7 ADT A36 ACK Message Examples and Error Handling

HL7 acknowledgments indicate whether a receiving application accepted or rejected the A36 message. A typical acknowledgment contains MSH and MSA segments. ERR can provide diagnostic information when processing fails. In original acknowledgment mode, AA indicates application acceptance, AE indicates an application error, and AR indicates rejection.

For patient merges, transport acceptance and completed identity reconciliation should be monitored separately. A successful ACK alone does not prove that every downstream record has been consolidated correctly.

Successful A36 ACK: AA

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022150001||ACK^A36^ACK|ACK36001|P|2.5
MSA|AA|MSG36001

Application Error ACK: AE

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022150002||ACK^A36^ACK|ACK36002|P|2.5
MSA|AE|MSG36001
ERR|||204^Unknown Key Identifier^HL70357|E

Application Rejection ACK: AR

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022150003||ACK^A36^ACK|ACK36003|P|2.5
MSA|AR|MSG36001

Correlate ACK Responses With Original Messages

MSA-2 should reference the original A36 message's MSH-10 identifier. Maintain a separate record of the actual downstream merge outcome.

Handle Failed and Duplicate Merge Messages

Before retrying an unacknowledged merge, determine whether the destination has already processed it. Never assume an application error means the merge made no changes.

Common HL7 ADT A36 Integration Errors and Troubleshooting

A36 integration errors are particularly sensitive because they can affect patient identity, clinical records, and financial accounts simultaneously. The most common issues involve incorrect merge direction, missing prior identifiers, mismatched account numbers, and unsupported legacy message structures. Some receiving applications support A40 and A41 but do not accept A36.

Troubleshooting should begin with the interface specification, complete patient identifier domains, and the original merge decision. Any ambiguous merge should be stopped until the identity relationship can be verified. Our HL7 interface messaging team can help trace merge failures across downstream systems.

Incorrect Patient Merge Direction

The receiving application may interpret the previous patient identifier as the surviving identity. Verify that PID contains the surviving information and MRG contains the prior values.

Missing MRG Segment or Identifiers

An A36 message without valid previous patient and account identifiers cannot safely describe the intended merge. Validate MRG-1 and MRG-3 before processing.

Unsupported Legacy A36 Event

Some applications accept A40 and A41 but not A36. Confirm supported trigger events and determine whether separate modern merge messages are required.

Patient and Account Records Do Not Match

The patient merge may be valid while the account relationship is incorrect. Validate both identity levels independently before applying any changes.

Duplicate or Partially Completed Merges

A retry may arrive after the destination has already merged one or both identifiers. Implement idempotent handling and reconcile the actual destination state.

HL7 ADT A36 vs A34, A35, A40, and A41

HL7 Version 2 defines several merge events that differ by identifier scope and intended use. A34 addresses patient identifier merges, while A35 addresses account number merges. A36 combines both operations in a legacy event. Beginning with HL7 v2.3.1, A40 and A41 became the preferred alternatives for patient identifier list and account number merges. These events should not be treated as interchangeable because they affect different identity relationships.

A36 vs A34: Combined and Patient-Only Merge

A34 addresses the patient identifier merge, while A36 covers both patient and account identifiers. Both are retained for backward compatibility in modern HL7 versions.

A36 vs A35: Combined and Account-Only Merge

A35 focuses on account number merging. A36 combines patient identity and account merging, requiring validation of both relationships.

A36 vs A40: Legacy and Modern Patient Merge

A40 is the preferred event for merging patient identifier lists. Unlike A36, it does not imply that the account number must also be merged.

A36 vs A41: Legacy and Modern Account Merge

A41 communicates a patient account number merge. It is the preferred alternative for the account portion of a legacy A36 workflow.

Should A36 Be Used in New HL7 Integrations?

Generally, no. A36 remains useful for supporting existing interfaces, but new implementations should evaluate A40 and A41 according to the sending and receiving systems' capabilities.

Best Practices for Reliable HL7 A36 Integration

A36 integration should be approached as a patient identity management workflow rather than a simple data transformation. Healthcare organizations need clear rules for determining the surviving patient, identifying previous accounts, validating source authority, and preserving clinical and financial history.

Integration teams should test duplicate delivery, incomplete merges, cross-domain identifiers, and downstream systems that cannot process legacy A36 events. Where possible, use supported application merge operations instead of direct database changes.

Verify Patient Identity Before Merging

Confirm that both records belong to the same individual through an approved patient identity verification process. Do not initiate a merge solely because names or demographic values match.

Validate Patient and Account Merge Direction

Verify surviving and previous identifiers independently. Ensure that the patient and account relationships are consistent with the approved merge decision.

Preserve Historical Identifiers and Audit Records

Retain previous identifiers as historical references where supported. Preserve enough audit information to trace which records were merged and when.

Implement Idempotency and Controlled Retries

Repeated A36 notifications must not trigger conflicting merges. Validate the destination's current state before retrying failed or unacknowledged operations.

Prefer A40 and A41 for New Implementations

When both systems support them, use the more specific A40 and A41 events. Document the sequence and expected outcomes when both patient and account merges are required.

Frequently Asked Questions About HL7 ADT A36 Messages

Need Help With HL7 ADT A36 Integration?

Patient and account merges require reliable coordination between EHRs, master patient indexes, registration applications, laboratory systems, and patient accounting platforms. Taction Software supports HL7 interface development, Mirth Connect implementation, patient identity reconciliation, and healthcare interoperability.

Legacy HL7 Patient Merge Integration

We help healthcare organizations maintain and modernize existing A34, A35, and A36 interfaces while preserving patient identity and account relationships.

Mirth Connect Development and Integration

Our engineers develop Mirth Connect channels for merge message validation, secure routing, identifier mapping, acknowledgment handling, and exception monitoring.

EHR and Master Patient Index Integration

We support integration between EHRs, registration platforms, master patient indexes, and patient accounting applications using approved merge workflows.

Migration From Legacy to Modern HL7 Events

We help assess whether legacy A36 workflows can be replaced with A40 and A41 messages supported by the participating applications.

Need help with HL7 patient merge integration? Explore HL7 Integration and Taction Software's EHR integration services to discuss your requirements.