HL7 ADT A26 Message: Cancel Pending Transfer, Structure, Segments & Examples

The HL7 A26 message is an Admit, Discharge, Transfer (ADT) event used to cancel a previously recorded pending patient transfer. Known as ADT A26 or Cancel Pending Transfer, it informs connected healthcare applications that an anticipated movement to another location will no longer proceed under the original plan. Unlike A12, which cancels a completed transfer, A26 concerns a transfer that has not yet taken place. Accurate A26 processing helps EHRs, patient administration systems, and bed management applications maintain consistent patient location and transfer planning information. This guide explains the message structure, field mapping, examples, Mirth Connect implementation, acknowledgments, and troubleshooting.

What Is an HL7 ADT A26 Message?

An HL7 ADT A26 message communicates the cancellation of a pending transfer for an existing patient encounter. It belongs to the HL7 Version 2 patient administration event family and supports workflows in which a patient's transfer has been planned but not completed. A26 typically relates to an earlier A15 pending transfer notification. When the planned movement is canceled, receiving systems should update the pending transfer state without treating the event as a completed transfer reversal. Understanding A26 within the broader HL7 ADT messaging framework helps integration teams distinguish transfer planning changes from actual patient movement.

Purpose of the HL7 A26 Event

A26 communicates that a previously recorded pending transfer has been canceled. Receiving applications use the event to update transfer planning status while preserving the existing patient encounter.

When Is an ADT A26 Message Generated?

An A26 notification may be generated when authorized hospital staff cancel a planned transfer because the patient's clinical condition, bed availability, or care arrangements have changed.

Which Healthcare Systems Receive A26 Messages?

EHRs, patient administration systems, nursing applications, and bed management platforms may receive A26 notifications. Each destination processes the cancellation according to its supported transfer workflow.

How A26 Supports Patient Location Accuracy

A26 helps connected applications distinguish planned patient movement from completed transfers. This reduces incorrect destination bed reservations and inconsistent transfer status information.

Why Accurate A26 Processing Matters

Incorrect A26 processing can leave outdated transfer requests active, affect bed allocation, or create conflicting patient location records. Reliable integration requires accurate encounter matching and transfer status validation.

HL7 ADT A26 Message Structure and Segments

An HL7 ADT A26 message follows the segment-based format defined by HL7 Version 2. In HL7 v2.5, A26 uses the ADT_A21 message structure, which is shared by several patient administration events. The core message commonly includes MSH, EVN, PID, and PV1 segments, with additional segments depending on the implementation profile. MSH identifies the event and source application, EVN records event information, PID identifies the patient, and PV1 provides encounter and location context. Receiving applications must interpret A26 as cancellation of a pending transfer rather than reversal of an actual completed transfer.

MSH Segment: Message Header

MSH identifies the sending and receiving applications, message timestamp, control identifier, and HL7 version. MSH-9 identifies A26 as the cancel pending transfer event.

EVN Segment: Event Information

EVN records event metadata, including the timestamp associated with the cancellation. Receiving applications may use it to reconcile changes in transfer planning status.

PID Segment: Patient Identification

PID identifies the patient whose pending transfer is being canceled. Receiving applications should validate patient identifiers and assigning authorities before modifying encounter information.

PV1 Segment: Patient Visit Information

PV1 contains encounter information, including patient class, assigned location, and visit number. These fields help identify the encounter affected by the transfer cancellation.

Optional Segments and Transfer Context

Additional segments or fields may provide transfer-related administrative information. Their use depends on the HL7 version, sending application, and agreed interface profile.

HL7 ADT A26 Message Example With Field Explanation

The following HL7 ADT A26 example illustrates a fictional inpatient whose planned transfer has been canceled. The message uses HL7 v2.5 conventions and contains MSH, EVN, PID, and PV1 segments. MSH-9 identifies ADT^A26^ADT_A21, PID-3 identifies the patient, and PV1-19 identifies the existing encounter. The example assumes that an earlier pending transfer event was recorded and that the patient remains in the current assigned location. Receiving applications should cancel the pending transfer without creating a new admission or reversing a completed transfer.

Complete HL7 ADT A26 Sample Message

MSH|^~\&|ADT_SYSTEM|HOSPITAL|EHR|MAIN|20261016160000||ADT^A26^ADT_A21|MSG26001|P|2.5
EVN|A26|20261016155500
PID|1||P260001^^^HOSPITAL^MR||MILLER^DAVID||19751114|M
PV1|1|I|WARD2^215^A||||1234^SMITH^ANNA||||||||||||V26001

All patient information is fictional. The example represents cancellation of a planned transfer, not an actual change in patient location.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies ADT_SYSTEM as the sending application and EHR as the receiver. ADT^A26^ADT_A21 identifies the cancellation event and message structure.

EVN Segment Explained

EVN identifies A26 as the event and records its timestamp. Integration teams can use this information to investigate when the pending transfer was canceled.

PID-3: Patient Identifier Explained

PID-3 identifies fictional patient David Miller using identifier P260001. The assigning authority helps the destination locate the correct patient record.

PV1-3: Assigned Patient Location Explained

PV1-3 identifies the patient's current assigned location. Receiving systems should not interpret the cancellation as evidence that the patient moved to another bed.

PV1-19: Visit Number Explained

PV1-19 identifies the existing encounter associated with the cancellation. Accurate visit matching prevents the A26 event from affecting another transfer request.

Important HL7 ADT A26 Fields and Mapping

Reliable HL7 A26 integration depends on accurate event identification, patient matching, and pending transfer status validation. Important fields include MSH-9 for the cancellation event, PID-3 for patient identification, PV1-19 for encounter matching, and EVN-2 for event timing. PV1-3 provides assigned location information, while pending location details may be represented through fields defined by the sending application's interface profile. A26 should not be treated as proof that the patient has physically moved. Clear HL7 v2 integration specifications help prevent inconsistent location and bed reservation information.

MSH-9: Identifying the A26 Event

MSH-9 identifies A26 as the trigger event. Integration engines should apply pending transfer cancellation logic rather than ordinary transfer or transfer reversal processing.

PID-3: Matching the Correct Patient

PID-3 contains patient identifiers and assigning authorities. Receiving applications should validate the complete identifier context before updating the pending transfer state.

PV1-19: Identifying the Existing Encounter

PV1-19 contains the visit number associated with the planned transfer. Accurate matching prevents cancellation from affecting unrelated patient encounters.

PV1-3: Maintaining the Current Location

PV1-3 provides assigned location information. Receiving systems should preserve the authoritative current location unless another event or validated workflow requires an update.

EVN-2: Recording Cancellation Timing

EVN-2 records the event timestamp. Integration teams can use it to investigate delayed messages and determine the appropriate order of transfer planning events.

How HL7 ADT A26 Messages Work in Healthcare Integration

An HL7 ADT A26 workflow begins when an authorized healthcare application records that a pending patient transfer has been canceled. The source patient administration system generates an A26 notification containing patient and encounter information. An integration engine receives the message, validates its structure, and routes it to connected applications. Receiving systems locate the existing encounter, identify the pending transfer, and cancel the planned movement according to their supported workflows. Bed reservations or transfer queues may also require updates. Reliable processing depends on accurate patient matching, event sequencing, acknowledgment handling, and duplicate prevention.

Step 1: Pending Transfer Cancellation Is Recorded

Authorized hospital staff cancel a planned patient transfer. The source patient administration system generates an A26 notification for connected applications.

Step 2: Validate the HL7 Message

The integration engine validates the A26 event, patient identifier, visit number, and event timestamp. Invalid notifications should enter an exception workflow.

Step 3: Match the Existing Encounter

Receiving applications identify the patient and encounter associated with the pending transfer. Accurate matching prevents cancellation from affecting another patient's movement.

Step 4: Cancel the Pending Transfer

The destination removes the applicable pending transfer state. It should not automatically move the patient, reverse a completed transfer, or create a new admission.

Step 5: Update Bed Management and Acknowledge

Connected systems update supported bed reservations and transfer planning queues. The receiving application returns an acknowledgment and records the processing outcome.

How to Implement HL7 ADT A26 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route HL7 ADT A26 notifications between patient administration systems, EHRs, and bed management applications. A typical channel receives an A26 message through an MLLP listener, validates the event type, extracts patient and encounter identifiers, and sends a cancellation request to the destination system. The destination must confirm that a pending transfer exists before applying the cancellation. Production interfaces should also account for missing A15 messages, duplicate cancellations, delayed notifications, and transfers that have already been completed. Mirth Connect development services can help implement these workflows.

Configure the HL7 Source Connector

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

Filter HL7 ADT A26 Messages

Use a source filter to identify A26 notifications. Keep pending transfer cancellations separate from completed transfer events and other patient administration 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 === 'A26';

Extract Patient and Encounter Information

Use a JavaScript transformer to extract the patient identifier, assigning authority, visit number, current location, event timestamp, and message control identifier.

Mirth Connect JavaScript transformer:

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

    var node = msg[segment][fieldName][partName];

    return node.toString().trim();
}

var patientId = getComponent('PID', 3, 1);
var assigningAuthority = getComponent('PID', 3, 4);

var visitNumber = getComponent('PV1', 19, 1);
var patientClass = getComponent('PV1', 2, 1);

var unit = getComponent('PV1', 3, 1);
var room = getComponent('PV1', 3, 2);
var bed = getComponent('PV1', 3, 3);

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

if (!patientId || !assigningAuthority) {
    throw new Error(
        'A26 missing patient identity information'
    );
}

if (!visitNumber) {
    throw new Error('A26 missing visit number');
}

if (!eventTimestamp || !messageControlId) {
    throw new Error(
        'A26 missing required message metadata'
    );
}

var cancellationEvent = {
    eventType: 'A26',
    patientId: patientId,
    assigningAuthority: assigningAuthority,
    visitNumber: visitNumber,
    patientClass: patientClass,
    currentLocation: {
        unit: unit,
        room: room,
        bed: bed
    },
    eventTimestamp: eventTimestamp,
    messageControlId: messageControlId
};

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

The example assumes that Mirth Connect has parsed the HL7 message into its XML representation. Production code should account for repeating patient identifiers and complete assigning-authority components.

Transform A26 Into a Pending Transfer Cancellation Request

Create a destination-specific request identifying the existing encounter and the pending transfer to be canceled. The destination should verify the pending transfer before changing its status.

Example JSON transformation:

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

var cancellationRequest = {
    eventType: 'A26',
    action: 'cancelPendingTransfer',
    patient: {
        identifier: event.patientId,
        assigningAuthority:
            event.assigningAuthority
    },
    encounter: {
        visitNumber: event.visitNumber,
        patientClass: event.patientClass
    },
    currentLocation: event.currentLocation,
    eventTimestamp: event.eventTimestamp,
    messageControlId: event.messageControlId
};

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

This payload is illustrative and is not a standardized HL7 API. Production systems may require an additional transfer request identifier to cancel the correct pending movement.

Validate the Pending Transfer Before Cancellation

Confirm that the patient has an active encounter and an eligible pending transfer. If the transfer is already completed, use the appropriate reconciliation workflow.

HL7 ADT A26 ACK Message Examples and Error Handling

HL7 acknowledgment messages allow sending applications to determine whether an A26 notification was accepted or rejected under the configured acknowledgment mode. An ACK generally includes MSH and MSA segments, with ERR used when additional error information is necessary. Common original-mode application acknowledgment codes include AA for acceptance, AE for application error, and AR for rejection. For pending transfer cancellation, the interface agreement should define whether an acknowledgment confirms message acceptance or successful cancellation in the destination application.

Successful ACK Response: AA

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

MSH|^~\&|EHR|MAIN|ADT_SYSTEM|HOSPITAL|20261016160001||ACK^A26^ACK|ACK26001|P|2.5
MSA|AA|MSG26001

Application Error Response: AE

An AE response indicates an application processing error. Missing encounters, unknown patient identifiers, or invalid pending transfer states may prevent successful processing.

MSH|^~\&|EHR|MAIN|ADT_SYSTEM|HOSPITAL|20261016160002||ACK^A26^ACK|ACK26002|P|2.5
MSA|AE|MSG26001
ERR|||204^Unknown Key Identifier^HL70357|E

Application Rejection Response: AR

An AR acknowledgment indicates that the receiving application rejected the notification. Unsupported events, invalid message profiles, or unauthorized requests may result in rejection.

MSH|^~\&|EHR|MAIN|ADT_SYSTEM|HOSPITAL|20261016160003||ACK^A26^ACK|ACK26003|P|2.5
MSA|AR|MSG26001

Correlate ACK Responses With Cancellation Events

MSA-2 identifies the original message control identifier. Integration teams use this value to connect acknowledgments, retries, and destination processing outcomes to the corresponding A26 notification.

Handle Failed Acknowledgments and Retries

Separate temporary connectivity failures from permanent application errors. Use controlled retries and idempotency checks to prevent duplicate cancellation attempts or inconsistent transfer records.

Common HL7 ADT A26 Integration Errors and Troubleshooting

HL7 A26 integration problems commonly involve missing pending transfer records, incorrect encounter identifiers, delayed messages, and confusion between pending transfer cancellation and completed transfer reversal. A receiving application may reject A26 because it never received the original A15 event or because the patient has already moved. Bed management systems may also retain reservations after the pending transfer is canceled. Troubleshooting should examine the original HL7 message, patient and visit identifiers, event history, acknowledgment responses, and destination workflow rules. Accurate HL7 parsing and data mapping helps prevent these failures.

Pending Transfer Record Cannot Be Found

The destination may not have received the original A15 notification or may store the pending transfer under a different identifier. Verify the authoritative transfer history.

A26 Is Mistaken for A12

A26 cancels a pending transfer, while A12 cancels an actual transfer. Incorrect mapping can reverse completed patient movements or leave planned transfers active.

Incorrect Patient or Visit Identifier

The destination may fail to match PID-3 or PV1-19. Validate the complete patient identifier and encounter number before modifying transfer planning records.

Duplicate Cancellation Notifications

Repeated A26 messages may arrive after a pending transfer has already been canceled. Use message control identifiers and transfer state to avoid duplicate processing.

Cancellation Arrives After a Completed Transfer

A delayed A26 may arrive after an A02 transfer. Receiving systems should reconcile the authoritative encounter history rather than automatically reversing the completed movement.

HL7 ADT A26 vs A15, A12, A02, and A01

HL7 ADT events distinguish planned patient transfers, canceled transfer plans, completed transfers, and admission workflows. A15 communicates a pending transfer, while A26 cancels that pending transfer. A02 communicates an actual transfer, and A12 cancels a completed transfer. A01 represents an admission or visit notification. Although these messages may contain similar patient and encounter information, their operational meanings differ. Receiving applications should use event-specific processing rules to prevent transfer planning changes from incorrectly modifying actual patient locations.

A26 vs A15: Cancellation and Pending Transfer

A15 communicates that a transfer is pending, while A26 cancels that pending transfer. Both events should reference the appropriate patient encounter and planned movement.

A26 vs A12: Pending and Completed Transfer Cancellation

A26 cancels a transfer that has not yet occurred. A12 cancels a completed transfer. Receiving applications must distinguish these events to preserve accurate location histories.

A26 vs A02: Cancellation and Actual Transfer

A02 records actual patient movement between locations. A26 cancels a planned movement and should not automatically reverse an A02 transfer.

A26 vs A01: Cancellation and Admission

A01 communicates an admission or visit notification. A26 does not create a new admission; it updates the pending transfer state of an existing encounter.

Best Practices for Reliable HL7 A26 Integration

Reliable HL7 A26 integration requires accurate encounter matching, clear pending transfer rules, and coordination with downstream bed management systems. Healthcare organizations should document how A15 and A26 events affect patient movement requests, destination bed reservations, and transfer queues. Interfaces should validate patient identifiers, visit numbers, event timestamps, and existing transfer states before processing. They should also prevent duplicate cancellations, handle delayed notifications, and maintain auditable processing records. Secure transmission and controlled access are essential because ADT messages contain protected health information.

Validate the Existing Pending Transfer

Confirm that the encounter has a pending transfer eligible for cancellation. Missing or conflicting transfer states should enter a controlled reconciliation workflow.

Preserve the Authoritative Patient Location

Cancel only the planned movement. Do not automatically change the current assigned location or reverse a completed transfer without a separate authorized event.

Coordinate Bed Reservation Updates

Notify connected bed management applications when a pending transfer is canceled. Release destination reservations only according to the facility's approved allocation rules.

Prevent Duplicate and Out-of-Sequence Processing

Use message control identifiers, event timestamps, and authoritative transfer status to prevent repeated cancellations or older notifications overwriting newer patient movement records.

Monitor Exceptions and Maintain Audit Records

Track rejected notifications, missing transfer requests, invalid visit identifiers, and delayed events. Maintain appropriate audit records and recovery procedures for unresolved transfer discrepancies.

Frequently Asked Questions About HL7 ADT A26 Messages

HL7 A26 integration involves pending transfer cancellation, encounter continuity, and coordination with patient location management systems. Healthcare developers often need to distinguish A26 from A12, identify the correct patient encounter, and handle notifications that arrive after a transfer has already occurred. These questions are especially important when multiple applications independently track patient movements and bed reservations. The following answers address common technical concerns using HL7 Version 2 conventions. Actual processing behavior depends on the sending application, receiving system, and agreed interface implementation guide.

Need Help With HL7 ADT A26 Integration?

Reliable pending transfer cancellation messaging helps healthcare organizations maintain accurate patient movement and bed reservation information when transfer plans change. Taction Software supports HL7 interface development, Mirth Connect configuration, patient and encounter matching, and healthcare application integration. Our engineers can help organizations implement A26 processing, distinguish pending transfer cancellation from completed transfer reversal, and establish dependable acknowledgment and monitoring procedures. Whether you are connecting a patient administration system to an EHR or improving existing ADT interfaces, accurate A26 processing supports consistent transfer planning information across connected healthcare applications.

Custom HL7 Transfer Management Interfaces

We develop HL7 A26 interfaces based on source and destination requirements, including patient matching, encounter validation, pending transfer cancellation, and acknowledgment handling.

Mirth Connect Channel Development

Our engineers configure Mirth Connect channels for transfer planning notifications, including event filtering, JavaScript transformations, secure destination connectivity, and exception management.

EHR and Bed Management Integration

We help organizations coordinate pending transfer changes between EHRs, patient administration platforms, and hospital bed management applications.

Production Monitoring and Support

We support HL7 interfaces through monitoring, failure alerts, mapping updates, and recovery procedures that help maintain dependable patient administration messaging.

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