HL7 ADT A24 Message: Link Patient Information, Structure, Segments & Examples

The HL7 A24 message is an Admit, Discharge, Transfer (ADT) event used to link patient information across healthcare records without merging those records into a single identity. Known as ADT A24 or Link Patient Information, it helps healthcare applications establish a relationship between patient identifiers while preserving the records involved. This is important when two patient records need to be associated for administrative or clinical workflows but must remain independently identifiable. The A24 event uses two PID segments, one for each patient record, to communicate the relationship. This guide explains HL7 A24 structure, examples, field mapping, Mirth Connect implementation, acknowledgments, and troubleshooting.

What Is an HL7 ADT A24 Message?

An HL7 ADT A24 message communicates that two patient records should be linked while remaining separate records. It belongs to the HL7 Version 2 patient administration event family and is commonly associated with patient identity management workflows. Unlike an A40 merge event, A24 does not instruct the receiving system to replace one patient identifier with another or consolidate all records into a single identity. Instead, it establishes a defined relationship between patient information records. Understanding A24 alongside other HL7 ADT messages helps developers distinguish linking, merging, and demographic updates.

Purpose of the HL7 A24 Event

A24 communicates a relationship between two patient records. Receiving systems use the event to maintain an association while preserving each record's independent identity and history.

When Is an ADT A24 Message Generated?

An A24 notification may be generated when an authorized identity management workflow establishes a relationship between existing patient records that should remain separate.

Which Healthcare Systems Use A24 Messages?

Enterprise master patient indexes, registration platforms, EHRs, and other patient identity management applications may exchange A24 messages when they support linked-record workflows.

How A24 Differs From Patient Merging

A24 links patient records without consolidating their identities. A merge event changes identifier relationships more fundamentally and may require migration or reconciliation of associated clinical data.

Why Accurate A24 Processing Matters

Incorrect patient linking can expose information across unrelated records or create unsafe clinical associations. Reliable integration requires verified identity relationships, identifier-domain validation, and appropriate access controls.

HL7 ADT A24 Message Structure and Segments

An HL7 ADT A24 message follows the segment-based format used by HL7 Version 2. In HL7 v2.5, A24 uses the ADT_A24 message structure. The message identifies the two records through two PID segments rather than an MRG segment, which belongs to merge events. Its core segments are MSH, EVN, and two PIDs, each optionally followed by PD1, PV1, and DB1. MSH identifies the event, EVN records event information, and each PID identifies one of the records being linked. The receiving system must interpret these fields as a linking instruction rather than a merge.

MSH Segment: Message Header

MSH identifies the sending and receiving applications, message timestamp, control identifier, and HL7 version. MSH-9 identifies A24 as the patient information linking event.

EVN Segment: Event Information

EVN contains event metadata, including the recorded timestamp. This supports audit tracking and investigation of when the patient record relationship was established.

First PID Segment: Patient Identification

The first PID identifies one patient record referenced by the event. Receiving applications should validate the complete identifier, including assigning authority and identifier type.

Second PID Segment: Related Patient Identifier

The second PID identifies the other record in the relationship. Parsers must read both PID segments and should not look for an MRG segment in A24.

Optional Segments and Local Extensions

Some implementations include additional identity or administrative context. These extensions should follow the agreed interface profile and must not change the fundamental linking semantics.

HL7 ADT A24 Message Example With Field Explanation

The following HL7 ADT A24 example illustrates a fictional patient identity linking notification. The message uses HL7 v2.5 conventions and contains MSH, EVN, and two PID segments. MSH-9 identifies ADT^A24^ADT_A24, the first PID-3 identifies one patient record, and the second PID-3 identifies the other patient record involved in the relationship. Both identifiers use fictional values and distinct assigning authorities to illustrate identifier-domain handling. The receiving application should establish only the approved link and must not automatically merge the two records or reassign clinical information.

Complete HL7 ADT A24 Sample Message

MSH|^~\&|MPI|HOSPITAL|EHR|MAIN|20261015140000||ADT^A24^ADT_A24|MSG24001|P|2.5
EVN|A24|20261015135500
PID|1||P240001^^^HOSPITAL^MR||TAYLOR^SARAH||19850409|F
PID|2||P240002^^^PARTNER_SYS^MR||TAYLOR^SARAH||19850409|F

All patient information is fictional. This message illustrates a link between two identifiers, not a merge or deletion operation.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies MPI as the sending application and EHR as the receiver. ADT^A24^ADT_A24 identifies the linking event and message structure, while MSG24001 supports tracking.

EVN Segment Explained

EVN identifies A24 as the event and records its timestamp. Integration teams can use this information to audit when the relationship notification was generated.

PID-3: Primary Patient Identifier

PID-3 identifies fictional patient Sarah Taylor through identifier P240001. The assigning authority provides context for identifying the correct record in the destination system.

Second PID-3: Related Patient Identifier

PID-3 in the second PID segment identifies the other patient record associated with the link. The destination should validate the identifier and its assigning authority before creating the relationship.

Understanding the Linking Relationship

The A24 event establishes an association between patient records while preserving their identities. Receiving applications should not automatically replace identifiers or consolidate clinical histories.

Important HL7 ADT A24 Fields and Mapping

Reliable HL7 A24 integration depends on accurate interpretation of the two patient identifiers and their relationship. MSH-9 identifies the linking event, MSH-10 supports tracking, PID-3 in the first PID identifies one record, and PID-3 in the second PID identifies the related record. EVN-2 provides event timing information. The destination must validate both identifiers, including assigning authorities and identifier types, before creating a link. Because linking can affect how users access patient information, organizations should define whether the relationship changes search results, chart navigation, or data visibility. Clear HL7 v2 integration specifications help maintain safe identity associations.

MSH-9: Identifying the Linking Event

MSH-9 identifies A24 as the trigger event. Integration engines should route this message through patient linking workflows rather than patient merge or deletion processing.

PID-3: Identifying the Current Patient Record

PID-3 contains the patient identifier referenced by the event. Receiving systems should validate the complete identifier domain before creating the relationship.

Second PID-3: Identifying the Related Record

PID-3 in the second PID segment identifies the other patient record involved in the link. Accurate matching prevents unrelated records from being associated through an incorrect identifier.

MSH-10: Tracking the Link Notification

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

EVN-2: Recording the Event Timestamp

EVN-2 records when the linking event was generated. This supports sequencing, audit history, and investigation of conflicting patient identity notifications.

How HL7 ADT A24 Messages Work in Healthcare Integration

An HL7 ADT A24 workflow begins when an authorized patient identity management application determines that two patient records should be linked. The source system generates an A24 notification containing identifiers for both records. An integration engine receives the message, validates its structure, and routes it to connected applications. The receiving system matches both records and establishes the approved relationship without merging their identities. Depending on the application, the link may support patient search, identity reconciliation, or navigation between related records. Reliable processing requires identifier validation, authorization, duplicate prevention, and audit tracking.

Step 1: Patient Relationship Is Approved

An authorized identity management workflow establishes that two patient records should be linked. The source application generates an A24 notification describing the relationship.

Step 2: Validate the HL7 Message

The integration engine validates the A24 event, message identifiers, and both PID segments. Invalid or incomplete notifications should enter an exception workflow.

Step 3: Match Both Patient Records

The receiving application locates the records identified by the two PID-3 values. Both matches should be unambiguous and use the correct assigning authorities.

Step 4: Establish the Patient Link

The destination creates the approved association while preserving the records' independent identifiers and clinical histories. It should not automatically merge or delete either record.

Step 5: Acknowledge and Audit the Relationship

The receiving application returns an acknowledgment under its configured HL7 processing mode. Audit records should identify the source event and the resulting patient relationship.

How to Implement HL7 ADT A24 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route HL7 ADT A24 messages between enterprise master patient indexes, registration applications, and EHR systems. Unlike a routine demographic update, A24 requires careful processing of two patient identities and the relationship between them. A typical channel receives the message through an MLLP listener, checks the trigger event, extracts patient identifiers, and sends a controlled linking request to the destination. Production interfaces should validate both identifier domains, reject ambiguous matches, and prevent automatic merging. Mirth Connect development services can support these requirements.

Configure an HL7 Source Connector

Create a Mirth Connect channel with an MLLP listener or another supported transport. Configure HL7 v2 parsing, authenticated connectivity, acknowledgment behavior, and message retention policies.

Filter HL7 ADT A24 Messages

Use a source filter to identify A24 linking notifications. Keep these messages separate from patient merge, unlink, deletion, and ordinary demographic update 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 === 'A24';

This filter identifies the event but does not establish that the sender is authorized to link patient records. Authentication and authorization must be enforced independently.

Extract Patient Identifiers From Both PID Segments

Use a JavaScript transformer to extract the patient identifier, related identifier, assigning authorities, and message metadata. Validate the values before routing the linking request.

Mirth Connect JavaScript transformer:

// ADT_A24 carries two PID segments, one per linked record.
function getComponent(segmentNode, field, component) {
    var fieldName = segmentNode.name().toString() + '.' + field;
    var componentName = fieldName + '.' + component;

    var node = segmentNode[fieldName];

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

    return node[0][componentName]
        .toString()
        .trim();
}

var pidSegments = msg['PID'];

if (pidSegments.length() !== 2) {
    throw new Error(
        'A24 must contain exactly two PID segments'
    );
}

var patientId = getComponent(pidSegments[0], 3, 1);
var patientAuthority = getComponent(pidSegments[0], 3, 4);

var relatedId = getComponent(pidSegments[1], 3, 1);
var relatedAuthority = getComponent(pidSegments[1], 3, 4);

var messageControlId = getComponent(msg['MSH'], 10, 1);
var eventTimestamp = getComponent(msg['EVN'], 2, 1);

if (!patientId || !relatedId) {
    throw new Error(
        'A24 requires both patient identifiers'
    );
}

if (!patientAuthority || !relatedAuthority) {
    throw new Error(
        'A24 requires both assigning authorities'
    );
}

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

var primaryKey =
    patientAuthority + '|' + patientId;

var relatedKey =
    relatedAuthority + '|' + relatedId;

if (primaryKey === relatedKey) {
    throw new Error(
        'A24 cannot link an identifier to itself'
    );
}

channelMap.put('patientId', patientId);
channelMap.put('patientAuthority', patientAuthority);
channelMap.put('relatedId', relatedId);
channelMap.put('relatedAuthority', relatedAuthority);
channelMap.put('messageControlId', messageControlId);
channelMap.put('eventTimestamp', eventTimestamp);

This example assumes a parsed HL7 v2 XML message in which repeated PID segments are addressed as msg['PID'][0] and msg['PID'][1]. Production implementations must account for repeating identifiers, complete assigning-authority components, and the exact message profile.

Transform A24 Into a Patient Linking Request

Create a destination-specific payload that identifies both records and requests a link. Do not translate the event into a patient merge, identifier replacement, or deletion operation.

Example JSON transformation:

var linkRequest = {
    eventType: 'A24',
    action: 'linkPatientRecords',
    relationshipType: 'linked',
    primaryPatient: {
        identifier: channelMap.get('patientId'),
        assigningAuthority:
            channelMap.get('patientAuthority')
    },
    relatedPatient: {
        identifier: channelMap.get('relatedId'),
        assigningAuthority:
            channelMap.get('relatedAuthority')
    },
    messageControlId:
        channelMap.get('messageControlId'),
    eventTimestamp:
        channelMap.get('eventTimestamp')
};

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

The JSON payload is illustrative and not a standardized HL7 patient linking API. The destination must verify both identities and enforce its own relationship authorization rules.

Validate and Monitor Patient Linking

Test successful links, unknown identifiers, ambiguous matches, duplicate events, and attempts to link a record to itself. Confirm that clinical histories remain independently associated with their original records.

HL7 ADT A24 ACK Message Examples and Error Handling

HL7 acknowledgments allow sending applications to determine whether an A24 linking notification was accepted or rejected under the configured acknowledgment mode. An ACK typically contains MSH and MSA segments, with an ERR segment when additional error details are needed. Common original-mode application acknowledgment codes include AA for acceptance, AE for application error, and AR for rejection. For patient linking workflows, acknowledgment semantics must be clearly defined. Acceptance of the HL7 message does not necessarily mean the receiving application has completed every downstream identity relationship update.

Successful ACK Response: AA

An AA acknowledgment indicates application-level acceptance under the configured acknowledgment mode. MSA-2 identifies the original A24 message control identifier, supporting transaction correlation.

MSH|^~\&|EHR|MAIN|MPI|HOSPITAL|20261015140001||ACK^A24^ACK|ACK24001|P|2.5
MSA|AA|MSG24001

Application Error Response: AE

An AE acknowledgment indicates an application processing error. Unknown patient identifiers, invalid relationship criteria, or inability to resolve a record may prevent successful linking.

MSH|^~\&|EHR|MAIN|MPI|HOSPITAL|20261015140002||ACK^A24^ACK|ACK24002|P|2.5
MSA|AE|MSG24001
ERR|||204^Unknown Key Identifier^HL70357|E

Application Rejection Response: AR

An AR acknowledgment indicates that the receiving application rejected the message. Unauthorized linking requests or unsupported workflows may result in rejection.

MSH|^~\&|EHR|MAIN|MPI|HOSPITAL|20261015140003||ACK^A24^ACK|ACK24003|P|2.5
MSA|AR|MSG24001

Correlate ACK Responses With Link Notifications

MSA-2 references the original message control identifier. Integration teams use this value to associate acknowledgments, retries, and processing outcomes with the corresponding patient linking event.

Handle Duplicate and Rejected Link Requests

Apply idempotent processing so retransmitted A24 messages do not create duplicate relationships. Rejected requests should enter a controlled exception workflow rather than repeatedly attempting unsafe patient links.

Common HL7 ADT A24 Integration Errors and Troubleshooting

HL7 A24 integration problems frequently involve incorrect patient identifiers, ambiguous record matches, unsupported linking operations, and confusion between linking and merging. A receiving application may recognize one patient identifier but fail to resolve the related record because it belongs to a different assigning authority. Another common problem occurs when destinations automatically consolidate clinical information after receiving a link event. Troubleshooting should examine both PID segments, source authorization, acknowledgment responses, and destination relationship rules. Accurate HL7 parsing and data mapping helps reduce these failures.

Related Patient Record Cannot Be Found

The destination may not recognize the identifier supplied for the related patient. Validate the assigning authority, identifier type, and record existence before creating a relationship.

Patient Linking Is Mistaken for Merging

Some destination mappings may incorrectly replace one patient identifier with another. Configure A24-specific processing that preserves both records and their independent clinical histories.

Incorrect Assigning Authority

Identifiers may be unique only within their issuing systems. Missing or incorrect assigning authorities can create false matches between unrelated patient records.

Duplicate A24 Notifications

Repeated A24 messages may create duplicate relationship entries or unnecessary administrative alerts. Use message identifiers and existing relationship checks to support idempotent processing.

Unauthorized or Ambiguous Patient Link

An A24 notification may reference records whose relationship has not been verified. Require approved identity matching and authorization before allowing the destination to expose linked information.

HL7 ADT A24 vs A37, A18, A40, and A08

HL7 patient administration events distinguish linking, unlinking, merging, and updating patient records. A24 establishes a link between patient information records, while A37 unlinks previously linked patient records. A18 is a legacy patient merge event, and A40 communicates a patient identifier merge. A08 updates patient information without changing the fundamental relationship between records. Although these events may contain similar identifiers, they have different meanings and downstream consequences. Receiving applications should use event-specific logic rather than treating every identity-related notification as a merge.

A24 vs A37: Link and Unlink

A24 establishes a patient information link, while A37 unlinks previously linked patient records. Receiving applications should preserve the history of both relationship changes for auditing.

A24 vs A18: Linking and Legacy Merging

A18 historically communicates patient information merging, while A24 establishes a relationship without consolidating records. Their processing rules should remain separate.

A24 vs A40: Linking and Identifier Merging

A40 communicates a patient identifier merge, which changes identity relationships. A24 links records while preserving their independent identifiers and associated information.

A24 vs A08: Linking and Demographic Updates

A08 updates existing patient information, while A24 communicates a relationship between patient records. Demographic changes should not automatically create or remove patient links.

Best Practices for Reliable HL7 A24 Integration

Reliable HL7 A24 integration requires accurate identity matching, clear relationship semantics, and strict control over how linked patient information is displayed or accessed. Healthcare organizations should define which application is authoritative for patient linking, what evidence supports the relationship, and how links are canceled. Interfaces should validate complete patient identifiers, including assigning authorities, and prevent linking operations from triggering merges. Because linked records may expose protected health information across patient charts, authorization and audit controls are essential. These practices help maintain trustworthy patient identity relationships.

Validate Both Patient Identities

Require complete identifiers and assigning authorities for both records. Reject ambiguous matches rather than relying solely on names, birth dates, or other demographic similarities.

Preserve Independent Patient Records

An A24 link should not automatically merge records, reassign encounters, or overwrite identifiers. Maintain separate patient histories unless another authorized workflow explicitly changes them.

Enforce Relationship Authorization

Accept linking events only from approved applications and workflows. Verify that the requested relationship is supported before making linked patient information available.

Support A37 Unlink Processing

Define how the receiving system removes a link when an A37 event arrives. Preserve an audit history of the original link and subsequent cancellation.

Monitor Conflicting Identity Relationships

Track duplicate links, missing records, ambiguous identifiers, and contradictory relationship updates. Establish reconciliation procedures for correcting patient identity errors.

Frequently Asked Questions About HL7 ADT A24 Messages

HL7 A24 integration involves patient identity relationships, record linking, and safe information access across healthcare applications. Developers often need to distinguish linking from merging, identify the fields involved, and understand how an existing relationship can be canceled. These questions are especially important for enterprise master patient indexes and systems that maintain records from multiple facilities. The following answers address common technical concerns using HL7 Version 2 conventions. Actual implementation requirements depend on the supported message profile and destination identity management rules.

Need Help With HL7 ADT A24 Integration?

Patient information linking requires accurate identity management and careful handling of clinical data relationships. Taction Software supports HL7 interface development, Mirth Connect configuration, patient identifier mapping, and healthcare application integration. Our engineers can help organizations implement A24 linking workflows, distinguish links from merges, validate identifier domains, and establish reliable acknowledgment and monitoring procedures. Whether you are integrating an enterprise master patient index with an EHR or improving existing patient administration interfaces, accurate patient linking helps maintain consistent identity relationships across connected healthcare systems.

Custom HL7 Patient Linking Interfaces

We develop HL7 A24 interfaces based on source and destination requirements, including identifier validation, relationship mapping, routing, and acknowledgment handling.

Mirth Connect Channel Development

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

Enterprise Master Patient Index Integration

We help organizations connect patient identity management systems with EHRs, registration platforms, and other healthcare applications through controlled linking and unlinking workflows.

Production Monitoring and Support

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

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