HL7 ADT A25 Message: Cancel Pending Discharge, Structure, Segments & Examples

The HL7 A25message is an Admit, Discharge, Transfer (ADT) event used to cancel a previously recorded pending discharge. Known as ADT A25 or Cancel Pending Discharge, it informs connected healthcare systems that a patient's planned discharge is no longer pending under the original administrative workflow. Unlike an A13 event, which cancels an actual discharge, A25 addresses a discharge that has not yet been completed. Accurate A25 processing helps EHRs, patient administration systems, bed management applications, and discharge planning tools maintain consistent encounter information. This guide explains message structure, field mapping, examples, Mirth Connect implementation, acknowledgments, and troubleshooting.

What Is an HL7 ADT A25 Message?

An HL7 ADT A25 message communicates the cancellation of a pending discharge for an existing patient encounter. It belongs to the HL7 Version 2 patient administration event family and is associated with workflows in which a discharge has been planned but not yet completed. A25 typically relates to an earlier A16 pending discharge notification. When the planned discharge is canceled, connected applications need to update their administrative records without treating the patient as newly admitted or reversing a completed discharge. Understanding A25 within the broader HL7 ADT messaging framework helps integration teams distinguish discharge planning changes from completed encounter transitions.

Purpose of the HL7 A25 Event

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

When Is an ADT A25 Message Generated?

An A25 notification may be generated when authorized staff cancel a planned discharge because the patient requires continued care or the discharge arrangements have changed.

Which Healthcare Systems Receive A25 Messages?

EHRs, patient administration systems, bed management applications, and discharge planning platforms may receive A25 notifications. Each destination updates its supported workflow according to the agreed interface specification.

How A25 Supports Discharge Planning Accuracy

A25 helps connected systems distinguish patients whose discharge remains pending from those whose planned discharge has been canceled. This reduces inconsistent administrative status information.

Why Accurate A25 Processing Matters

Incorrect A25 processing can leave discharge plans active, trigger premature bed availability changes, or produce inconsistent encounter records. Reliable integration requires correct event interpretation and visit matching.

HL7 ADT A25 Message Structure and Segments

An HL7 ADT A25 message follows the segment-based format used by HL7 Version 2. In HL7 v2.5, A25 uses the ADT_A21 message structure, which supports 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 sending application, EVN records event information, PID identifies the patient, and PV1 supplies encounter details. Receiving applications should use the A25 trigger event to cancel the pending discharge state without automatically changing the encounter to discharged or readmitted.

MSH Segment: Message Header

MSH identifies the sending and receiving applications, message timestamp, control identifier, and HL7 version. MSH-9 identifies A25 as the cancel pending discharge 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 discharge planning status.

PID Segment: Patient Identification

PID identifies the patient whose pending discharge 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 visit affected by the pending discharge cancellation.

Optional Segments and Discharge Planning Context

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

HL7 ADT A25 Message Example With Field Explanation

The following HL7 ADT A25 example illustrates a fictional inpatient whose planned discharge has been canceled. The message uses HL7 v2.5 conventions and contains MSH, EVN, PID, and PV1 segments. MSH-9 identifies ADT^A25^ADT_A21, PID-3 identifies the patient, and PV1-19 identifies the existing encounter. The example assumes that an earlier pending discharge event was recorded and that the patient remains admitted. Receiving applications should cancel the pending discharge state without creating a new admission or treating the event as a reversal of an actual discharge.

Complete HL7 ADT A25 Sample Message

MSH|^~\&|ADT_SYSTEM|HOSPITAL|EHR|MAIN|20261016140000||ADT^A25^ADT_A21|MSG25001|P|2.5
EVN|A25|20261016135500
PID|1||P250001^^^HOSPITAL^MR||DAVIS^ROBERT||19680821|M
PV1|1|I|WARD3^312^B||||1234^SMITH^ANNA||||||||||||V25001

All patient information is fictional. The message illustrates cancellation of a pending discharge associated with an existing inpatient encounter.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies ADT_SYSTEM as the sender and EHR as the receiver. ADT^A25^ADT_A21 identifies the cancellation event and message structure, while MSG25001 supports tracking.

EVN Segment Explained

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

PID-3: Patient Identifier Explained

PID-3 identifies fictional patient Robert Davis using identifier P250001. The assigning authority provides context for matching the correct patient record.

PV1-3: Assigned Patient Location Explained

PV1-3 contains the patient's assigned location. Receiving applications should preserve or reconcile this information according to the current encounter and bed management state.

PV1-19: Visit Number Explained

PV1-19 identifies the encounter affected by the cancellation. Accurate visit matching prevents the A25 event from changing discharge plans associated with unrelated encounters.

Important HL7 ADT A25 Fields and Mapping

Reliable HL7 A25 integration depends on accurate event identification, patient matching, and encounter status validation. Important fields include MSH-9 for identifying 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 discharge-related fields must be interpreted according to the source application's workflow. An A25 event should not be treated as evidence that an actual discharge occurred. Clear HL7 v2 integration specifications help receiving applications distinguish pending discharge cancellation from completed discharge reversal.

MSH-9: Identifying the A25 Event

MSH-9 identifies A25 as the trigger event. Integration engines should apply pending discharge cancellation logic rather than discharge, admission, or transfer processing.

PID-3: Matching the Correct Patient

PID-3 contains patient identifiers and assigning authorities. Receiving applications should use the complete identifier context to locate the correct patient record.

PV1-19: Identifying the Existing Encounter

PV1-19 contains the visit number associated with the pending discharge. Accurate matching prevents cancellation from affecting another encounter belonging to the same patient.

EVN-2: Recording Cancellation Timing

EVN-2 records the event timestamp. Integration teams can use this value for auditing, event sequencing, and reconciliation of delayed discharge planning notifications.

PV1-3: Maintaining Accurate Location Information

PV1-3 identifies the assigned patient location. Receiving applications should validate this information before making bed management changes related to the canceled discharge.

How HL7 ADT A25 Messages Work in Healthcare Integration

An HL7 ADT A25 workflow begins when an authorized healthcare application records that a pending discharge has been canceled. The source patient administration system generates an A25 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 discharge state, and cancel it according to their supported workflow. The patient remains associated with the encounter, and downstream discharge planning or bed management actions may need updating. Reliable processing requires event sequencing, acknowledgment handling, and duplicate prevention.

Step 1: Pending Discharge Cancellation Is Recorded

Authorized staff cancel a planned discharge in the source application. The patient administration system generates an A25 notification for connected applications.

Step 2: Validate the HL7 Message

The integration engine validates the A25 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 discharge. Accurate matching prevents cancellation from affecting unrelated visits.

Step 4: Cancel the Pending Discharge State

The destination removes the applicable pending discharge status. It should not create a new admission or reverse an actual completed discharge.

Step 5: Update Downstream Systems and Acknowledge

Connected applications update supported discharge planning and bed management workflows. The receiving application returns an acknowledgment and records the processing outcome.

How to Implement HL7 ADT A25 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route HL7 ADT A25 messages between hospital information systems, EHRs, and discharge planning applications. A typical implementation receives the message through an MLLP listener, identifies the A25 trigger event, extracts patient and encounter information, and updates the appropriate pending discharge workflow. The destination must verify that a pending discharge exists before applying the cancellation. Production implementations should also handle duplicate notifications, missing A16 events, delayed messages, and conflicting discharge states. 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, authenticated connectivity, acknowledgment settings, and message retention policies.

Filter HL7 ADT A25 Messages

Use a source filter to accept A25 events and separate pending discharge cancellation from completed discharge reversal, admission, and transfer 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 === 'A25';

This filter identifies the event only. Production channels should independently validate the sender, message profile, and destination authorization.

Extract Patient and Encounter Information

Use a JavaScript transformer to extract the patient identifier, assigning authority, visit number, assigned location, and event timestamp. Validate required fields before routing the cancellation.

Mirth Connect JavaScript transformer:

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

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

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

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

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

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

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

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

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

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

var cancellation = {
    eventType: 'A25',
    patientId: patientId,
    assigningAuthority: assigningAuthority,
    visitNumber: visitNumber,
    patientClass: patientClass,
    location: {
        unit: unit,
        room: room,
        bed: bed
    },
    eventTimestamp: eventTimestamp,
    messageControlId: messageControlId
};

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

This example assumes Mirth Connect has parsed the HL7 message into its XML representation. Production implementations should handle repeating identifiers, complete assigning-authority components, and the destination's specific encounter identifier requirements.

Transform A25 Into a Pending Discharge Cancellation Request

Create a destination-specific payload that identifies the existing encounter and requests cancellation of its pending discharge. Do not map the event to a completed discharge reversal.

Example JSON transformation:

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

var cancellationRequest = {
    eventType: 'A25',
    action: 'cancelPendingDischarge',
    patient: {
        identifier: event.patientId,
        assigningAuthority:
            event.assigningAuthority
    },
    encounter: {
        visitNumber: event.visitNumber,
        patientClass: event.patientClass
    },
    assignedLocation: event.location,
    eventTimestamp: event.eventTimestamp,
    messageControlId: event.messageControlId
};

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

The JSON payload is illustrative rather than a standardized HL7 API. The receiving system must verify the encounter's current status and whether a pending discharge is eligible for cancellation.

Validate the Pending Discharge Before Updating

The destination should confirm that the patient has an existing encounter with a pending discharge. Missing or conflicting states require reconciliation rather than automatic encounter modification.

HL7 ADT A25 ACK Message Examples and Error Handling

HL7 acknowledgment messages allow sending applications to determine whether an A25 notification was accepted or rejected under the configured acknowledgment mode. An ACK typically includes 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. Acceptance does not always prove that every downstream discharge planning application has updated its records. Integration teams should define when acknowledgments are generated and how cancellation outcomes are monitored.

Successful ACK Response: AA

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

MSH|^~\&|EHR|MAIN|ADT_SYSTEM|HOSPITAL|20261016140001||ACK^A25^ACK|ACK25001|P|2.5
MSA|AA|MSG25001

Application Error Response: AE

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

MSH|^~\&|EHR|MAIN|ADT_SYSTEM|HOSPITAL|20261016140002||ACK^A25^ACK|ACK25002|P|2.5
MSA|AE|MSG25001
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 profiles, or unauthorized processing requests may result in rejection.

MSH|^~\&|EHR|MAIN|ADT_SYSTEM|HOSPITAL|20261016140003||ACK^A25^ACK|ACK25003|P|2.5
MSA|AR|MSG25001

Correlate ACK Responses With A25 Notifications

MSA-2 identifies the original message control identifier. Integration teams use this value to associate acknowledgment responses, retries, and destination outcomes with the corresponding cancellation event.

Handle Failed Acknowledgments and Retries

Distinguish temporary transport failures from application validation errors. Use controlled retries and idempotent processing to prevent duplicate cancellations or inconsistent encounter states.

Common HL7 ADT A25 Integration Errors and Troubleshooting

HL7 A25 integration problems commonly involve missing pending discharge records, incorrect encounter identifiers, delayed events, and confusion between A25 and A13. A receiving application may reject the cancellation because it never received the original A16 notification or because the encounter has already been discharged. Other failures occur when bed management applications have already acted on an anticipated discharge. 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 problems.

Pending Discharge Record Cannot Be Found

The destination may not have received the original A16 notification. Verify encounter history and source state before creating or modifying pending discharge records.

A25 Is Mistaken for A13

A25 cancels a pending discharge, while A13 cancels an actual discharge. Incorrect event mapping may reopen completed encounters or leave discharge plans active.

Incorrect Patient or Visit Identifier

The destination may fail to match PID-3 or PV1-19. Validate the complete patient identifier and visit number before updating discharge planning status.

Duplicate Cancellation Notifications

Repeated A25 messages may arrive after the pending discharge has already been canceled. Use message identifiers and current encounter state to avoid duplicate processing.

Cancellation Arrives After Completed Discharge

A delayed A25 may arrive after an A03 discharge. Receiving systems should reconcile the authoritative encounter history rather than automatically reopening the visit.

HL7 ADT A25 vs A16, A13, A03, and A01

HL7 ADT events distinguish pending discharge, discharge cancellation, completed discharge, and admission workflows. A16 communicates a pending discharge, while A25 cancels that pending discharge. A03 communicates an actual discharge or end of visit, and A13 cancels a completed discharge event. A01 represents an admission or visit notification. These events may contain similar patient and encounter fields, but their operational meanings differ. Receiving applications should implement event-specific processing rules so discharge planning changes do not accidentally alter completed encounter histories.

A25 vs A16: Cancellation and Pending Discharge

A16 communicates that a discharge is pending, while A25 cancels that pending status. Both events should reference the appropriate existing encounter.

A25 vs A13: Pending and Completed Discharge Cancellation

A25 cancels a pending discharge, while A13 reverses a completed discharge event. Their processing rules must remain separate to protect encounter history.

A25 vs A03: Cancellation and Actual Discharge

A03 communicates a completed discharge or end of visit. A25 cancels a planned discharge and should not automatically reverse an A03 event.

A25 vs A01: Cancellation and Admission

A01 communicates an admission or visit notification. A25 does not create a new admission; it updates the discharge planning state of an existing encounter.

Best Practices for Reliable HL7 A25 Integration

Reliable HL7 A25 integration requires accurate encounter matching, clear pending discharge rules, and careful handling of downstream workflow changes. Healthcare organizations should document how A16 and A25 events affect patient administration systems, discharge planning applications, and bed management tools. Interfaces should validate patient identifiers, visit numbers, event timestamps, and existing discharge states before processing. They should also prevent duplicate cancellations, handle delayed messages, and maintain appropriate audit records. Secure transmission and controlled access are essential because ADT messages contain protected health information.

Validate the Existing Pending Discharge

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

Preserve the Correct Encounter Status

Cancel only the pending discharge state. Do not create a new admission, reopen a completed discharge, or alter unrelated encounters.

Coordinate Bed Management Updates

Notify connected bed management systems when a pending discharge is canceled. Avoid treating anticipated bed availability as confirmed patient departure.

Prevent Duplicate and Out-of-Sequence Processing

Use message control identifiers, event timestamps, and authoritative encounter state to prevent repeated cancellations or older events overwriting newer information.

Monitor Exceptions and Maintain Audit Records

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

Frequently Asked Questions About HL7 ADT A25 Messages

HL7 A25 integration involves pending discharge cancellation, encounter continuity, and downstream discharge planning coordination. Healthcare developers and IT teams often need to understand how A25 differs from A13, which fields identify the affected encounter, and how to handle notifications that arrive after a completed discharge. The following questions address common implementation 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 A25 Integration?

Reliable pending discharge cancellation messaging helps healthcare organizations maintain accurate patient and encounter information when discharge 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 A25 processing, distinguish pending discharge cancellation from completed discharge 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 A25 processing supports consistent discharge planning information across connected healthcare applications.

Custom HL7 Discharge Planning Interfaces

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

Mirth Connect Channel Development

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

EHR and Bed Management Integration

We help organizations coordinate pending discharge 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 discharge integration? Explore our HL7 interface messaging services to discuss your requirements.