HL7 ADT A11 Message: Cancel Admit / Visit Notification, Structure, Segments & Examples

The HL7 ADT A11 message is an Admit, Discharge, Transfer event used to cancel a previously recorded patient admission or visit notification. Officially called ADT A11: Cancel Admit / Visit Notification, it allows healthcare systems to reverse an admission or visit registration event entered incorrectly.

Hospitals use A11 when an admission was recorded for the wrong patient, created in error, or needs to be canceled through an authorized registration workflow. Unlike an A03 discharge, A11 indicates that the original admission or visit notification should be reversed. This guide explains A11 message structure, PID and PV1 segments, examples, Mirth Connect integration, acknowledgments, troubleshooting, and implementation best practices.

What Is an HL7 ADT A11 Message?

An HL7 ADT A11 message communicates the cancellation of a previously recorded admission or visit notification. It is generally used when a patient admission or visit was registered incorrectly and must be reversed. For example, a hospital registration team may accidentally admit a patient who was not actually admitted. Instead of sending a discharge notification, the source system generates an A11 cancellation.

The receiving applications identify the original encounter and apply their supported cancellation rules. This distinction is important because canceling an admission is not the same as completing a valid patient visit. Understanding A11 within the broader HL7 ADT messaging framework helps teams choose the right cancellation event.

Purpose of the HL7 A11 Event

A11 communicates that an earlier admission or visit notification should be canceled. Receiving applications use it to reverse the corresponding administrative event and maintain consistent encounter records.

When Is an ADT A11 Message Generated?

An A11 message may be generated when an admission was entered accidentally, a patient was registered under the wrong encounter, or an authorized registration correction requires canceling the original notification.

Which Healthcare Systems Receive A11 Messages?

EHRs, admission and registration applications, patient accounting systems, bed management platforms, billing applications, and hospital integration engines may receive A11 notifications.

How A11 Supports Registration Corrections

A11 helps connected applications reverse invalid admissions without recording a discharge for an encounter that should not have existed as a valid admission.

Why Accurate A11 Processing Matters

Incorrect cancellation can remove or invalidate a legitimate patient encounter. Receiving systems must verify patient identifiers, encounter identifiers, event history, and authorization before applying the reversal.

HL7 ADT A11 Message Structure and Segments

The HL7 Version 2.5 A11 event uses the ADT_A09 message structure. The required core segments include MSH, EVN, PID, and PV1. Additional optional segments may provide patient demographics, visit details, observations, and diagnoses.

The PV1 segment is particularly important because it identifies the visit or admission being canceled. A11 processing must reference the correct patient and encounter, especially when a patient has multiple visits or admissions. The exact cancellation behavior depends on the receiving application's encounter lifecycle rules and the implementation agreement.

HL7 ADT A11 Message Structure

MSH
[{SFT}]
EVN
PID
[PD1]
PV1
[PV2]
[{DB1}]
[{OBX}]
[{DG1}]

This is a simplified representation of the HL7 v2.5 ADT_A09 structure. Optional and repeating segments must follow the selected implementation profile.

MSH Segment: Message Header

MSH identifies the sending and receiving applications, message timestamp, trigger event, control identifier, and HL7 version. MSH-9 identifies the cancellation event as ADT^A11^ADT_A09.

EVN Segment: Event Information

EVN contains administrative information about the cancellation, including its recorded timestamp. It supports audit tracking and investigation of registration corrections.

PID Segment: Patient Identification

PID identifies the patient associated with the admission or visit being canceled. The destination must match the correct patient before modifying encounter records.

PV1 Segment: Patient Visit Information

PV1 contains the patient class, visit number, location, and admission information. It helps the receiving system identify the encounter associated with the cancellation.

Optional Segments: PV2, OBX, and DG1

PV2 can provide additional visit information. OBX and DG1 may appear where supported by the applicable interface profile, but they are not the primary basis for admission cancellation.

HL7 ADT A11 Message Example With Field Explanation

Consider a hospital registration team that accidentally creates an inpatient admission for a patient. The admission is transmitted to the EHR, patient accounting system, and bed management platform. During verification, the registration team discovers that the patient was never admitted. The team cancels the erroneous admission in the source application, and the source generates an A11 message to notify connected systems. Receiving applications identify the original encounter and reverse the admission according to their supported workflows.

Complete HL7 ADT A11 Sample Message

MSH|^~\&|REGISTRATION|HOSPITAL|EHR|MAIN|20261022110000||ADT^A11^ADT_A09|MSG11001|P|2.5
EVN|A11|20261022105500
PID|1||MRN110001^^^HOSPITAL^MR||SMITH^EMILY||19920416|F
PV1|1|I|WARD5^ROOM12^BED2

All patient information is fictional. This simplified message demonstrates the A11 trigger event and core segments. A production cancellation should include the encounter identifier required by the destination, commonly PV1-19, along with other fields needed to identify the original admission reliably.

Example admission cancellation workflow:

The cancellation reverses an erroneous admission or visit notification; it is not a normal discharge.

MSH Segment Explained

MSH identifies the registration system as the sender and EHR as the destination. ADT^A11^ADT_A09 identifies the cancellation event, while MSH-10 supports tracking.

EVN Segment Explained

EVN records when the cancellation was registered. Receiving systems can use this timestamp to maintain the administrative history of the encounter.

PID-3: Patient Identifier

PID-3 contains the patient's medical record number. The receiving application uses this identifier and its assigning authority to identify the correct patient.

PV1-2: Patient Class

PV1-2 contains I, indicating the original inpatient classification. The field provides encounter context but does not independently identify the admission being canceled.

PV1-19: Visit Number

PV1-19 is commonly used to identify the encounter being canceled. It should be populated according to the interface agreement to avoid canceling the wrong visit.

Important HL7 A11 Cancellation Rules

HL7 A11 applies to two different administrative scenarios. For admitted patients, it cancels an earlier A01 admission notification. For non-admitted patients, it cancels an earlier A04 registration notification. An A05 pre-admission is canceled using A38, not A11.

The earlier example shows the correct core structure but omits the visit number. The following example includes an explicit PV1-19 encounter identifier.

HL7 ADT A11 Example With Visit Number

MSH|^~\&|REGISTRATION|HOSPITAL|EHR|MAIN|20261022110000||ADT^A11^ADT_A09|MSG11002|P|2.5
EVN|A11|20261022105500
PID|1||MRN110001^^^HOSPITAL^MR||SMITH^EMILY||19920416|F
PV1|1|I|WARD5^ROOM12^BED2||||||||||||||||VIS110001

The encounter identifier is VIS110001. The receiving system must match it against the original admission or visit before applying the cancellation.

Explore each segment and its key fields:

Important HL7 ADT A11 Fields and Mapping

A11 processing depends on identifying the original encounter accurately. Patient identifiers alone may not be sufficient because a patient can have multiple visits. The destination should match the patient, encounter, and relevant admission or registration history before reversing the event.

The interface agreement should also define what happens when clinical, billing, or bed-management activity has already occurred against the encounter. Clear HL7 v2 integration specifications help make those rules explicit.

PID-3: Patient Identifier List

PID-3 identifies the patient associated with the canceled admission or registration. The destination should validate the complete identifier and assigning authority.

PV1-19: Visit Number

PV1-19 commonly identifies the encounter being canceled. Accurate matching is essential when the patient has several admissions or outpatient visits.

PV1-44: Admit Date and Time

PV1-44 may help correlate the cancellation with the original admission event. Its use depends on the source system and receiving application requirements.

PID-18: Patient Account Number

PID-18 provides account context when available. The destination should reconcile any patient accounting activity associated with the canceled encounter.

MSH-10: Message Control Identifier

MSH-10 identifies the A11 notification itself. It supports acknowledgment correlation, duplicate detection, and investigation of interface failures.

How HL7 ADT A11 Cancellation Workflows Operate

An A11 workflow begins when an authorized registration team determines that a previously transmitted admission or visit notification was incorrect. The source application identifies the original event and generates a cancellation notification. The integration engine validates and routes the A11 message. Receiving applications match the encounter and apply the appropriate reversal.

For an A01 cancellation, the admission state is reversed. For an A04 cancellation, the visit registration is reversed. The exact database and workflow effects depend on the destination system.

Step 1: Identify the Incorrect Admission or Registration

Registration staff review the encounter and determine whether the original A01 or A04 notification should be canceled.

Step 2: Confirm the Encounter and Authorization

The source verifies the patient, encounter, and reason for cancellation. It should prevent unauthorized or accidental reversal of legitimate visits.

Step 3: Generate the A11 Notification

The registration application generates an A11 message with patient identification, visit information, and the cancellation event timestamp.

Step 4: Validate and Route the Message

Mirth Connect or another integration engine validates the message structure and identifiers before forwarding the cancellation to approved systems.

Step 5: Reverse and Reconcile the Encounter

Receiving applications apply their supported cancellation workflow, reconcile dependent records, and return an acknowledgment or processing status.

How to Implement HL7 ADT A11 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route A11 cancellation messages between registration applications, EHRs, billing systems, and bed management platforms. Because A11 reverses an earlier administrative event, processing should include patient and encounter validation.

The destination must also determine whether the original event exists and whether the encounter is eligible for cancellation. Directly deleting encounter records from databases is not recommended. Use the destination's supported cancellation interface or API. Organizations can use Mirth Connect development services to build and support these channels.

Configure the Mirth Connect Source Connector

Create an MLLP Listener with HL7 v2.x inbound data type. Configure trusted sending applications, secure transport, acknowledgments, and message retention.

Filter HL7 ADT A11 Messages

var messageType =
    msg['MSH']['MSH.9']['MSH.9.1'].toString();

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

var structure =
    msg['MSH']['MSH.9']['MSH.9.3'].toString();

var version =
    msg['MSH']['MSH.12']['MSH.12.1'].toString();

return messageType === 'ADT' &&
       event === 'A11' &&
       structure === 'ADT_A09' &&
       version === '2.5';

Extract Patient and Encounter Information

The following JavaScript transformer extracts the patient identifier, visit number, account number, and cancellation timestamp.

function component(segment, field, number) {
    var value = segment[field];

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

    return value[0][field + '.' + number]
        .toString().trim();
}

var msh = msg['MSH'];
var evn = msg['EVN'];
var pid = msg['PID'];
var pv1 = msg['PV1'];

var event =
    component(msh, 'MSH.9', 2);

if (event !== 'A11') {
    throw new Error('Unexpected HL7 event');
}

var patientId =
    component(pid, 'PID.3', 1);

var visitNumber =
    component(pv1, 'PV1.19', 1);

var accountNumber =
    component(pid, 'PID.18', 1);

var controlId =
    component(msh, 'MSH.10', 1);

if (!patientId || !visitNumber || !controlId) {
    throw new Error(
        'Missing patient, visit, or control ID'
    );
}

var cancellation = {
    eventType: 'A11',

    action: 'cancelAdmitOrVisit',

    patientId: patientId,
    visitNumber: visitNumber,
    accountNumber: accountNumber,

    patientClass:
        component(pv1, 'PV1.2', 1),

    originalAdmitTime:
        component(pv1, 'PV1.44', 1),

    cancellationRecordedAt:
        component(evn, 'EVN.2', 1),

    messageControlId: controlId,

    processingStatus:
        'pending_encounter_validation'
};

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

This code is illustrative. Production implementations must preserve complete identifier domains and validate the cancellation against the original encounter.

Transform A11 Into a Controlled Cancellation Request

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

var request = {
    operation: 'cancelEncounterNotification',

    patientId: event.patientId,
    encounterId: event.visitNumber,

    accountNumber: event.accountNumber,

    originalEventValidationRequired: true,

    status: 'pending_validation',

    cancellationRecordedAt:
        event.cancellationRecordedAt,

    sourceMessageId:
        event.messageControlId
};

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

This is an illustrative application payload, not a standardized HL7 or FHIR API.

Validate the Original Encounter

Confirm that the encounter exists and that the original A01 or A04 notification is eligible for cancellation. Route conflicting records for authorized review.

Configure Audit Logging and Monitoring

Track patient identifiers, visit numbers, original event references, cancellation timestamps, acknowledgment responses, and downstream reconciliation results.

HL7 ADT A11 ACK Message Examples and Error Handling

HL7 acknowledgments allow the sender to determine whether an A11 cancellation was accepted or rejected by the receiving application. A typical ACK contains MSH and MSA segments. ERR may provide diagnostic details when validation or application processing fails.

In original acknowledgment mode, AA indicates application acceptance, AE indicates an application error, and AR indicates rejection. An AA acknowledgment does not necessarily prove that every downstream application has completed encounter reconciliation.

Successful A11 ACK: AA

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022110001||ACK^A11^ACK|ACK11001|P|2.5
MSA|AA|MSG11002

Application Error ACK: AE

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022110002||ACK^A11^ACK|ACK11002|P|2.5
MSA|AE|MSG11002
ERR|||204^Unknown Key Identifier^HL70357|E

This error is illustrative. The destination's actual error code and response depend on its implementation profile.

Application Rejection ACK: AR

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022110003||ACK^A11^ACK|ACK11003|P|2.5
MSA|AR|MSG11002

Correlate ACK Responses With Original Messages

MSA-2 should reference the A11 message's MSH-10 identifier. The destination should also preserve the relationship between the cancellation and the original encounter.

Handle Failed Messages and Retries

Before resending an unacknowledged A11 message, verify whether the destination already processed the cancellation. Duplicate messages must not create inconsistent encounter states.

Common HL7 ADT A11 Integration Errors and Troubleshooting

A11 integration failures often occur when the receiving application cannot identify the original encounter or the encounter has already progressed through additional clinical and financial workflows. Other problems include incorrect patient identifiers, missing visit numbers, duplicate cancellations, and confusion between cancellation and discharge.

Troubleshooting should focus on the original A01 or A04 event, current encounter state, message identifiers, and the destination's supported cancellation rules. Accurate HL7 parsing and data mapping helps prevent these problems.

Original Encounter Cannot Be Found

The receiving system may not recognize the visit number or patient identifier. Verify PID-3, PV1-19, assigning authorities, and original event history.

A11 Is Mistaken for A03 Discharge

A11 cancels an earlier admission or visit notification. A03 represents discharge or end of a valid visit. Applying discharge logic to a cancellation can produce incorrect encounter history.

Encounter Has Dependent Clinical or Billing Activity

An encounter may already contain orders, results, charges, or documentation. The receiving system must follow its approved cancellation and reconciliation workflow rather than deleting dependent records indiscriminately.

Duplicate A11 Messages Are Received

Repeated cancellation notifications can generate errors if the destination assumes the original encounter remains active. Implement idempotent processing and defined behavior for already-canceled encounters.

A11 Arrives Before the Original Admission

Out-of-order delivery may cause a cancellation to arrive before its corresponding A01 or A04. Use event history and controlled reconciliation to resolve the sequence.

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

HL7 Version 2 defines separate events for canceling admissions, transfers, discharges, and pre-admissions. The appropriate event depends on which administrative action is being reversed. A11 cancels an admission or visit registration. A12 cancels a transfer, A13 cancels a discharge, and A38 cancels a pre-admission. A03 is not a cancellation event; it communicates discharge or end of visit.

A11 vs A03: Cancellation and Discharge

A11 reverses an admission or visit notification that should not stand. A03 ends a valid encounter. These events must not be processed interchangeably.

A11 vs A12: Admission and Transfer Cancellation

A11 cancels an admission or registration. A12 cancels a previously recorded transfer. The original event being reversed determines the appropriate trigger.

A11 vs A13: Admission and Discharge Cancellation

A11 reverses admission or registration, while A13 reverses a discharge. A13 is appropriate when the patient was discharged incorrectly and the discharge must be canceled.

A11 vs A38: Admission and Pre-Admission Cancellation

A11 cancels an A01 or A04 notification. A38 cancels an A05 pre-admission notification. Choosing the wrong event may cause the destination to update the wrong encounter state.

Best Practices for Reliable HL7 A11 Integration

Reliable A11 processing requires accurate encounter identification, authorization, and reconciliation across connected systems. Healthcare organizations should define which admission and registration events can be canceled, how downstream applications should reverse them, and how dependent records should be handled.

Integration teams should test cases involving duplicate notifications, delayed events, active orders, existing charges, and already-canceled encounters. A11 should be treated as a controlled administrative correction rather than a general-purpose record deletion instruction.

Validate the Original Admission or Registration

Confirm that the A11 corresponds to a previously recorded A01 or A04 event. Verify patient and encounter identifiers before applying the cancellation.

Preserve Clinical and Financial Audit History

Do not indiscriminately delete clinical documentation, orders, or financial transactions. Preserve audit records and apply the receiving system's supported reconciliation workflow.

Require Authorized Cancellation Workflows

Only approved registration or administrative processes should initiate admission cancellations. Record the reason, timestamp, and responsible workflow where available.

Implement Idempotency and Event Sequencing

Prevent duplicate cancellations and handle out-of-order notifications. Maintain sufficient event history to determine the correct encounter state.

Monitor Downstream Reconciliation

Verify that EHR, billing, bed management, and other receiving systems reflect the intended cancellation without leaving inconsistent administrative records.

Frequently Asked Questions About HL7 ADT A11 Messages

Need Help With HL7 ADT A11 Integration?

Admission cancellation interfaces require reliable coordination between registration applications, EHRs, patient accounting systems, and bed management platforms. Taction Software supports HL7 interface development, Mirth Connect implementation, encounter lifecycle mapping, and healthcare interoperability.

HL7 Admission Cancellation Interfaces

We develop A11 interfaces based on source and destination requirements, including encounter identification, cancellation validation, and administrative workflow reconciliation.

Mirth Connect Development and Integration

Our engineers configure Mirth Connect channels for admission cancellation notifications, including JavaScript transformations, secure routing, acknowledgment handling, and exception monitoring.

EHR and Registration System Integration

We support integration between EHRs, registration platforms, patient accounting applications, and hospital systems using approved encounter management workflows.

Production Monitoring and Troubleshooting

We help investigate failed cancellations, missing encounter identifiers, duplicate messages, acknowledgment errors, and inconsistent downstream encounter states.

Need help with HL7 admission cancellations? Explore our HL7 interface messaging services to discuss your requirements.