HL7 ADT A13 Message: Cancel Discharge, Structure, Segments & Examples

The HL7 A13 message is an Admit, Discharge, Transfer (ADT) notification used to cancel a previously recorded patient discharge. Also known as ADT A13 or Cancel Discharge/End Visit, this HL7 Version 2 event helps EHRs, hospital administration systems, bed management platforms, and connected clinical applications correct encounter information when a discharge is reversed. Unlike a new admission notification, A13 communicates that an earlier discharge should be canceled and the encounter state corrected. This guide explains the HL7 ADT A13 message structure, PID and PV1 fields, practical HL7 examples, Mirth Connect JavaScript, acknowledgment handling, and troubleshooting.

What Is an HL7 ADT A13 Message?

An HL7 ADT A13 message communicates cancellation of a previously recorded discharge or end-of-visit notification. It belongs to the HL7 v2 patient administration message family and is used when an earlier discharge must be reversed. Receiving applications use A13 to correct encounter status and related administrative information according to their supported workflows. The event differs from a new admission because it refers to an existing encounter whose discharge notification is no longer valid. Understanding A13 within HL7 ADT messaging helps integration teams maintain accurate encounter histories and avoid duplicate admissions.

Purpose of the HL7 A13 Event

The A13 event communicates that an earlier discharge notification has been canceled. Receiving applications use it to reverse or correct discharge-related encounter information according to their supported workflows.

When Is an ADT A13 Message Generated?

An A13 notification may be generated when a discharge was entered incorrectly, canceled administratively, or requires reversal. The specific business conditions depend on hospital policies and application configuration.

Which Healthcare Systems Receive A13 Messages?

EHRs, billing systems, bed management platforms, laboratory applications, and hospital information systems may receive A13 notifications. Each destination processes the cancellation according to its encounter management requirements.

How A13 Supports Encounter Continuity

A13 allows connected applications to correct the effects of an earlier discharge without automatically creating a new admission. Accurate visit matching helps preserve the existing encounter relationship.

Why Accurate A13 Processing Matters

Incorrect A13 processing can reopen the wrong encounter, leave canceled discharges active, or create inconsistent downstream records. Reliable integration requires precise patient matching, visit identification, and cancellation rules.

HL7 ADT A13 Message Structure and Segments

An HL7 ADT A13 message follows the segment-based format defined by HL7 Version 2. Common segments include MSH, EVN, PID, and PV1, with additional segments depending on the implementation profile. MSH identifies the sender, receiver, message type, and version. EVN records event information, PID identifies the patient, and PV1 communicates encounter details. PV1-19 commonly contains the visit identifier, while PV1-45 can contain discharge date and time information. In HL7 v2.5, A13 uses the ADT_A01 message structure. Developers should validate segment requirements against the applicable interface specification.

MSH Segment: Message Header

MSH identifies the sending and receiving applications, message timestamp, control identifier, and HL7 version. MSH-9 identifies the A13 cancellation event and its associated ADT_A01 structure.

EVN Segment: Event Information

EVN records metadata about the discharge cancellation, including the event timestamp. Receiving applications may use this information for auditing and investigating delayed cancellation notifications.

PID Segment: Patient Identification

PID contains patient identifiers and demographic information. Receiving systems use these values to locate the correct patient before changing discharge-related encounter information.

PV1 Segment: Patient Visit Information

PV1 provides encounter information, including patient class, assigned location, visit number, and discharge date and time. Accurate visit identification is essential for applying the correct cancellation.

Optional Segments in A13 Messages

Additional segments may contain supplementary visit, diagnosis, or administrative information. Their presence and interpretation depend on the HL7 version and destination interface requirements.

HL7 ADT A13 Message Example With Field Explanation

The following HL7 ADT A13 example illustrates cancellation of a fictional patient's previously recorded discharge. The message follows HL7 v2.5 conventions and includes event metadata, patient identification, and encounter information. MSH-9 identifies the event as ADT^A13^ADT_A01. PID-3 identifies the patient, PV1-19 identifies the encounter, and PV1-45 may contain discharge-related timestamp information when populated. The sample demonstrates general cancellation concepts and should be adapted to the sending and receiving applications' implementation specifications before production use.

Complete HL7 ADT A13 Sample Message

MSH|^~\&|ADT_SYSTEM|HOSPITAL|EHR|MAIN|20261012190000||ADT^A13^ADT_A01|MSG13001|P|2.5
EVN|A13|20261012185500
PID|1||P567890^^^HOSPITAL^MR||THOMAS^LINDA||19771103|F
PV1|1|I|WARD4^410^A||||7890^BROWN^MICHAEL||||||||||||V90001

All patient information is fictional. The sample represents cancellation of a previously recorded discharge for the identified encounter, not creation of a new admission.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies ADT_SYSTEM as the sender and EHR as the receiver. ADT^A13^ADT_A01 identifies the cancellation event and message structure, while MSG13001 supports message tracking.

EVN Segment Explained

EVN identifies A13 as the event and records the cancellation timestamp. Integration teams can use this information to investigate delayed notifications and discharge history discrepancies.

PID-3: Patient Identifier Explained

PID-3 identifies fictional patient Linda Thomas using identifier P567890. Receiving applications should validate the identifier and assigning authority before applying discharge cancellation.

PV1-19: Visit Number Explained

PV1-19 identifies the encounter affected by the cancellation. Accurate visit matching helps receiving systems reverse the correct discharge without reopening unrelated patient encounters.

PV1-45: Discharge Date and Time Explained

PV1-45 can contain discharge date and time information. During cancellation, its population and interpretation depend on the source interface specification and the receiving application's update rules.

Important HL7 ADT A13 Fields and Mapping

Reliable HL7 A13 integration depends on accurate patient and encounter identification. Important fields include MSH-9 for event identification, PID-3 for patient matching, and PV1-19 for visit matching. PV1-45 may contain discharge date and time information, but its handling during cancellation varies by application. Receiving systems should determine whether to clear, retain, or otherwise correct discharge-related values according to their documented workflows. Developers should define these behaviors before implementing HL7 v2 integration to avoid inconsistent encounter states across connected applications.

MSH-9: Identifying the Cancellation Event

MSH-9 identifies the A13 event. Integration engines use this value to apply discharge cancellation logic rather than admission, discharge, transfer, or routine update 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 before modifying discharge-related information.

PV1-19: Identifying the Encounter

PV1-19 identifies the visit associated with the canceled discharge. Accurate matching helps receiving systems reverse the correct discharge without changing unrelated encounters.

PV1-45: Handling Discharge Timestamps

PV1-45 can contain discharge date and time information. Receiving systems should follow documented rules for clearing, retaining, or correcting the value during cancellation processing.

MSH-10: Tracking the Cancellation Message

MSH-10 contains the control identifier for the A13 notification. This value supports acknowledgment correlation and duplicate detection but does not automatically identify the original discharge message.

How HL7 ADT A13 Messages Work in Healthcare Integration

An HL7 ADT A13 workflow begins when a healthcare organization cancels a previously recorded discharge. The source patient administration system generates an A13 notification containing patient and encounter identifiers. An integration engine receives the message, validates its structure, and routes it to connected applications. Receiving systems locate the affected encounter and apply the supported discharge cancellation behavior. This may involve reopening the encounter, correcting discharge information, or updating related administrative records. Reliable processing requires accurate matching, acknowledgment handling, duplicate prevention, and monitoring to maintain consistent encounter information.

Step 1: Discharge Cancellation Is Recorded

The patient administration system records cancellation of an earlier discharge. The source application generates an A13 notification containing the patient and visit identifiers required by receiving systems.

Step 2: Message Validation

The integration engine validates the HL7 structure, A13 trigger event, patient identifiers, and visit information. Invalid notifications should enter a controlled exception workflow instead of modifying encounters.

Step 3: Identify the Original Discharge

Receiving applications locate the patient, encounter, and original discharge associated with the cancellation. Matching rules should prevent unrelated encounters from being reopened.

Step 4: Apply Discharge Reversal Rules

The destination applies its supported cancellation workflow. This may reopen the encounter, correct discharge timestamps, or update related administrative and bed management records.

Step 5: Acknowledgment and Monitoring

The receiving application returns an acknowledgment under the configured HL7 processing mode. Integration teams monitor failures, delays, and reconciliation exceptions to maintain consistent encounter information.

How to Implement HL7 ADT A13 Messages Using Mirth Connect

Mirth Connect supports HL7 ADT A13 integration through configurable channels, filters, transformers, and destination connectors. Developers can receive cancellation notifications through MLLP, identify the A13 trigger event, extract patient and visit identifiers, and route the message to receiving applications. JavaScript transformers can validate required values and prepare destination-specific cancellation requests. Production implementations should also handle duplicate notifications, acknowledgments, and cases where the original discharge cannot be located. Organizations managing complex healthcare interfaces can use Mirth Connect development services to support channel implementation and maintenance.

Configure an HL7 Source Connector

Create a Mirth Connect channel using an MLLP listener or another supported transport connector. Configure the expected HL7 version, network endpoint, security requirements, and message data type.

Filter ADT A13 Messages

Configure a source filter that checks MSH-9 and accepts the A13 trigger event. This prevents unrelated admission, discharge, and transfer messages from entering cancellation processing.

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

Extract Patient and Encounter Identifiers

Use a JavaScript transformer to extract the patient identifier, visit number, and message control identifier. Validate required values before forwarding the cancellation to the destination.

Mirth Connect JavaScript transformer:

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

var visitNumber =
    msg['PV1']['PV1.19']['PV1.19.1'].toString();

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

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

if (!patientId || !visitNumber) {
    throw new Error(
        'Missing patient identifier or visit number'
    );
}

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

channelMap.put('patientId', patientId);
channelMap.put('visitNumber', visitNumber);
channelMap.put('messageControlId', messageControlId);
channelMap.put('eventType', eventType);

The example assumes an HL7 v2 message parsed into Mirth Connect's XML representation. Production implementations should account for assigning authorities, repeating identifiers, and destination-specific discharge cancellation rules.

Transform A13 Data for Destination Systems

Use a transformer to prepare the receiving application's required cancellation payload. Preserve patient and visit identifiers so the destination can identify the correct discharge.

Example JSON transformation:

var cancellationData = {
    eventType: 'A13',
    action: 'cancelDischarge',
    patientId: channelMap.get('patientId'),
    visitNumber: channelMap.get('visitNumber'),
    messageControlId: channelMap.get('messageControlId')
};

var jsonPayload = JSON.stringify(cancellationData);

channelMap.put('jsonPayload', jsonPayload);

The JSON structure is illustrative. The destination must define how to identify the original discharge and apply the appropriate cancellation behavior.

Test and Monitor Cancellation Processing

Test valid cancellations, missing encounters, repeated A13 notifications, incorrect identifiers, and destination failures. Monitor acknowledgments and reconciliation exceptions to detect incomplete discharge reversals.

HL7 ADT A13 ACK Message Examples and Error Handling

HL7 acknowledgment messages help sending applications determine whether A13 cancellation notifications were accepted or rejected under the configured acknowledgment mode. An ACK response contains an acknowledgment code and the original message control identifier. Common application acknowledgment codes include AA for acceptance, AE for application error, and AR for rejection. These responses support message tracking and controlled recovery. However, successful acknowledgment does not necessarily confirm completion of every downstream cancellation operation. Integration teams should document acknowledgment semantics, retry behavior, and reconciliation procedures to prevent inconsistent encounter states.

Successful ACK Response: AA

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

MSH|^~\&|EHR|MAIN|ADT_SYSTEM|HOSPITAL|20261012190001||ACK^A13^ACK|ACK13001|P|2.5
MSA|AA|MSG13001

Application Error Response: AE

An AE acknowledgment indicates an application error during cancellation processing. Additional error information may identify missing encounters, invalid identifiers, or unsupported discharge reversal conditions.

MSH|^~\&|EHR|MAIN|ADT_SYSTEM|HOSPITAL|20261012190002||ACK^A13^ACK|ACK13002|P|2.5
MSA|AE|MSG13001
ERR|||204^Unknown Key Identifier^HL70357|E

Application Rejection Response: AR

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

MSH|^~\&|EHR|MAIN|ADT_SYSTEM|HOSPITAL|20261012190003||ACK^A13^ACK|ACK13003|P|2.5
MSA|AR|MSG13001

How to Correlate ACK Responses

MSA-2 identifies the A13 message being acknowledged. Sending applications use this value to associate the response with the correct cancellation notification and support reliable message tracking.

How to Handle Failed Acknowledgments

Failed acknowledgments require controlled recovery procedures. Integration teams should distinguish temporary transport failures from validation errors and prevent retries from repeatedly reopening the same encounter.

Common HL7 ADT A13 Integration Errors and Troubleshooting

HL7 A13 integration problems commonly involve missing encounter identifiers, cancellation of the wrong discharge, duplicate notifications, and inconsistent handling of discharge timestamps. These issues can affect patient administration, billing, bed management, and downstream clinical applications. Vendor-specific cancellation rules may introduce additional validation failures. Troubleshooting should begin with the original A03 discharge notification, the A13 message, acknowledgment responses, and destination encounter state. A documented HL7 parsing and data mapping process helps teams identify inconsistencies and improve discharge cancellation reliability.

Original Discharge Cannot Be Found

A receiving application may reject A13 when it cannot locate the original discharge. Validate patient and visit identifiers and investigate whether the earlier A03 notification was received.

Incorrect Encounter Is Reopened

Inadequate visit matching can cause cancellation of the wrong discharge. Validate patient identifiers, assigning authorities, and visit numbers before applying encounter reopening logic.

Duplicate A13 Notifications

Repeated cancellation notifications can create errors when the original discharge has already been reversed. Implement idempotent processing and track previously handled cancellation events.

Incorrect Discharge Timestamp Handling

Receiving applications may retain or clear discharge timestamps incorrectly. Define how PV1-45 and related discharge information should be processed during cancellation.

Out-of-Sequence ADT Messages

An A13 message may arrive before its corresponding A03 notification due to interface delays. Establish reconciliation rules for cancellations received before the original discharge.

HL7 ADT A13 vs A03, A11, A12, and A01

HL7 ADT events represent different patient administration activities. A13 cancels a previously recorded discharge, while A03 communicates discharge or visit completion. A11 cancels an admission, A12 cancels a transfer, and A01 communicates admission. Although these events may share patient and visit segments, their workflow meanings differ. Receiving applications should distinguish cancellations from valid encounter transitions to avoid incorrect patient status, duplicate records, and inconsistent downstream information.

A13 vs A03: Discharge and Cancellation

A03 communicates discharge or visit completion, while A13 cancels an earlier discharge. Receiving applications should match the cancellation to the correct encounter and apply supported reversal logic.

A13 vs A11: Discharge and Admission Cancellation

A11 cancels an admission, while A13 cancels a discharge. Integration engines should identify the original event and apply the appropriate encounter correction workflow.

A13 vs A12: Discharge and Transfer Cancellation

A12 cancels a transfer, while A13 cancels a discharge. Receiving systems should distinguish these events to maintain accurate encounter histories and patient locations.

A13 vs A01: Reopening and New Admission

A01 communicates admission, while A13 cancels an earlier discharge. A13 should not automatically create another admission or duplicate the existing encounter.

Best Practices for Reliable HL7 A13 Integration

Reliable HL7 A13 integration depends on accurate encounter matching, consistent discharge correction rules, and clear cancellation behavior. Healthcare organizations should document how receiving applications identify and reverse canceled discharges, including the handling of duplicate and out-of-sequence notifications. Interface specifications should define required identifiers, discharge timestamp handling, acknowledgment behavior, exception processing, and reconciliation procedures. Because A13 messages may contain protected health information, secure transport and controlled access are essential. Combining validation, monitoring, and auditing helps integration teams maintain consistent encounter information across connected healthcare systems.

Match Cancellations to the Original Discharge

Use patient and visit identifiers to identify the original discharge. Investigate ambiguous matches before applying cancellation logic that could reopen unrelated encounters.

Define Idempotent Cancellation Behavior

Ensure repeated A13 notifications do not repeatedly reopen the same encounter or create inconsistent records. Track processed events and apply controlled retry rules.

Handle Discharge Timestamp Corrections

Document how discharge date and time values should be cleared, retained, or corrected during cancellation. Validate these rules against destination application requirements.

Secure Patient and Encounter Information

Protect HL7 message transmission, restrict interface access, and minimize sensitive information in operational logs. Apply appropriate healthcare privacy and security controls throughout processing.

Monitor Cancellation and Reconciliation Failures

Track failed acknowledgments, unmatched encounters, duplicate cancellations, and processing delays. Establish alerts and reconciliation procedures to identify incomplete discharge reversals.

Frequently Asked Questions About HL7 ADT A13 Messages

HL7 A13 integration involves discharge cancellation, encounter matching, and downstream record correction. Healthcare developers and IT teams often need to understand how A13 differs from a new admission, which fields identify the existing encounter, and how receiving applications reverse an earlier discharge. The following questions address common implementation concerns using general HL7 v2 conventions. Actual processing requirements depend on the healthcare organization, HL7 version, vendor, and interface implementation guide.

Need Help With HL7 ADT A13 Integration?

Reliable discharge cancellation messaging helps healthcare organizations maintain accurate encounter information across EHRs, hospital administration systems, billing platforms, and connected clinical applications. Taction Software supports HL7 interface development, Mirth Connect configuration, encounter matching, and production troubleshooting. Our engineers can help organizations implement controlled discharge cancellation workflows, prevent duplicate processing, and establish dependable acknowledgment and recovery procedures. Whether an organization is developing a new interface or improving existing HL7 channels, careful validation and monitoring support consistent patient administration information across connected healthcare systems.

Custom HL7 Discharge Cancellation Interfaces

We develop HL7 A13 interfaces based on source and destination requirements. Implementation includes encounter identification, discharge correction mapping, message validation, routing, and acknowledgment handling.

Mirth Connect Channel Development

Our engineers configure Mirth Connect channels to receive, filter, transform, and deliver discharge cancellation notifications. We address destination connectivity, field mapping, and error handling during implementation.

Encounter Matching and Discharge Reversal

We help organizations improve cancellation processing through patient identifier validation, visit matching, and duplicate prevention. These controls support accurate reversal of earlier discharge notifications.

Production Monitoring and Support

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

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