HL7 ADT A27 Message: Cancel Pending Admit, Structure, Segments & Examples

The HL7 ADT A27 message is a patient administration event used to cancel a previously recorded pending admission. Officially named ADT A27: Cancel Pending Admit, it allows hospitals to reverse an A14 notification when the expected admission was entered incorrectly or the decision to admit the patient changes. A27 helps EHRs, registration systems, bed management platforms, and other connected applications maintain accurate pending-admission records. It does not cancel a completed admission or discharge an admitted patient. This guide covers the A27 message structure, important segments and fields, practical HL7 examples, Mirth Connect implementation, acknowledgments, troubleshooting, and best practices.

What Is an HL7 ADT A27 Message?

An HL7 ADT A27 message communicates the cancellation of a pending admission that was previously announced through an A14 event. A pending admission indicates that a patient is expected to be admitted, but the actual admission has not yet occurred. When the planned admission is canceled, the source system generates an A27 notification.

Receiving applications use the event to reverse the pending-admission status and reconcile related administrative records. The event should not be confused with A11, which cancels an actual admit or visit notification, or A38, which cancels a pre-admission event. For the wider event family, see our HL7 ADT messages guide.

Purpose of the HL7 A27 Event

A27 reverses an earlier pending-admission notification. It helps receiving systems remove or cancel the pending state without incorrectly recording a completed admission, discharge, or new encounter.

When Is an ADT A27 Message Generated?

A27 may be generated when an A14 pending admission was entered incorrectly, the patient no longer requires admission, or the planned admission is canceled before completion.

Which Healthcare Systems Receive A27 Messages?

EHRs, admission-discharge-transfer platforms, registration systems, bed management applications, patient tracking systems, and integration engines may receive A27 messages to synchronize pending-admission status.

Does A27 Mean the Patient Was Discharged?

No. A27 cancels an expected admission. It does not indicate that an admitted patient was discharged or that an active inpatient encounter ended.

Why Accurate A27 Processing Matters

Incorrect cancellation can leave a patient listed as awaiting admission or remove a valid pending record. Receiving systems must identify the correct patient and pending encounter.

HL7 ADT A27 Message Structure and Segments

In HL7 Version 2.5, A27 uses the ADT_A21 message structure, not ADT_A27. This is an important technical distinction: the event code is A27, but its message structure is shared with several other patient administration events.

The required core segments are MSH, EVN, PID, and PV1. Optional segments may include SFT, PD1, PV2, repeating DB1, and repeating OBX segments. The message identifies the patient and the pending admission that must be canceled.

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

MSH Segment: Message Header

MSH identifies the sender, receiver, timestamp, message control ID, and HL7 version. MSH-9 contains ADT^A27^ADT_A21 for HL7 v2.5.

EVN Segment: Event Information

EVN records administrative information about the cancellation. EVN-2 identifies when the event was recorded, while EVN-6 may contain the effective event time.

PID Segment: Patient Identification

PID identifies the patient whose pending admission is being canceled. PID-3 should contain an identifier recognized by the receiving application.

PV1 Segment: Pending Encounter Information

PV1 identifies the visit or pending encounter. PV1-19 is commonly used for encounter matching, while other PV1 fields may provide patient class and location context.

Optional PV2, DB1, and OBX Segments

PV2 may provide additional visit details, DB1 may carry disability information, and OBX may contain observations supported by the receiving interface.

HL7 ADT A27 Message Example With Field Explanation

Consider a hospital that schedules an inpatient admission for a patient. The patient's medical record number is MRN270001, and the pending visit identifier is VIS270001. The registration system generates an A14 message to notify connected applications that the patient is expected to be admitted.

Before the admission occurs, the clinical team decides that inpatient admission is no longer necessary. The registration system cancels the pending admission and generates an A27 message. Connected applications use the cancellation to update their pending-admission records without creating a discharge or canceling a completed admission.

Complete HL7 ADT A27 Sample Message

MSH|^~\&|REGISTRATION|HOSPITAL|EHR|MAIN|20261023103000||ADT^A27^ADT_A21|MSG27001|P|2.5
EVN|A27|20261023103000
PID|1||MRN270001^^^HOSPITAL^MR||WILSON^EMILY||19880215|F
PV1|1|I|WARD1^ROOM12^BED2||||||||||||||||VIS270001

All patient information is fictional. The sample is illustrative and should be validated against the receiving system's HL7 interface profile.

Explore each segment and its key fields:

MSH-9: Message Type and Trigger Event

ADT^A27^ADT_A21 identifies the cancellation event and its correct HL7 v2.5 message structure.

EVN-2: Recorded Event Timestamp

EVN-2 records when the cancellation was entered into the source application. It supports audit history and event sequencing.

PID-3: Patient Identifier List

PID-3 contains MRN270001, identifying the patient associated with the pending admission.

PV1-2: Patient Class

PV1-2 contains I, reflecting the intended inpatient classification in this example. It does not prove that an actual admission occurred.

PV1-19: Visit Number

PV1-19 contains VIS270001, allowing the receiving system to identify the pending encounter that must be canceled.

Important HL7 A27 Fields and Mapping

The most important part of an A27 integration is matching the cancellation to the correct pending admission. The receiving system should use the patient identifier, encounter identifier, sending facility, and its previously recorded A14 event to establish the relationship.

A27 does not contain a universal reference field that automatically identifies the original A14 message. Correlation therefore depends on the interface agreement and the destination's pending-admission records. Where an IHE Patient Encounter Management profile applies, the receiver is expected to restore the patient's status to its value before the pending admission. Our HL7 parsing and data mapping team can document these correlation rules.

PID-3: Patient Identity Verification

The receiver should validate the complete patient identifier, including assigning authority and identifier type. Matching only the patient name is insufficient for safely canceling a pending admission.

PV1-19: Pending Visit Identification

PV1-19 can identify the pending encounter associated with the original A14 notification. The receiving application should confirm that the encounter exists and remains pending.

EVN-2 and EVN-6: Cancellation Timing

EVN-2 identifies when the event was recorded. EVN-6 can communicate when the cancellation took effect, which may differ when registration is delayed.

PV1-3: Location and Bed Context

PV1-3 may contain the location associated with the planned admission. Bed management systems should reconcile reservations using their own resource allocation rules.

MSH-10: Message Control and Deduplication

MSH-10 identifies the A27 notification. It supports acknowledgment tracking and duplicate detection but is not necessarily the identifier of the original A14 event.

How HL7 ADT A27 Pending Admission Cancellation Works

An A27 workflow starts when a previously announced admission is canceled before the patient is actually admitted. The registration application verifies the pending admission and records the cancellation, and an A27 message is generated and sent through the integration engine.

The receiving application validates the patient, pending encounter, and event type before changing its administrative state. Connected systems may then update admission worklists, pending bed reservations, and operational dashboards according to their established workflows. The process should preserve the historical record of the original A14 and its cancellation.

Step 1: Locate the Original A14 Event

Identify the pending admission that was previously communicated. Confirm that the encounter is still pending and has not progressed to an actual admission.

Step 2: Approve the Cancellation

An authorized registration or clinical workflow confirms that the planned admission should be canceled and records the reason in the source system.

Step 3: Generate the A27 Message

The source sends an A27 notification identifying the patient and pending encounter. MSH-9 must contain the correct event and structure values.

Step 4: Validate and Route the Message

The integration engine validates the message, identifies approved recipients, and forwards the cancellation to systems that maintain pending-admission information.

Step 5: Restore the Previous Administrative State

Receiving systems reverse the pending-admission status and reconcile affected workflows, preserving appropriate historical records rather than deleting unrelated patient information.

How to Implement HL7 ADT A27 Using Mirth Connect

Mirth Connect can receive A27 notifications, validate message structure, extract patient and encounter identifiers, and route cancellations to EHRs, bed management applications, or other healthcare systems. The most important implementation requirement is confirming that the destination has an eligible pending admission to cancel. An A27 event should not cancel an already completed admission.

The following examples illustrate validation and transformation using Mirth Connect's HL7 v2.x XML representation. They do not directly modify a patient's encounter or admission status. Mirth Connect development services can support these requirements.

Configure the Mirth Connect Source Connector

Create an MLLP Listener with HL7 v2.x as the inbound data type. Configure trusted senders, secure transport, appropriate acknowledgment handling, and access-controlled message retention.

Filter HL7 ADT A27 Messages

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

var triggerEvent =
    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' &&
       triggerEvent === 'A27' &&
       structure === 'ADT_A21' &&
       version === '2.5';

Extract Patient and Pending Encounter Information

function getComponent(segment, field, number) {
    if (segment[field].length() === 0) {
        return '';
    }

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

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

if (evn.length() === 0 ||
    pid.length() === 0 ||
    pv1.length() === 0) {
    throw new Error(
        'Missing EVN, PID, or PV1 segment'
    );
}

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

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

var patientClass =
    getComponent(pv1, 'PV1.2', 1);

var recordedTime =
    getComponent(evn, 'EVN.2', 1);

var effectiveTime =
    getComponent(evn, 'EVN.6', 1);

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

if (!patientId ||
    !visitNumber ||
    !controlId) {
    throw new Error(
        'Missing required A27 identifiers'
    );
}

var cancellation = {
    eventType: 'A27',
    operation: 'cancelPendingAdmission',

    patientId: patientId,
    visitNumber: visitNumber,
    patientClass: patientClass,

    recordedTime: recordedTime,
    effectiveTime: effectiveTime,

    messageControlId: controlId,

    status: 'pending_validation'
};

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

This example extracts the first identifier component. Production implementations should validate complete CX identifiers, assigning authorities, encounter state, and message chronology.

Transform A27 Into a Controlled Cancellation Request

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

var request = {
    operation: 'validatePendingAdmissionCancellation',

    patientIdentifier:
        event.patientId,

    encounterIdentifier:
        event.visitNumber,

    recordedAt:
        event.recordedTime,

    effectiveAt:
        event.effectiveTime,

    requirePendingStatus: true,

    sourceMessageId:
        event.messageControlId
};

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

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

Validate the Original Pending Admission

Before applying the cancellation, verify that a matching A14 pending admission exists and has not already been converted into an actual admission.

Monitor Processing and Reconciliation

Track acknowledgments, duplicate messages, rejected cancellations, and downstream pending-admission status. Preserve audit records for the original A14 and the A27 cancellation.

HL7 ADT A27 ACK Message Examples and Error Handling

An HL7 acknowledgment communicates whether the receiving application accepted or rejected the A27 notification. A typical ACK contains MSH and MSA segments. ERR may provide additional details when processing fails.

In original acknowledgment mode, AA indicates application acceptance, AE indicates an application error, and AR indicates application rejection. A successful ACK does not necessarily prove that every downstream application has removed the pending-admission status, so acknowledgment processing and operational reconciliation should be monitored separately.

Successful A27 ACK: AA

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261023103001||ACK^A27^ACK|ACK27001|P|2.5
MSA|AA|MSG27001

Application Error ACK: AE

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261023103002||ACK^A27^ACK|ACK27002|P|2.5
MSA|AE|MSG27001
ERR|||204^Unknown Key Identifier^HL70357|E

Application Rejection ACK: AR

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261023103003||ACK^A27^ACK|ACK27003|P|2.5
MSA|AR|MSG27001

Correlate ACKs With the A27 Message

MSA-2 should reference the A27 message's MSH-10 value. This allows the sending system to identify which cancellation received the acknowledgment.

Handle Missing or Conflicting Pending Admissions

Behavior depends on the interface agreement. For example, the IHE Patient Encounter Management profile specifies ignoring certain conflicting pending events without raising an error, while unsupported pending-event management may require rejection.

Common HL7 ADT A27 Integration Errors and Troubleshooting

A27 processing failures often involve missing pending-admission history, incorrect encounter identifiers, unexpected patient status, or message structure mismatches. One common mistake is using ADT_A27 as the message structure identifier instead of ADT_A21. Another is attempting to cancel an admission that has already occurred.

These errors can create inconsistent registration records and pending bed assignments. Troubleshooting should begin with the original A14 event, PID-3, PV1-19, MSH-9, and the destination's current encounter state.

Incorrect MSH-9 Message Structure

For HL7 v2.5, use ADT^A27^ADT_A21. A receiving application may reject a message that incorrectly specifies ADT_A27.

Visit Number in the Wrong PV1 Field

PV1 is position-sensitive. An extra or missing field separator can shift the visit number from PV1-19 into a neighbouring field such as PV1-20 (financial class), so the receiver cannot find the pending encounter. Validate field positions with a version-aware parser.

Original A14 Event Cannot Be Found

The destination may not have received the pending admission or may have already processed a cancellation. Reconcile event history before retrying.

Pending Admission Already Became an Actual Admission

A27 should not cancel a completed admission. If the patient was actually admitted, determine whether a different administrative event is required.

Incorrect Patient or Visit Identifier

An incorrect PID-3 or PV1-19 value can prevent the receiver from locating the pending encounter. Validate full identifiers and assigning authorities.

Pending Bed Reservation Remains Active

The registration system may cancel the admission while the bed management platform retains a reservation. Reconcile operational resources after processing.

HL7 ADT A27 vs A14, A11, A25, A26, and A38

HL7 defines separate events for pending admissions, completed admissions, transfers, discharges, and pre-admission workflows. A14 records that a patient is expected to be admitted, while A27 cancels that pending admission. A11 cancels an actual admit or visit notification. A25 and A26 cancel pending discharge and transfer events, respectively. A38 cancels a pre-admission event rather than a pending admission. Selecting the correct event helps healthcare applications reverse only the intended administrative operation.

A27 vs A14: Pending Admission and Cancellation

A14 announces an expected admission. A27 reverses that notification when the pending admission was entered incorrectly or is no longer planned.

A27 vs A11: Pending and Completed Admissions

A27 cancels an admission that has not yet occurred. A11 cancels a previously recorded admit or visit notification.

A27 vs A38: Pending Admit and Pre-Admit

A27 cancels an A14 pending admission. A38 cancels an A05 pre-admission. The correct event depends on the original registration workflow.

A27 vs A25 and A26: Different Pending Events

A25 cancels a pending discharge, A26 cancels a pending transfer, and A27 cancels a pending admission. Each event reverses a different planned action.

Best Practices for Reliable HL7 A27 Integration

Reliable A27 processing requires accurate pending-admission matching, controlled event cancellation, and consistent downstream status. Healthcare organizations should define how A14 and A27 events are correlated and which system is authoritative for pending admissions.

Integration teams should test missing A14 history, duplicate cancellations, delayed messages, and encounters that have already progressed to actual admission. Historical records should remain traceable, and production monitoring should distinguish successful message acknowledgment from successful operational reconciliation.

Verify the Original A14 Notification

Confirm that a matching pending admission exists before canceling it. Do not automatically treat an A27 message as evidence that the patient was admitted.

Validate Patient and Encounter Identifiers

Use complete patient and encounter identifiers, including assigning authorities. This reduces the risk of canceling the wrong pending admission.

Confirm the Current Encounter State

Check whether the encounter is still pending, already canceled, or converted into an actual admission before applying the A27 event.

Preserve Administrative Audit History

Retain the original pending-admission event and its cancellation. Do not erase historical evidence of the administrative workflow.

Reconcile Bed Management and Registration Systems

Verify that pending admission lists, planned bed reservations, and operational dashboards reflect the canceled admission after processing.

Frequently Asked Questions About HL7 ADT A27 Messages

Need Help With HL7 ADT A27 Integration?

Pending-admission cancellations require accurate coordination between registration systems, EHRs, patient tracking applications, and bed management platforms. Taction Software supports HL7 interface development, Mirth Connect implementation, ADT workflow integration, and healthcare interoperability.

HL7 Pending Admission Integration

We help healthcare organizations implement A14 and A27 interfaces with accurate encounter matching, event validation, and pending-admission status synchronization.

Mirth Connect Development and Integration

Our engineers develop Mirth Connect channels for admission-related events, including secure routing, transformations, acknowledgments, and exception monitoring.

EHR and Bed Management Integration

We support integration between EHRs, registration systems, patient tracking applications, and bed management platforms using approved patient administration workflows.

Production Troubleshooting and Monitoring

We help investigate missing pending-admission events, duplicate cancellations, message structure errors, and inconsistent downstream patient status.

Need help with HL7 pending admission integration? Explore our HL7 interface messaging services and EHR and EMR integration services to discuss your requirements.