HL7 ADT A18 Message: Merge Patient Information, Structure, Segments & Examples

The HL7 A18 message is an Admit, Discharge, Transfer (ADT) event historically used to communicate the merging of patient information between records. Known as ADT A18 or Merge Patient Information, it helps healthcare systems reconcile duplicate patient identities and maintain consistent patient records across connected applications. In HL7 v2.5, A18 is a retained backward-compatibility event, with more specific merge events available for modern implementations. This guide explains the A18 message structure, PID and MRG segments, practical examples, Mirth Connect JavaScript, acknowledgments, and troubleshooting. It also covers how to avoid incorrect patient merges and protect encounter and clinical data integrity.

What Is an HL7 ADT A18 Message?

An HL7 ADT A18 message communicates a patient information merge between records that represent the same person. Historically, the event supported the consolidation of duplicate patient identifiers and related information across healthcare applications. Modern HL7 v2 implementations distinguish several merge scenarios, including patient identifiers, patient accounts, and visit numbers, so A18 should not automatically be treated as interchangeable with every newer merge event. A18 remains relevant in legacy interfaces and interoperability environments that still support it. Understanding these distinctions within HL7 ADT messaging helps integration teams avoid incorrect identity updates.

Purpose of the HL7 A18 Event

A18 communicates that patient information previously associated with one identifier must be merged with another. Receiving applications use the event to reconcile identities according to agreed interface rules.

When Is an ADT A18 Message Generated?

An A18 notification may be generated when a healthcare organization's master patient index or registration system identifies duplicate patient records and initiates a supported merge workflow.

Which Healthcare Systems Receive A18 Messages?

EHRs, laboratory systems, radiology platforms, billing applications, and other connected healthcare systems may receive patient merge notifications. Each destination must support the appropriate identity reconciliation behavior.

How A18 Supports Patient Identity Management

A18 helps connected systems recognize that identifiers previously associated with separate records now refer to the same patient. Correct processing reduces fragmentation across healthcare applications.

Why Accurate A18 Processing Matters

An incorrect patient merge can associate clinical information with the wrong individual. Reliable interfaces require strict identifier validation, audit trails, exception handling, and controlled merge procedures.

HL7 ADT A18 Message Structure and Segments

The HL7 ADT A18 event uses the ADT_A18 message structure in HL7 v2.5 for backward compatibility. A typical message includes MSH, EVN, PID, and MRG, with additional segments depending on the version and implementation profile. MSH identifies the sender, receiver, event, and version. EVN records event information. PID identifies the surviving or target patient record, while MRG identifies prior patient information that must be reconciled. Developers should distinguish current identifiers from prior identifiers because reversing this relationship can cause serious patient identity errors.

MSH Segment: Message Header

MSH identifies the sending and receiving applications, message timestamp, control identifier, and HL7 version. MSH-9 identifies the A18 merge event and associated message structure.

EVN Segment: Event Information

EVN contains metadata about the merge event, including the recorded timestamp. Receiving applications may use this information for auditing, reconciliation, and investigation of delayed identity updates.

PID Segment: Patient Identification

PID identifies the patient record that remains after the merge. Its patient identifiers should be interpreted according to the interface's surviving-record rules and assigning authorities.

MRG Segment: Merge Information

MRG contains identifiers associated with the prior patient record. MRG-1, the Prior Patient Identifier List, is particularly important when reconciling old identifiers with the surviving patient identity.

Optional Segments in A18 Messages

Additional segments may communicate supplementary demographic, visit, or administrative information. Their inclusion depends on the HL7 version and implementation specification, and they must not alter the intended merge direction.

HL7 ADT A18 Message Example With Field Explanation

The following HL7 ADT A18 example illustrates a fictional patient merge involving two identifiers. The surviving patient record uses identifier P180002, while the prior record used P180001. The message follows HL7 v2.5 conventions and includes the MSH, EVN, PID, and MRG segments. MSH-9 identifies ADT^A18^ADT_A18, PID-3 contains the surviving identifier, and MRG-1 identifies the prior patient identifier. This example illustrates identity reconciliation rather than deletion of clinical records. Production interfaces must follow their approved merge rules and applicable HL7 implementation profiles.

Complete HL7 ADT A18 Sample Message

MSH|^~\&|MPI|HOSPITAL|EHR|MAIN|20261013140000||ADT^A18^ADT_A18|MSG18001|P|2.5
EVN|A18|20261013135500
PID|1||P180002^^^HOSPITAL^MR||MARTIN^ELIZABETH||19840415|F
MRG|P180001^^^HOSPITAL^MR

All patient information is fictional. In this example, P180002 is the surviving identifier and P180001 is the prior identifier. The destination must validate this direction before applying any merge.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies MPI as the sending application and EHR as the receiver. ADT^A18^ADT_A18 identifies the legacy patient merge event, while MSG18001 supports message tracking.

EVN Segment Explained

EVN identifies A18 as the event and records its timestamp. Integration teams can use this information to investigate delayed notifications and patient identity reconciliation issues.

PID-3: Surviving Patient Identifier

PID-3 contains P180002, the surviving patient identifier in this example. Receiving applications should use its assigning authority and identifier type to identify the intended target record.

MRG-1: Prior Patient Identifier

MRG-1 contains P180001, the prior patient identifier. Receiving applications use this value to locate the record whose identity must be reconciled with the surviving record.

Understanding Merge Direction

The PID and MRG segments identify different sides of the merge. Reversing their roles may incorrectly replace the surviving identifier with the obsolete identifier.

Important HL7 ADT A18 Fields and Mapping

Reliable HL7 A18 integration depends on accurate mapping of surviving and prior patient identifiers. MSH-9 identifies the merge event, PID-3 identifies the surviving patient record, and MRG-1 contains prior patient identifiers. MSH-10 supports message tracking, while EVN-2 provides event timing information. Implementations must preserve assigning authorities and identifier types to prevent accidental cross-domain merges. Healthcare organizations should document how receiving applications retain historical identifiers, reconcile clinical records, and handle merge conflicts before implementing HL7 v2 integration.

MSH-9: Identifying the Merge Event

MSH-9 identifies the A18 trigger event. Integration engines use this field to route merge notifications through controlled patient identity reconciliation workflows rather than ordinary demographic updates.

PID-3: Identifying the Surviving Record

PID-3 identifies the patient record that remains after the merge. Receiving systems should validate its assigning authority and identifier type before updating patient identity relationships.

MRG-1: Identifying the Prior Record

MRG-1 contains the previous patient identifier. Receiving applications should match this identifier to the correct existing record and avoid assuming that identical identifier strings represent the same patient across authorities.

MSH-10: Tracking the Merge Notification

MSH-10 provides the message control identifier. Integration teams use it for acknowledgment correlation, duplicate detection, and audit trails associated with patient identity reconciliation.

EVN-2: Recording Merge Event Timing

EVN-2 records the event timestamp. Receiving applications may use it for auditing and investigating the sequence of patient identity changes across connected systems.

How HL7 ADT A18 Messages Work in Healthcare Integration

An HL7 ADT A18 workflow begins when a healthcare organization identifies duplicate patient records and approves a merge according to its identity management procedures. The source system generates an A18 notification identifying the surviving and prior patient identifiers. An integration engine receives the message, validates its structure, and routes it to connected applications. Receiving systems locate both records and apply their supported reconciliation procedures. These procedures may update identifier relationships, patient references, and related records. Reliable processing requires strict validation, duplicate prevention, acknowledgment handling, and auditing.

Step 1: Duplicate Patient Records Are Identified

A master patient index or registration system identifies records representing the same patient. Authorized staff or an approved matching workflow determines the correct surviving identity.

Step 2: Merge Notification Is Generated

The source system generates an A18 message containing the surviving patient identifier in PID and prior identifier information in MRG, according to its interface specification.

Step 3: Validate Both Patient Identities

The integration engine validates the event type, identifiers, assigning authorities, and merge direction. Invalid or ambiguous notifications should enter a controlled exception workflow.

Step 4: Apply Patient Identity Reconciliation

The destination locates the affected records and performs its supported merge operation. Clinical and administrative references must remain associated with the correct individual.

Step 5: Acknowledge and Audit the Merge

The receiving application returns an acknowledgment under the configured HL7 processing mode. Integration teams monitor failures and preserve audit information for identity reconciliation.

How to Implement HL7 ADT A18 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route HL7 ADT A18 messages through configurable integration channels. Unlike routine patient demographic updates, A18 requires careful handling because it changes how two patient identifiers relate to one another. A typical implementation receives the merge notification over MLLP, validates the surviving and prior identifiers, checks assigning authorities, and forwards a controlled reconciliation request to the destination. Production implementations must address duplicate messages, invalid merge direction, audit requirements, and destination-specific merge behavior. Mirth Connect development services can support these requirements.

Configure an HL7 Source Connector

Create a Mirth Connect channel using an MLLP listener or another supported transport. Configure the expected HL7 version, source authentication, transport security, message validation, and acknowledgment settings.

Filter HL7 ADT A18 Messages

Use a source filter to identify A18 notifications and prevent unrelated ADT events from entering patient merge processing. Keep legacy A18 handling separate from newer merge events.

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 === 'A18';

Extract Surviving and Prior Patient Identifiers

Use a JavaScript transformer to extract the surviving identifier from PID-3 and the prior identifier from MRG-1. Validate both identifiers and their assigning authorities before routing the merge.

Mirth Connect JavaScript transformer:

var survivingId =
    msg['PID']['PID.3']['PID.3.1'].toString();

var survivingAuthority =
    msg['PID']['PID.3']['PID.3.4'].toString();

var survivingType =
    msg['PID']['PID.3']['PID.3.5'].toString();

var priorId =
    msg['MRG']['MRG.1']['MRG.1.1'].toString();

var priorAuthority =
    msg['MRG']['MRG.1']['MRG.1.4'].toString();

var priorType =
    msg['MRG']['MRG.1']['MRG.1.5'].toString();

var messageControlId =
    msg['MSH']['MSH.10']['MSH.10.1'].toString();

if (!survivingId || !priorId) {
    throw new Error(
        'Missing surviving or prior patient identifier'
    );
}

if (!survivingAuthority || !priorAuthority) {
    throw new Error(
        'Missing patient identifier assigning authority'
    );
}

if (survivingId === priorId &&
    survivingAuthority === priorAuthority &&
    survivingType === priorType) {
    throw new Error(
        'Surviving and prior identifiers are identical'
    );
}

channelMap.put('survivingId', survivingId);
channelMap.put('survivingAuthority', survivingAuthority);
channelMap.put('survivingType', survivingType);

channelMap.put('priorId', priorId);
channelMap.put('priorAuthority', priorAuthority);
channelMap.put('priorType', priorType);

channelMap.put('messageControlId', messageControlId);

This example assumes that Mirth Connect has parsed the HL7 message into its XML representation. Production interfaces should support repeating patient identifiers, complete assigning-authority components, and organization-specific identity matching policies.

Transform A18 Data for Destination Systems

Prepare a destination-specific payload that clearly distinguishes the surviving patient from the prior patient. The destination should validate the merge before modifying clinical or administrative records.

Example JSON transformation:

var mergeRequest = {
    eventType: 'A18',
    action: 'mergePatientInformation',
    survivingPatient: {
        identifier: channelMap.get('survivingId'),
        assigningAuthority:
            channelMap.get('survivingAuthority'),
        identifierType:
            channelMap.get('survivingType')
    },
    priorPatient: {
        identifier: channelMap.get('priorId'),
        assigningAuthority:
            channelMap.get('priorAuthority'),
        identifierType:
            channelMap.get('priorType')
    },
    messageControlId:
        channelMap.get('messageControlId')
};

var jsonPayload = JSON.stringify(mergeRequest);

channelMap.put('jsonPayload', jsonPayload);

This JSON structure is illustrative, not a standardized patient merge API. Production systems should use an approved merge endpoint or workflow with authorization, validation, audit logging, and recovery controls.

Test and Monitor Patient Merge Processing

Test valid merges, missing identifiers, incorrect assigning authorities, duplicate notifications, unknown records, and destination failures. Verify that the surviving identity remains correct and clinical information is not associated with another patient.

HL7 ADT A18 ACK Message Examples and Error Handling

HL7 acknowledgment messages help sending systems determine whether an A18 merge notification was accepted or rejected under the configured acknowledgment mode. An ACK contains a response code and the original message control identifier. Common application acknowledgment codes include AA for acceptance, AE for application error, and AR for rejection. Because patient merges affect identity relationships and potentially clinical records, acknowledgment handling must be clearly documented. An AA response does not necessarily prove that every connected downstream application has completed reconciliation unless the receiving system explicitly guarantees that behavior.

Successful ACK Response: AA

An AA acknowledgment indicates application-level acceptance under the configured acknowledgment mode. MSA-2 identifies the original A18 message control identifier, allowing the sender to correlate the response.

MSH|^~\&|EHR|MAIN|MPI|HOSPITAL|20261013140001||ACK^A18^ACK|ACK18001|P|2.5
MSA|AA|MSG18001

Application Error Response: AE

An AE acknowledgment indicates an application processing error. Unknown patient identifiers, ambiguous matches, or invalid merge relationships may prevent successful reconciliation.

MSH|^~\&|EHR|MAIN|MPI|HOSPITAL|20261013140002||ACK^A18^ACK|ACK18002|P|2.5
MSA|AE|MSG18001
ERR|||204^Unknown Key Identifier^HL70357|E

Application Rejection Response: AR

An AR acknowledgment indicates that the receiving application rejected the merge notification. The sender should investigate the rejection before correcting or retransmitting the message.

MSH|^~\&|EHR|MAIN|MPI|HOSPITAL|20261013140003||ACK^A18^ACK|ACK18003|P|2.5
MSA|AR|MSG18001

Correlate ACK Responses With Merge Notifications

MSA-2 identifies the original message control identifier. Integration engines use this value to correlate responses with A18 notifications and maintain traceability for patient identity changes.

Handle Merge Failures Without Data Loss

Failed merges should enter a controlled exception workflow. Avoid automatic retries that could repeat destructive operations, and reconcile affected records before reprocessing the notification.

Common HL7 ADT A18 Integration Errors and Troubleshooting

HL7 A18 integration problems commonly involve reversed merge direction, missing prior identifiers, inconsistent assigning authorities, and duplicate merge notifications. These issues are particularly sensitive because patient merges can affect clinical records, laboratory results, billing information, and longitudinal histories. Some modern systems do not support A18 and require more specific merge events. Troubleshooting should examine the original message, patient identity records, acknowledgment responses, and destination audit logs. Careful HL7 parsing and data mapping helps prevent identity reconciliation errors.

Surviving and Prior Identifiers Are Reversed

A transformer may incorrectly treat MRG-1 as the surviving identifier. Validate merge direction before applying changes, because reversing the relationship can compromise patient identity records.

Prior Patient Record Cannot Be Found

The receiving application may not recognize the identifier in MRG-1. Verify the assigning authority, identifier type, and historical patient identity mappings before retrying.

Duplicate Merge Notifications

Repeated A18 messages may arrive after a successful merge. Implement idempotent processing so subsequent notifications do not attempt to merge an already retired identity incorrectly.

Conflicting Patient Demographics

The surviving and prior records may contain different names, birth dates, or demographic details. Follow approved identity verification and conflict resolution procedures rather than automatically overwriting values.

Destination Does Not Support A18

Some applications support newer merge events instead of legacy A18. Confirm destination capabilities and implement an approved mapping rather than automatically substituting another event.

HL7 ADT A18 vs A28, A34, A40, and A47

HL7 patient administration includes multiple events that may affect patient identity information. A18 is a legacy merge event retained for backward compatibility in HL7 v2.5. A28 adds patient information, A34 represents a merge involving patient ID information, A40 merges patient identifiers within the patient identifier list, and A47 changes patient identifiers. These events are not interchangeable because their identifier scope and intended operations differ. Integration teams should follow the relevant HL7 version and implementation guide when selecting the correct event for an identity management workflow.

A18 vs A28: Merge and Add Patient Information

A18 communicates a merge of existing patient identities, while A28 adds patient information. Receiving applications should distinguish identity reconciliation from creation of a new patient record.

A18 vs A34: Different Merge Semantics

A34 represents a patient ID merge event with more specific identifier scope. A18 is a legacy merge event whose use should be reviewed against the applicable HL7 version.

A18 vs A40: Legacy and Identifier-List Merge

A40 is commonly used for merging patient identifiers in modern HL7 v2 interfaces. A18 remains relevant to legacy systems but should not automatically replace A40.

A18 vs A47: Merge and Identifier Change

A47 communicates a change to patient identifiers, while A18 communicates a merge relationship. These operations differ because a change of identifier does not necessarily involve two duplicate patient records.

Best Practices for Reliable HL7 A18 Integration

Reliable HL7 A18 integration requires strict patient identity validation, clear merge direction, and controlled reconciliation procedures. Healthcare organizations should document how surviving and prior identifiers are represented, how assigning authorities are interpreted, and which destination systems support the event. Interfaces should define duplicate detection, acknowledgment behavior, error recovery, and audit requirements. Because an incorrect merge can affect clinical information, patient safety considerations are essential. Combining validation, authorized merge workflows, monitoring, and reconciliation helps maintain trustworthy patient identities across connected healthcare systems.

Validate Merge Direction Before Processing

Confirm which identifier survives and which becomes historical. Never assume that the first identifier encountered should be retired without checking the interface specification.

Preserve Assigning Authorities and Identifier Types

Patient identifiers may overlap across facilities and identifier domains. Use assigning authorities and identifier types to distinguish records accurately before applying merge operations.

Protect Clinical and Encounter Associations

Ensure clinical records, encounters, orders, and results remain associated with the correct individual. Avoid destructive data operations without approved reconciliation and recovery procedures.

Implement Idempotent Merge Processing

Track processed notifications and existing merge relationships. Repeated A18 messages should not recreate records, reverse previous merges, or generate inconsistent identifier mappings.

Maintain Audit Trails and Recovery Procedures

Record merge events, processing outcomes, and authorized corrections. Establish recovery procedures for incorrect merges, including escalation to patient identity management and clinical data governance teams.

Frequently Asked Questions About HL7 ADT A18 Messages

HL7 A18 integration involves patient identity reconciliation, surviving identifiers, prior identifiers, and legacy merge behavior. Healthcare developers and IT teams often need to understand how A18 differs from newer merge events, which fields identify the records involved, and how to handle duplicate or failed notifications. The following questions address common implementation concerns using HL7 v2.5 conventions. Actual processing requirements depend on the sending application, receiving system, and agreed interface implementation guide.

Need Help With HL7 ADT A18 Integration?

Reliable patient merge messaging helps healthcare organizations reconcile duplicate identities while protecting the accuracy of clinical and administrative records. Taction Software supports HL7 interface development, Mirth Connect configuration, patient identifier mapping, and identity reconciliation workflows. Our engineers can help organizations implement controlled merge processing, validate surviving and prior identifiers, prevent duplicate operations, and establish dependable monitoring procedures. Whether you are maintaining a legacy A18 interface or modernizing patient merge workflows, accurate message handling supports more consistent patient information across connected healthcare applications.

Custom HL7 Patient Merge Interfaces

We develop HL7 patient merge interfaces based on source and destination requirements. Implementation includes identifier validation, merge direction mapping, message routing, and acknowledgment handling.

Mirth Connect Channel Development

Our engineers configure Mirth Connect channels for patient merge notifications, including event filters, JavaScript transformations, destination connectivity, and exception handling.

Patient Identity Reconciliation

We help organizations manage surviving and prior patient identifiers through controlled mapping, duplicate prevention, and reconciliation procedures that support accurate patient identity records.

Production Monitoring and Support

We support HL7 interfaces through monitoring, failure alerts, mapping updates, and recovery procedures. These services help maintain dependable patient identity messaging as healthcare applications evolve.

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