HL7 ADT A21 Message: Patient Goes on a Leave of Absence, Structure, Segments & Examples

The HL7 ADT A21 message is an Admit, Discharge, Transfer event used to notify healthcare systems that a patient has started a leave of absence during an existing encounter. Officially called ADT A21: Patient Goes on a Leave of Absence, it allows hospitals to record a temporary absence without treating the event as a normal discharge.

A21 is especially relevant to inpatient facilities, behavioral health organizations, rehabilitation centers, and long-term care environments where authorized temporary absences may occur. This guide explains the A21 message structure, important PID and PV1 fields, sample messages, Mirth Connect integration, acknowledgments, troubleshooting, and implementation best practices.

What Is an HL7 ADT A21 Message?

An HL7 ADT A21 message communicates that a patient has gone on an authorized leave of absence. The event records a temporary absence from a healthcare facility while the patient's existing encounter may remain open. For example, a patient receiving inpatient rehabilitation may be approved to leave the facility temporarily and return later.

Rather than generating a discharge event, the hospital records the leave using A21. When the patient returns, the corresponding event is ADT A22: Patient Returns From a Leave of Absence. The receiving system must distinguish this workflow from a discharge, transfer, or ordinary patient tracking movement. See the HL7 ADT messages guide for the full event family.

Purpose of the HL7 A21 Event

A21 informs connected systems that a patient has started a leave of absence. It supports encounter continuity, administrative tracking, and coordination between clinical and operational applications.

When Is an ADT A21 Message Generated?

An A21 notification may be generated when a patient begins an approved temporary absence during an active inpatient or other eligible encounter, according to facility policies.

Which Healthcare Systems Receive A21 Messages?

EHRs, admission and registration systems, bed management platforms, patient accounting applications, behavioral health systems, and hospital integration engines may receive A21 notifications.

How A21 Supports Encounter Continuity

A21 allows systems to record the patient's temporary absence while preserving the underlying encounter. This helps avoid treating an authorized leave as a completed discharge.

Why Accurate A21 Processing Matters

Incorrect leave processing can prematurely close an encounter, misrepresent patient location, or create inconsistent bed and billing information. Receiving applications must apply the approved leave-of-absence workflow.

HL7 ADT A21 Message Structure and Segments

HL7 Version 2 uses a structured message format to communicate administrative events between healthcare applications. An A21 message identifies the sending system, receiving system, patient, encounter, and leave-of-absence event. The PV1 segment is particularly important because it contains patient class, location, visit identifiers, and leave-related information.

For HL7 v2.5, A21 uses the ADT_A21 message structure. Optional segments may provide additional patient demographics, visit details, and other information supported by the implementation profile.

HL7 ADT A21 Message Structure

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

This is a simplified structural overview. The exact required, optional, and repeating segments should be validated against the selected HL7 version and receiving application's interface specification.

MSH Segment: Message Header

MSH identifies the source, destination, timestamp, trigger event, control identifier, and HL7 version. MSH-9 identifies the leave event as ADT^A21^ADT_A21.

EVN Segment: Event Information

EVN records administrative information about the leave event, including its recorded timestamp. It supports event history and operational auditing.

PID Segment: Patient Identification

PID identifies the patient beginning the leave of absence. Receiving systems should match the patient using the complete identifier and assigning authority.

PV1 Segment: Patient Visit and Leave Information

PV1 contains the patient's encounter classification, assigned location, visit number, and other visit information relevant to the leave workflow.

Optional Segments: PV2, DB1, and OBX

Optional segments may provide additional visit context, such as the expected return in PV2, disability information in DB1, or observations in OBX, where supported by the interface profile.

HL7 ADT A21 Message Example With Field Explanation

Consider a patient admitted to an inpatient rehabilitation facility. The care team authorizes a temporary leave beginning at 2:00 PM. The patient is expected to return later, and the existing encounter remains active according to the facility's policies. The registration system records the leave and generates an A21 notification. Connected applications update the patient's leave status without processing a normal discharge. When the patient returns, the source application may generate an A22 notification to complete the leave workflow.

Illustrative HL7 ADT A21 Message

MSH|^~\&|REGISTRATION|REHAB_CENTER|EHR|MAIN|20261022140000||ADT^A21^ADT_A21|MSG21001|P|2.5
EVN|A21|20261022140000
PID|1||MRN210001^^^REHAB_CENTER^MR||THOMAS^JAMES||19860618|M
PV1|1|I|REHAB^ROOM12^BED2

All patient information is fictional. This simplified example illustrates the A21 trigger event and core patient information. Production messages should include the encounter identifier, leave-related dates and times, and other required values according to the destination's implementation profile.

MSH Segment Explained

MSH identifies the registration application as the sender and the EHR as the destination. ADT^A21^ADT_A21 identifies the leave-of-absence event.

EVN Segment Explained

EVN records when the leave event was entered. The timestamp supports audit tracking and reconciliation with subsequent leave and return events.

PID-3: Patient Identifier

PID-3 identifies the patient beginning the leave. The receiving application uses the medical record number and assigning authority to locate the correct patient.

PV1-2: Patient Class

PV1-2 contains I, indicating inpatient classification. A21 does not automatically convert an inpatient encounter to an outpatient encounter.

PV1-19: Visit Number

PV1-19 identifies the encounter associated with the leave of absence. It should be populated according to the interface agreement to support reliable encounter matching.

Important HL7 A21 Fields and Mapping

An A21 message should identify the patient, the active encounter, the actual leave start time, and the expected return time when known. Two fields deserve particular attention:

• EVN-6: Event Occurred records when the patient actually left the institution.
• PV2-47: Expected LOA Return Date/Time records when the patient is expected to return.

HL7 guidance recommends EVN-6 for the actual leave start because there is no dedicated leave-start field. Our HL7 parsing and data mapping team can document how each field maps to your receiving applications.

EVN-6: Actual Leave Start Date and Time

EVN-6 should contain the actual time the patient left the facility. This is particularly important when the leave was entered into the registration system later.

PV2-47: Expected Return Date and Time

PV2-47 communicates the anticipated return from leave. Receiving applications can use this information for operational planning and exception monitoring.

PID-3: Patient Identifier List

PID-3 identifies the patient beginning the leave. Receiving systems should validate the complete patient identifier, including its assigning authority.

PV1-19: Visit Number

PV1-19 identifies the active encounter associated with the leave. The destination should verify that the encounter exists and is eligible for leave processing.

PV1-3: Assigned Patient Location

PV1-3 provides the patient's assigned location. In the standard A21 scenario, the bed remains assigned while the patient is temporarily away.

HL7 ADT A21 Example With Leave Start Time

The following example explicitly identifies the actual leave start using EVN-6.

MSH|^~\&|REGISTRATION|REHAB_CENTER|EHR|MAIN|20261022140500||ADT^A21^ADT_A21|MSG21002|P|2.5
EVN|A21|20261022140500||||20261022140000
PID|1||MRN210001^^^REHAB_CENTER^MR||THOMAS^JAMES||19860618|M
PV1|1|I|REHAB^ROOM12^BED2

Here, the event was recorded at 14:05, while the patient actually left at 14:00. The message is intentionally minimal; production interfaces should include an encounter identifier and any required PV2 information.

Explore each segment and its key fields:

How HL7 ADT A21 Leave of Absence Workflows Operate

An A21 workflow begins when an admitted patient is authorized to leave the healthcare institution temporarily. The registration or patient administration application records the departure and generates an A21 message. The integration engine validates and routes the notification to connected systems.

Receiving applications update the patient's leave status, preserve the encounter, and apply the facility's bed and service-management rules. When the patient returns, an A22 message communicates the end of the leave.

Step 1: Authorize the Leave of Absence

The facility confirms that the patient is eligible for a temporary leave. The approved workflow records relevant authorization and expected return information.

Step 2: Record the Actual Departure

The source system captures when the patient physically leaves the institution. This timestamp should be represented in EVN-6.

Step 3: Generate and Route the A21 Message

The registration application creates the A21 notification. Mirth Connect or another integration engine validates patient, encounter, and event information before routing.

Step 4: Update Connected Systems

Receiving applications update leave status and suspend or adjust relevant activities according to approved workflows. The encounter and assigned bed remain associated with the patient where applicable.

Step 5: Process the Patient's Return

When the patient returns, an A22 message communicates the return event. The destination reconciles the leave interval and resumes appropriate workflows.

How to Implement HL7 ADT A21 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route A21 notifications between patient administration applications, EHRs, dietary systems, laboratory applications, and operational platforms. An A21 interface should validate patient and encounter identifiers, the actual departure timestamp, and expected return information when supplied.

The destination must also distinguish leave of absence from discharge or temporary in-hospital transport. A21 processing should use supported application interfaces rather than directly modifying encounter records in a database.

Configure the Mirth Connect Source Connector

Create a channel using an MLLP Listener with HL7 v2.x inbound data type. Configure trusted sending systems, transport security, acknowledgment handling, and message retention.

Filter HL7 ADT A21 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 === 'A21' &&
       structure === 'ADT_A21' &&
       version === '2.5';

Extract Patient, Encounter, and Leave Information

The following transformer extracts the important identifiers and timestamps from an A21 notification.

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

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

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

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

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

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

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

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

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

if (!patientId || !encounterId ||
    !leaveStart || !controlId) {
    throw new Error(
        'Missing required leave identifiers or timestamp'
    );
}

var expectedReturn = '';

if (msg['PV2'].length() > 0) {
    expectedReturn = getComponent(
        msg['PV2'], 'PV2.47', 1
    );
}

var leaveEvent = {
    eventType: 'A21',
    action: 'startLeaveOfAbsence',

    patientId: patientId,
    encounterId: encounterId,

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

    leaveStartTime: leaveStart,
    expectedReturnTime: expectedReturn,

    messageControlId: controlId,

    leaveStatus: 'on_leave'
};

channelMap.put(
    'leaveOfAbsenceEvent',
    JSON.stringify(leaveEvent)
);

This is illustrative Mirth Connect code. Production implementations must preserve full identifier domains and validate the exact HL7 version and receiving application's requirements.

Transform A21 Into a Leave Management Request

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

var request = {
    operation: 'startLeaveOfAbsence',

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

    status: 'on_leave',

    leaveStartTime:
        event.leaveStartTime,

    expectedReturnTime:
        event.expectedReturnTime,

    preserveEncounter: 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 Active Encounter

Confirm that the patient is admitted and the encounter is eligible for leave processing. Reject or quarantine messages with unresolved patient or visit identifiers.

Configure Monitoring and Exception Handling

Monitor missing return notifications, duplicate leave events, invalid timestamps, acknowledgment failures, and inconsistent leave status across receiving systems.

HL7 ADT A21 ACK Message Examples and Error Handling

HL7 acknowledgments allow the sender to determine whether the receiving application accepted or rejected an A21 leave-of-absence notification. A typical acknowledgment includes MSH and MSA segments. ERR may provide diagnostic details when validation fails.

In original acknowledgment mode, AA indicates application acceptance, AE indicates an application error, and AR indicates rejection. An AA acknowledgment does not necessarily mean every downstream application has completed its leave-status update.

Successful A21 ACK: AA

MSH|^~\&|EHR|MAIN|REGISTRATION|REHAB_CENTER|20261022140501||ACK^A21^ACK|ACK21001|P|2.5
MSA|AA|MSG21002

Application Error ACK: AE

MSH|^~\&|EHR|MAIN|REGISTRATION|REHAB_CENTER|20261022140502||ACK^A21^ACK|ACK21002|P|2.5
MSA|AE|MSG21002
ERR|||204^Unknown Key Identifier^HL70357|E

This error is illustrative. Actual error codes depend on the receiving application's interface specification.

Application Rejection ACK: AR

MSH|^~\&|EHR|MAIN|REGISTRATION|REHAB_CENTER|20261022140503||ACK^A21^ACK|ACK21003|P|2.5
MSA|AR|MSG21002

Correlate ACK Responses With Original Messages

MSA-2 should reference the original A21 message's MSH-10 identifier. Monitoring should also retain patient, encounter, and leave timestamps.

Handle Duplicate Leave Notifications

Before resending an unacknowledged A21 message, determine whether the destination already processed the leave. Repeated messages should not create multiple overlapping leave periods.

Common HL7 ADT A21 Integration Errors and Troubleshooting

A21 integration failures commonly involve missing encounter identifiers, invalid leave timestamps, duplicate events, or confusion between leave of absence and discharge. Some receiving applications incorrectly close the encounter when the patient leaves the institution. Others fail to preserve the patient's assigned bed or do not reconcile the subsequent return event.

Troubleshooting should focus on the active encounter, EVN-6 leave start time, expected return information, and any corresponding A22 notification. Our HL7 interface messaging team can help trace failures across the full message flow.

A21 Is Processed as a Discharge

A21 communicates a temporary leave, not the end of an encounter. Processing it as A03 can prematurely close the visit and disrupt connected workflows.

Patient Encounter Cannot Be Matched

The destination may not recognize PID-3 or PV1-19. Verify patient and encounter identifiers, assigning authorities, and current admission status.

Leave Start Time Is Incorrect

EVN-6 should represent when the patient actually left. Using only the message creation timestamp can produce inaccurate leave durations.

A22 Return Notification Is Missing

The patient may remain marked as on leave if the return notification is missing or delayed. Monitor incomplete leave-return sequences and reconcile them.

Duplicate or Overlapping Leave Events Occur

Repeated A21 notifications may create overlapping leave periods. Implement idempotency and validate the patient's current leave status before processing.

HL7 ADT A21 vs A22, A03, A09, and A52

HL7 Version 2 defines separate events for leave of absence, return from leave, discharge, patient movement tracking, and cancellation of leave. These events represent different administrative workflows. A21 starts a leave of absence. A22 communicates the patient's return. A03 ends a visit, A09 tracks departure, and A52 cancels a leave-of-absence event.

A21 vs A22: Leave and Return

A21 communicates that the patient has started a leave of absence. A22 communicates that the patient has returned. Together, these events define the leave interval.

A21 vs A03: Temporary Leave and Discharge

A21 preserves the encounter while the patient is temporarily away. A03 communicates discharge or end of visit. These events should not be treated interchangeably.

A21 vs A09: Leave and Movement Tracking

A21 represents an authorized leave from the healthcare institution. A09 tracks patient departure for movement workflows, such as transport between clinical departments.

A21 vs A52: Leave and Cancellation

A21 starts the leave-of-absence workflow. A52 cancels a previously recorded leave event when that event should not stand.

Best Practices for Reliable HL7 A21 Integration

Reliable A21 processing requires accurate patient identification, encounter matching, leave timestamps, and coordination between leave and return events. Healthcare organizations should define how leave status affects clinical activities, bed assignments, billing, and operational workflows.

Integration teams should test delayed messages, missing return notifications, duplicate events, and leave cancellations. The destination must preserve the patient's encounter and apply only the changes authorized by the leave-of-absence workflow.

Use EVN-6 for the Actual Leave Start

Populate EVN-6 with the actual departure time. This supports accurate leave duration calculation and reconciliation with the return event.

Preserve the Active Encounter

Do not automatically discharge the patient when processing A21. Maintain the encounter and assigned bed according to the facility's leave policies.

Validate Patient and Encounter Identifiers

Use complete patient and visit identifiers, including assigning authorities. Confirm that the encounter is eligible for leave processing.

Correlate A21 and A22 Notifications

Track the leave start and return events using patient, encounter, timestamps, and message history. Monitor unresolved leave periods.

Implement Audit Logging and Monitoring

Record event timestamps, message control identifiers, expected return times, acknowledgment results, and processing errors. Maintain a traceable leave history.

Frequently Asked Questions About HL7 ADT A21 Messages

Need Help With HL7 ADT A21 Integration?

Leave-of-absence interfaces require reliable coordination between patient administration applications, EHRs, bed management systems, and other clinical and operational platforms. Taction Software supports HL7 interface development, Mirth Connect implementation, patient administration workflow mapping, and healthcare interoperability.

HL7 Leave-of-Absence Interface Development

We develop A21 and A22 interfaces based on source and destination requirements, including patient identification, encounter validation, leave timestamps, and return reconciliation.

Mirth Connect Development and Integration

Our engineers configure Mirth Connect channels for leave-of-absence notifications, including JavaScript transformations, secure routing, acknowledgment handling, and exception monitoring.

EHR and Patient Administration Integration

We support integration between EHRs, registration systems, bed management platforms, and clinical applications using approved leave-of-absence workflows.

Production Monitoring and Troubleshooting

We help investigate missing return notifications, invalid leave timestamps, duplicate events, acknowledgment errors, and inconsistent encounter states.

Need help with HL7 leave-of-absence integration? Explore HL7 Integration and Taction Software's EHR integration services to discuss your requirements.