HL7 ADT A22 Message: Patient Returns From Leave of Absence, Structure, Segments & Examples

The HL7 A22 message is an Admit, Discharge, Transfer (ADT) notification used when a patient returns to a healthcare facility after a leave of absence. Also known as ADT A22 or Patient Returns From Leave of Absence, this HL7 Version 2 event allows hospital systems to communicate the patient's return without creating an entirely new admission. A22 typically follows an earlier A21 leave event and helps EHRs, hospital information systems, and connected applications maintain consistent encounter and location information. This guide explains the HL7 A22 message structure, sample messages, field mapping, Mirth Connect implementation, acknowledgments, troubleshooting, and best practices.

What Is an HL7 ADT A22 Message?

An HL7 ADT A22 message communicates that a patient has returned from a previously recorded leave of absence. It belongs to the HL7 Version 2 patient administration message family and supports the continuation of an existing encounter following a temporary absence. Unlike an A01 admission, A22 normally does not represent the creation of a new inpatient encounter. Instead, it records the patient's return and enables connected systems to update administrative and location information. Understanding A22 within the broader HL7 ADT messaging framework helps integration teams distinguish return-from-leave workflows from admissions and transfers.

Purpose of the HL7 A22 Event

A22 communicates the patient's return from an approved leave of absence. Receiving applications use this event to update leave status and maintain continuity of the existing encounter.

When Is an ADT A22 Message Generated?

An A22 notification may be generated when authorized hospital staff record that a patient has returned to the facility following a previously documented temporary absence.

Which Healthcare Systems Receive A22 Messages?

EHRs, hospital information systems, nursing applications, and patient administration platforms may receive A22 notifications. Each destination processes the return according to its supported encounter and location workflows.

How A22 Supports Encounter Continuity

A22 helps connected applications recognize that a returning patient is continuing an existing encounter. This avoids unnecessary duplicate admissions and supports accurate administrative histories.

Why Accurate A22 Processing Matters

Incorrect A22 processing can leave a patient marked absent, create duplicate encounters, or restore an outdated bed assignment. Reliable integration requires accurate visit matching and status validation.

HL7 ADT A22 Message Structure and Segments

An HL7 ADT A22 message follows the segment-based structure defined by HL7 Version 2. In HL7 v2.5, the A22 event uses the ADT_A21 message structure, which is shared with the related leave-of-absence event. A typical message includes MSH, EVN, PID, and PV1, with additional segments depending on the interface profile. MSH identifies the sender, receiver, and return event. EVN records event information, PID identifies the patient, and PV1 provides encounter context. Receiving applications must use the A22 trigger event to distinguish a return from the earlier A21 departure.

MSH Segment: Message Header

MSH identifies the sending and receiving applications, message timestamp, control identifier, and HL7 version. MSH-9 identifies A22 as the return-from-leave trigger event.

EVN Segment: Event Information

EVN contains event information, including the recorded timestamp. Receiving applications may use it to reconcile the patient's return with the preceding leave notification.

PID Segment: Patient Identification

PID identifies the returning patient through patient identifiers and demographic information. Receiving systems use these values to locate the correct patient record.

PV1 Segment: Patient Visit Information

PV1 contains encounter information, including patient class, assigned location, and visit number. These values help connect the return event to the existing encounter.

Optional Segments and Return Details

Additional segments or fields may provide administrative context, updated location information, or return timing. Their use depends on the HL7 version and implementation specification.

HL7 ADT A22 Message Example With Field Explanation

The following HL7 ADT A22 example illustrates a fictional inpatient returning from a temporary leave of absence. The message uses HL7 v2.5 conventions and contains MSH, EVN, PID, and PV1 segments. MSH-9 identifies ADT^A22^ADT_A21, where A22 is the trigger event and ADT_A21 is the message structure. PID-3 identifies the returning patient, while PV1-19 identifies the existing encounter. The example does not create a new admission. Production systems should validate the return timestamp, encounter state, and assigned location against the source application's interface specification.

Complete HL7 ADT A22 Sample Message

MSH|^~\&|ADT_SYSTEM|HOSPITAL|EHR|MAIN|20261014100000||ADT^A22^ADT_A21|MSG22001|P|2.5
EVN|A22|20261014095500
PID|1||P220001^^^HOSPITAL^MR||WILSON^JAMES||19790318|M
PV1|1|I|WARD4^405^A||||1234^SMITH^ANNA||||||||||||V22001

All patient information is fictional. The sample assumes that the patient's existing encounter remains active and that the assigned location is valid at the time of return.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies ADT_SYSTEM as the sending application and EHR as the receiver. ADT^A22^ADT_A21 identifies the return event and message structure.

EVN Segment Explained

EVN identifies A22 as the event and records the return notification timestamp. Integration teams can use this information for auditing and event sequencing.

PID-3: Returning Patient Identifier

PID-3 identifies fictional patient James Wilson through identifier P220001. Receiving applications should validate the identifier and assigning authority before updating the encounter.

PV1-3: Assigned Patient Location

PV1-3 contains the assigned location associated with the returning patient. Receiving systems should confirm that the location remains valid before updating bed management records.

PV1-19: Existing Visit Number

PV1-19 identifies the existing encounter associated with the return event. Accurate visit matching prevents the creation of duplicate admissions or updates to unrelated encounters.

Important HL7 ADT A22 Fields and Mapping

Reliable HL7 A22 integration depends on correct patient matching, encounter continuity, and location validation. Important fields include MSH-9 for identifying the return event, PID-3 for patient identification, PV1-3 for assigned location, and PV1-19 for encounter matching. EVN-2 provides event timing information. Receiving systems should also consider the patient's current leave status and the validity of the assigned bed before applying the return. Clear HL7 v2 integration specifications help prevent duplicate encounters and inconsistent patient location information.

MSH-9: Identifying the Return Event

MSH-9 identifies A22 as the trigger event. Integration engines should apply return-from-leave processing rather than admission, discharge, or ordinary transfer logic.

PID-3: Matching the Returning 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: Preserving Encounter Continuity

PV1-19 identifies the encounter associated with the return. Receiving systems should verify that the visit exists and supports a return-from-leave transition.

PV1-3: Validating the Assigned Location

PV1-3 provides assigned location information. Receiving applications should validate the location and reconcile any changes that occurred while the patient was away.

EVN-2: Recording Return Timing

EVN-2 records the event timestamp. Integration teams can use it to investigate delayed notifications and determine the correct order of leave and return events.

How HL7 ADT A22 Messages Work in Healthcare Integration

An HL7 ADT A22 workflow begins when a healthcare organization records that a patient has returned from a temporary leave of absence. The source patient administration system generates an A22 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, confirm the patient was previously on leave, and update the appropriate administrative status. Location assignments may also require reconciliation. Reliable processing depends on accurate encounter matching, event sequencing, acknowledgment handling, and duplicate prevention.

Step 1: Patient Return Is Recorded

Authorized staff record the patient's return from leave. The source patient administration system generates an A22 notification for connected applications.

Step 2: Validate the HL7 Message

The integration engine validates the A22 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's existing encounter. The return should be associated with the appropriate visit rather than creating a new admission automatically.

Step 4: Update Leave and Location Status

The destination records the patient's return and clears the applicable leave status. Assigned location information should be validated against current bed management records.

Step 5: Acknowledge and Monitor Processing

The receiving application returns an acknowledgment under the configured HL7 processing mode. Integration teams monitor duplicate returns, invalid encounters, and out-of-sequence events.

How to Implement HL7 ADT A22 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route HL7 ADT A22 messages between patient administration systems and connected healthcare applications. A typical integration uses an MLLP listener, an HL7 v2 message filter, JavaScript transformers, and destination connectors. The channel should identify the returning patient, match the existing encounter, and communicate the return without generating an unnecessary admission. Production implementations must also account for duplicate messages, missing A21 events, invalid location assignments, and delayed notifications. Mirth Connect development services can help implement these workflows.

Configure an HL7 Source Connector

Create a Mirth Connect channel with an MLLP listener or another supported transport. Configure the HL7 v2 data type, connection security, acknowledgment settings, and appropriate message storage policies.

Filter ADT A22 Messages

Configure a source filter that accepts A22 notifications. This prevents admissions, discharges, transfers, and unrelated patient administration events from entering the return-from-leave processing workflow.

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

Extract Patient and Encounter Information

Use a JavaScript transformer to extract the patient identifier, assigning authority, visit number, location, and event timestamp. Validate required values before routing the return notification.

Mirth Connect JavaScript transformer:

function getField(segment, field, component) {
    var node = msg[segment][segment + '.' + field];

    if (component) {
        node = node[segment + '.' + field + '.' + component];
    }

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

var patientId = getField('PID', 3, 1);
var assigningAuthority = getField('PID', 3, 4);
var visitNumber = getField('PV1', 19, 1);

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

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

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

if (!assigningAuthority) {
    throw new Error(
        'A22 missing patient assigning authority'
    );
}

if (!eventTimestamp || !messageControlId) {
    throw new Error(
        'A22 missing event timestamp or control ID'
    );
}

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

channelMap.put(
    'returnEvent',
    JSON.stringify(returnEvent)
);

The example assumes an HL7 v2 XML message representation in Mirth Connect. In production, support repeating patient identifiers, complete assigning-authority components, and version-specific message structures.

Transform A22 Data for Destination Systems

Create a destination-specific request that identifies the existing encounter and communicates the patient's return. Avoid hardcoding a new admission or assuming the previous bed remains available.

Example JSON transformation:

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

var returnRequest = {
    eventType: 'A22',
    action: 'returnFromLeave',
    patient: {
        identifier: event.patientId,
        assigningAuthority: event.assigningAuthority
    },
    encounter: {
        visitNumber: event.visitNumber,
        patientClass: event.patientClass
    },
    assignedLocation: event.location,
    returnTimestamp: event.eventTimestamp,
    messageControlId: event.messageControlId
};

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

This payload is illustrative, not a standardized HL7 API. The destination must verify the encounter state, applicable leave record, and location before committing the return.

Validate the Return Against the Existing Encounter

Before updating the destination, confirm the patient and visit match an existing encounter. If the patient is already discharged or the return conflicts with current records, route the message for review.

HL7 ADT A22 ACK Message Examples and Error Handling

HL7 acknowledgments allow the sender to determine whether an A22 return notification was accepted or rejected under the configured acknowledgment mode. An ACK typically contains MSH and MSA segments, with an ERR segment when appropriate. Common original-mode application acknowledgment codes include AA for acceptance, AE for application error, and AR for rejection. However, receiving an AA does not necessarily prove that every downstream application has updated its records. Integration teams should define whether acknowledgment occurs after message validation, destination processing, or completion of the return workflow.

Successful ACK Response: AA

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

MSH|^~\&|EHR|MAIN|ADT_SYSTEM|HOSPITAL|20261014100001||ACK^A22^ACK|ACK22001|P|2.5
MSA|AA|MSG22001

Application Error Response: AE

An AE response indicates an application processing error. Examples include a missing encounter, an invalid return transition, or a destination unable to resolve the patient identifier.

MSH|^~\&|EHR|MAIN|ADT_SYSTEM|HOSPITAL|20261014100002||ACK^A22^ACK|ACK22002|P|2.5
MSA|AE|MSG22001
ERR|||204^Unknown Key Identifier^HL70357|E

Application Rejection Response: AR

An AR acknowledgment indicates rejection by the receiving application. The sending system should investigate the cause before correcting or retransmitting the return notification.

MSH|^~\&|EHR|MAIN|ADT_SYSTEM|HOSPITAL|20261014100003||ACK^A22^ACK|ACK22003|P|2.5
MSA|AR|MSG22001

Correlate Acknowledgments With the Original Event

MSA-2 identifies the original message control identifier. Integration teams can use this value to connect acknowledgments, retries, and destination processing logs with the corresponding return notification.

Handle Failed Acknowledgments and Retries

Separate temporary transport failures from permanent validation errors. Apply controlled retries and idempotency checks to prevent duplicate return events or repeated encounter updates.

Common HL7 ADT A22 Integration Errors and Troubleshooting

HL7 A22 integration problems frequently involve missing encounters, incorrect leave status, duplicate return events, and invalid location assignments. Some destinations may interpret A22 as a new admission or fail to recognize it because the corresponding A21 notification was never received. Delayed messages can also arrive after a later discharge or transfer, creating conflicts with the patient's current status. Troubleshooting should examine the original HL7 message, patient and visit identifiers, acknowledgment responses, and encounter history. Reliable HL7 parsing and data mapping reduces these errors.

Existing Encounter Cannot Be Found

The destination may not recognize the visit number in PV1-19. Validate the patient identifier, assigning authority, and encounter mapping before creating or updating records.

Patient Is Not Marked on Leave

An A22 message may arrive when the destination has no active leave record. Investigate missing A21 messages, interface delays, and administrative corrections before applying the return.

Duplicate Return Notifications

Repeated A22 messages can create duplicate administrative events. Use message identifiers and encounter state to recognize previously completed returns and avoid repeated updates.

Previous Bed Is No Longer Available

The patient's former bed may have been reassigned during leave. Validate the current location assignment rather than automatically restoring the previous bed.

Return Arrives After a Discharge Event

A delayed A22 may arrive after an A03 discharge. Compare event timing and authoritative encounter status before deciding whether to process, reject, or reconcile the message.

HL7 ADT A22 vs A21, A01, A02, A03, and A13

HL7 ADT events describe different patient administration activities, including admission, temporary leave, return, transfer, and discharge. A22 specifically communicates a patient's return from leave, typically within an existing encounter. A21 begins the leave, while A01 represents an admission and A02 represents an actual transfer. A03 communicates discharge or end of visit, and A13 cancels a discharge. Although these events can contain similar patient and visit segments, their business meanings differ. Receiving systems should apply event-specific rules rather than treating them as interchangeable status updates.

A22 vs A21: Return and Departure

A21 records the beginning of a leave of absence, while A22 records the patient's return. Both events should reference the correct patient and encounter.

A22 vs A01: Return and New Admission

A01 communicates an admission, while A22 normally resumes activity within an existing encounter. Treating A22 as A01 can create duplicate admissions and inaccurate encounter histories.

A22 vs A02: Return and Transfer

A02 communicates movement between assigned locations, while A22 communicates return from leave. A returning patient may also require location reconciliation, but that does not make the events equivalent.

A22 vs A03 and A13: Return and Discharge

A03 records discharge and A13 cancels discharge. A22 communicates return from temporary leave and should not automatically reverse a completed discharge.

Best Practices for Reliable HL7 A22 Integration

Reliable HL7 A22 integration requires accurate encounter matching, clear leave status rules, and careful coordination with bed management systems. Healthcare organizations should define how the return affects patient status, assigned locations, and subsequent administrative workflows. Interfaces should validate patient identifiers, visit numbers, event timestamps, and existing leave records before processing. They should also prevent duplicate returns, handle delayed events, and maintain auditable processing records. Combining event-specific mapping, secure transmission, monitoring, and reconciliation helps connected applications maintain consistent patient information after a temporary absence.

Match the Existing Encounter Before Updating

Validate the patient identifier, assigning authority, and visit number before processing the return. Do not create a new encounter merely because the existing visit cannot be located.

Validate the Previous Leave Status

Confirm that the return is consistent with the encounter's current administrative state. Missing or conflicting leave records should trigger a controlled exception process.

Reconcile the Assigned Bed and Location

Verify whether the previous bed remains assigned and available. Apply current bed management rules rather than assuming the location has remained unchanged.

Prevent Duplicate and Out-of-Order Events

Use message control identifiers, event timestamps, and authoritative encounter status to avoid repeated returns or older notifications overwriting newer information.

Monitor Exceptions and Preserve Audit Records

Track rejected returns, unmatched encounters, invalid location assignments, and delayed events. Maintain appropriate audit records and procedures for reconciling inconsistent patient administration data.

Frequently Asked Questions About HL7 ADT A22 Messages

HL7 A22 integration involves return-from-leave processing, encounter continuity, and patient location reconciliation. Healthcare developers and IT teams often need to understand how A22 differs from admission, why it follows A21, and how to handle situations where the patient's encounter or assigned bed has changed during the absence. 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 A22 Integration?

Reliable return-from-leave messaging helps healthcare organizations maintain accurate patient and encounter information when patients return from temporary absences. Taction Software supports HL7 interface development, Mirth Connect configuration, patient and encounter matching, and hospital system integration. Our engineers can help organizations implement A22 processing, validate leave transitions, reconcile patient locations, and establish dependable acknowledgment and monitoring procedures. Whether you are connecting an EHR to a patient administration system or improving existing ADT interfaces, accurate A22 processing supports consistent encounter information across connected healthcare applications.

Custom HL7 Return-From-Leave Interfaces

We develop A22 interfaces based on source and destination requirements, including patient matching, encounter validation, leave status updates, and acknowledgment handling.

Mirth Connect Channel Development

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

Encounter and Bed Management Integration

We help organizations coordinate patient return workflows with existing encounter records, assigned locations, and hospital bed management systems.

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 return-from-leave integration? Explore our HL7 interface messaging services to discuss your requirements.