HL7 ADT A15 Message: Pending Transfer, Structure, Segments & Examples

The HL7 A15 message is an Admit, Discharge, Transfer (ADT) notification used to communicate a pending patient transfer between healthcare locations. Also known as ADT A15 or Pending Transfer, this HL7 Version 2 event informs connected applications that a patient transfer is planned but has not yet occurred. Hospitals use A15 notifications to support bed planning, nursing coordination, and communication between patient administration systems and clinical applications. Unlike an A02 transfer notification, A15 does not confirm that the patient has physically moved. This guide explains HL7 ADT A15 message structure, field mapping, examples, Mirth Connect JavaScript, acknowledgments, and troubleshooting.

What Is an HL7 ADT A15 Message?

An HL7 ADT A15 message communicates an anticipated patient transfer from one healthcare location to another. It belongs to the HL7 v2 patient administration message family and allows connected systems to prepare for a planned movement without treating the transfer as completed. An A15 notification may contain patient identifiers, encounter information, current location, and proposed destination details. Receiving applications must distinguish planned transfers from actual patient movements to avoid incorrect occupancy or location updates. Understanding A15 within the broader HL7 ADT messaging workflow helps integration teams manage patient movement accurately.

Purpose of the HL7 A15 Event

The A15 event informs receiving applications that a patient transfer is planned. It supports operational preparation without confirming that the patient has moved or that the destination is occupied.

When Is an ADT A15 Message Generated?

An A15 notification may be generated when staff schedule or record a pending patient transfer. The trigger depends on hospital workflows, bed management procedures, and source application configuration.

Which Healthcare Systems Receive A15 Messages?

EHRs, bed management platforms, nursing applications, patient tracking systems, and hospital information systems may receive A15 notifications. Each destination processes pending transfers according to its supported workflow.

How A15 Supports Bed Management

A15 can help bed management teams prepare for anticipated patient movement. Receiving systems may display planned transfers or coordinate resources without marking the patient as physically transferred.

Why Accurate A15 Processing Matters

Incorrect A15 processing can create false occupancy changes, inaccurate patient locations, and duplicate transfer records. Reliable interfaces must distinguish pending transfers from confirmed movements and canceled transfer plans.

HL7 ADT A15 Message Structure and Segments

An HL7 ADT A15 message follows the segment-based format used by HL7 Version 2. Common segments include MSH, EVN, PID, and PV1, with additional segments depending on the version and interface profile. MSH identifies the sender, receiver, message type, and version. EVN records event information, PID identifies the patient, and PV1 contains visit and location details. In HL7 v2.5, A15 uses the ADT_A15 message structure. The proposed destination is commonly communicated through PV1-42, while PV1-3 represents the assigned patient location. Developers should confirm exact requirements with the interface specification.

MSH Segment: Message Header

MSH identifies the sending application, receiving application, message timestamp, control identifier, and HL7 version. MSH-9 identifies the A15 pending transfer event and associated message structure.

EVN Segment: Event Information

EVN contains information about the pending transfer event, including its recorded timestamp. Receiving applications may use this information for auditing and investigating delayed transfer notifications.

PID Segment: Patient Identification

PID contains patient identifiers and demographic information. Receiving applications use these values to locate the correct patient before associating a pending transfer with an encounter.

PV1 Segment: Patient Visit Information

PV1 contains visit and location information. PV1-3 commonly identifies the assigned location, PV1-19 identifies the visit, and PV1-42 may identify the pending location.

Optional Segments in A15 Messages

Additional segments may provide supplementary patient, encounter, or administrative information. Their inclusion depends on the HL7 version, sending application, and destination implementation requirements.

HL7 ADT A15 Message Example With Field Explanation

The following HL7 ADT A15 example illustrates a fictional inpatient with a planned transfer from one ward to another. The message follows HL7 v2.5 conventions and includes event metadata, patient identification, and encounter information. MSH-9 identifies the event as ADT^A15^ADT_A15. PID-3 identifies the patient, PV1-3 contains the currently assigned location, and PV1-42 identifies the proposed destination. PV1-19 provides the visit number. This example represents a pending movement, not a completed transfer, and should be adapted to the applicable interface guide.

Complete HL7 ADT A15 Sample Message

MSH|^~\&|ADT_SYSTEM|HOSPITAL|BED_MGMT|MAIN|20261013110000||ADT^A15^ADT_A15|MSG15001|P|2.5
EVN|A15|20261013105500
PID|1||P789012^^^HOSPITAL^MR||ANDERSON^ROBERT||19790816|M
PV1|1|I|WARD2^210^A||||3456^CLARK^JULIA||||||||||||V15001

For this sample, the proposed destination is WARD3^310^B. It should be supplied in PV1-42 using the sending system's agreed HL7 field mapping. The message above intentionally leaves that field unpopulated, so it is a minimal pending-transfer example, not a complete location-specific transfer request.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies ADT_SYSTEM as the sender and BED_MGMT as the receiver. ADT^A15^ADT_A15 identifies the pending transfer event and message structure, while MSG15001 supports tracking.

EVN Segment Explained

EVN identifies A15 as the event and records its timestamp. Integration teams may use this information to investigate delayed notifications and discrepancies between planned and actual transfer times.

PID-3: Patient Identifier Explained

PID-3 identifies fictional patient Robert Anderson using identifier P789012. Receiving applications should validate the identifier and assigning authority before associating transfer information with an existing encounter.

PV1-3: Assigned Patient Location Explained

PV1-3 contains the assigned patient location. During a pending transfer, this generally represents the current location, subject to the sending application's interface specification.

PV1-42: Pending Location Explained

PV1-42 is the Pending Location field. It can communicate the anticipated destination of a planned transfer, allowing receiving systems to distinguish a proposed location from the currently assigned location.

Important HL7 ADT A15 Fields and Mapping

Reliable HL7 A15 integration depends on accurate patient identification, encounter matching, and separation of current and pending locations. Important fields include MSH-9 for event identification, PID-3 for patient matching, PV1-3 for assigned location, PV1-19 for visit identification, and PV1-42 for pending location. Receiving systems should not treat the proposed destination as an actual patient movement. Developers should document how location components, bed assignments, and pending transfer statuses are interpreted before implementing HL7 v2 integration.

MSH-9: Identifying the Pending Transfer Event

MSH-9 identifies the A15 trigger event. Integration engines use this value to apply pending transfer logic rather than confirmed transfer, discharge, admission, or cancellation processing.

PID-3: Matching the Correct Patient

PID-3 contains patient identifiers and assigning authorities. Receiving applications should use the complete identifier context to associate pending transfer information with the correct patient record.

PV1-3: Current Assigned Location

PV1-3 identifies the assigned patient location. During pending transfer processing, receiving systems should preserve the current location until an actual transfer is confirmed.

PV1-42: Proposed Transfer Destination

PV1-42 identifies the pending location when populated. Integration teams should map its facility, point of care, room, and bed components according to destination requirements.

PV1-19: Encounter Identification

PV1-19 contains the visit identifier associated with the pending transfer. Accurate encounter matching helps receiving systems avoid applying transfer plans to unrelated visits.

How HL7 ADT A15 Messages Work in Healthcare Integration

An HL7 ADT A15 workflow begins when a healthcare organization records a planned patient transfer. The source patient administration or bed management system generates an A15 notification containing patient identifiers, encounter information, and the anticipated destination. An integration engine receives the message, validates its structure, and routes it to connected applications. Receiving systems record the pending movement without automatically updating the patient's confirmed location. When the actual transfer occurs, an A02 notification may communicate the completed movement. Reliable processing requires event sequencing, duplicate prevention, acknowledgment handling, and reconciliation.

Step 1: Planned Transfer Is Recorded

A hospital application records an anticipated movement to another ward, room, or bed. The source generates an A15 message containing patient, encounter, and planned location information.

Step 2: Message Validation

The integration engine validates the A15 event, patient identifiers, visit number, and location fields. Invalid notifications should enter an exception workflow rather than change patient occupancy.

Step 3: Identify the Patient and Encounter

Receiving applications match the patient and existing encounter using the supplied identifiers. Ambiguous matches should be investigated before associating a planned movement with a record.

Step 4: Record the Pending Destination

The destination stores or displays the proposed transfer according to its supported workflow. The patient's confirmed location should remain unchanged until an appropriate actual movement event occurs.

Step 5: Confirm or Cancel the Transfer

A subsequent A02 may confirm the movement, while A26 may cancel the pending transfer. Receiving applications should correlate these events with the existing transfer plan.

How to Implement HL7 ADT A15 Messages Using Mirth Connect

Mirth Connect can process HL7 ADT A15 messages through configurable source connectors, filters, transformers, and destination connectors. A typical integration receives pending transfer notifications over MLLP, validates the event type, extracts patient and encounter identifiers, and maps current and proposed locations. The destination records the transfer as pending rather than immediately changing the patient's physical location. Production implementations should also handle duplicate messages, missing destinations, canceled transfer plans, and acknowledgments. Organizations can use Mirth Connect development services to implement and maintain these workflows.

Configure an HL7 Source Connector

Create a Mirth Connect channel using an MLLP listener or another supported transport. Configure the HL7 version, message data type, network endpoint, access controls, and acknowledgment behavior.

Filter ADT A15 Messages

Use a source filter to identify ADT A15 notifications. This prevents confirmed transfers, admissions, discharges, and cancellation events from entering the pending transfer 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 === 'A15';

Extract Patient and Location Information

Use a JavaScript transformer to extract patient identifiers, encounter numbers, current locations, and pending destinations. Validate the required values before forwarding the planned transfer to downstream systems.

Mirth Connect JavaScript transformer:

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

var assigningAuthority =
    msg['PID']['PID.3']['PID.3.4'].toString();

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

var currentUnit =
    msg['PV1']['PV1.3']['PV1.3.1'].toString();

var currentRoom =
    msg['PV1']['PV1.3']['PV1.3.2'].toString();

var pendingUnit =
    msg['PV1']['PV1.42']['PV1.42.1'].toString();

var pendingRoom =
    msg['PV1']['PV1.42']['PV1.42.2'].toString();

var pendingBed =
    msg['PV1']['PV1.42']['PV1.42.3'].toString();

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

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

if (!pendingUnit) {
    throw new Error(
        'Missing pending transfer destination'
    );
}

channelMap.put('patientId', patientId);
channelMap.put('assigningAuthority', assigningAuthority);
channelMap.put('visitNumber', visitNumber);
channelMap.put('currentUnit', currentUnit);
channelMap.put('currentRoom', currentRoom);
channelMap.put('pendingUnit', pendingUnit);
channelMap.put('pendingRoom', pendingRoom);
channelMap.put('pendingBed', pendingBed);
channelMap.put('messageControlId', messageControlId);

This example assumes Mirth Connect has parsed the message into its HL7 v2 XML representation. Repeating patient identifiers, location facility components, and application-specific matching rules require additional handling in production.

Transform A15 Data for Destination Systems

Create a destination-specific payload that preserves the current patient location and proposed destination separately. Explicitly identify the event as pending to prevent premature occupancy updates.

Example JSON transformation:

var pendingTransfer = {
    eventType: 'A15',
    status: 'pending',
    patientId: channelMap.get('patientId'),
    visitNumber: channelMap.get('visitNumber'),
    currentLocation: {
        unit: channelMap.get('currentUnit'),
        room: channelMap.get('currentRoom')
    },
    proposedLocation: {
        unit: channelMap.get('pendingUnit'),
        room: channelMap.get('pendingRoom'),
        bed: channelMap.get('pendingBed')
    },
    messageControlId:
        channelMap.get('messageControlId')
};

var jsonPayload = JSON.stringify(pendingTransfer);

channelMap.put('jsonPayload', jsonPayload);

This JSON structure is illustrative. Receiving applications must define their own pending transfer data model and rules for planned bed reservations.

Test and Monitor A15 Processing

Test valid pending transfers, missing destination locations, duplicate notifications, canceled plans, and delayed A02 messages. Verify that receiving systems preserve confirmed patient locations until actual movement occurs.

HL7 ADT A15 ACK Message Examples and Error Handling

HL7 acknowledgment messages allow sending systems to determine whether A15 notifications were accepted or rejected under the configured acknowledgment mode. An ACK 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 help integration teams track pending transfer notifications and investigate failures. However, an accepted A15 notification does not confirm that the patient has moved. The actual transfer must be established through the appropriate patient administration workflow.

Successful ACK Response: AA

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

MSH|^~\&|BED_MGMT|MAIN|ADT_SYSTEM|HOSPITAL|20261013110001||ACK^A15^ACK|ACK15001|P|2.5
MSA|AA|MSG15001

Application Error Response: AE

An AE acknowledgment indicates an application processing error. Missing patient identifiers, unknown encounters, invalid locations, or unsupported transfer planning workflows may require investigation.

MSH|^~\&|BED_MGMT|MAIN|ADT_SYSTEM|HOSPITAL|20261013110002||ACK^A15^ACK|ACK15002|P|2.5
MSA|AE|MSG15001
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 rejection before correcting or retransmitting the pending transfer notification.

MSH|^~\&|BED_MGMT|MAIN|ADT_SYSTEM|HOSPITAL|20261013110003||ACK^A15^ACK|ACK15003|P|2.5
MSA|AR|MSG15001

Correlate ACK Responses With Original Messages

MSA-2 identifies the message being acknowledged. Integration engines use this field to match responses with the original A15 notification and track processing outcomes.

Handle Failed Acknowledgments Safely

Separate temporary transport failures from permanent application errors. Implement controlled retries and duplicate detection so retransmitted pending transfer notifications do not create multiple transfer plans.

Common HL7 ADT A15 Integration Errors and Troubleshooting

HL7 A15 integration problems commonly involve incorrect location mapping, duplicate transfer plans, missing visit identifiers, and premature updates to actual patient locations. These errors can affect bed management, nursing coordination, and patient tracking. A15 notifications may also arrive after an A02 confirmation because of interface delays, causing an already completed movement to appear pending again. Troubleshooting should examine the original HL7 payload, destination processing rules, message timestamps, and acknowledgment responses. Consistent HL7 parsing and data mapping helps prevent these issues.

Pending Transfer Treated as Completed

A receiving system may process A15 like A02 and immediately update patient occupancy. Apply event-specific processing so planned transfers do not automatically change confirmed patient locations.

Missing or Invalid Pending Location

PV1-42 may be missing or contain an unsupported location. Validate destination codes, room assignments, and required location components against the receiving application's configuration.

Duplicate Transfer Plans

Repeated A15 notifications may create multiple pending transfers for the same encounter. Implement idempotent processing and correlate new notifications with existing transfer plans.

A15 Arrives After A02

An A15 message may arrive after the actual transfer notification because of network delays. Receiving systems should avoid reverting a completed transfer to pending status.

Pending Transfer Is Never Completed

Some pending transfers are canceled or remain unresolved. Establish reconciliation procedures to identify outdated transfer plans and determine whether a cancellation or confirmation event was missed.

HL7 ADT A15 vs A02, A12, A14, and A26

HL7 ADT events distinguish planned patient movements from completed transfers and cancellation workflows. A15 communicates a pending transfer, while A02 represents an actual transfer. A12 cancels a previously completed transfer notification, whereas A26 cancels a pending transfer. A14 communicates a pending admission rather than movement within an existing encounter. Although these events may contain similar patient and visit fields, they have different operational meanings. Receiving systems should apply event-specific rules to maintain accurate location histories and bed management information.

A15 vs A02: Pending and Actual Transfer

A15 communicates an anticipated patient movement, while A02 records an actual transfer. Receiving applications should preserve the current location until the transfer is confirmed through the appropriate workflow.

A15 vs A12: Pending Transfer and Cancellation

A12 cancels a previously recorded actual transfer, while A15 communicates a future planned movement. These events should not share identical location update logic.

A15 vs A14: Transfer and Admission Planning

A14 communicates an anticipated admission, while A15 communicates an anticipated transfer. Their workflows differ because A15 concerns movement associated with an existing patient encounter.

A15 vs A26: Pending Transfer and Its Cancellation

A26 cancels a pending transfer previously communicated through A15. Receiving systems should match the cancellation to the appropriate transfer plan without changing unrelated actual location records.

Best Practices for Reliable HL7 A15 Integration

Reliable HL7 A15 integration requires accurate encounter matching, clear separation of planned and actual locations, and controlled transfer lifecycle management. Healthcare organizations should document how receiving applications handle pending destinations, bed reservations, duplicate notifications, and canceled plans. Interface specifications should define required identifiers, location mapping rules, acknowledgment behavior, and event sequencing. Because A15 messages may contain protected health information, secure transmission and access controls are necessary. Combining validation, monitoring, and reconciliation helps healthcare systems maintain dependable patient movement information.

Preserve Current and Pending Locations Separately

Store the patient's confirmed location separately from the proposed destination. Avoid updating actual occupancy until an appropriate transfer event confirms the movement.

Validate Patient and Encounter Identifiers

Use patient identifiers, assigning authorities, and visit numbers to associate planned movements with the correct encounter. Investigate ambiguous matches before updating transfer information.

Support Transfer Confirmation and Cancellation

Define how A15 plans transition after A02 confirmation or A26 cancellation. Maintain consistent transfer states and avoid leaving outdated pending movements active.

Secure Patient Location Information

Protect HL7 transmissions, restrict interface access, and minimize sensitive patient information in operational logs. Apply appropriate security and privacy controls to integration workflows.

Monitor Pending Transfer Exceptions

Track rejected messages, unresolved transfer plans, missing destinations, and out-of-sequence events. Establish reconciliation procedures to identify discrepancies between planned and actual movements.

Frequently Asked Questions About HL7 ADT A15 Messages

HL7 A15 integration involves pending patient transfers, location mapping, and event lifecycle management. Healthcare developers and IT teams often need to distinguish planned movements from actual transfers, understand how pending destinations are represented, and determine how cancellation events should be handled. The following questions address common implementation concerns using HL7 v2.5 conventions. Actual processing behavior depends on the sending application, receiving system, and agreed interface implementation guide.

Need Help With HL7 ADT A15 Integration?

Reliable pending transfer messaging helps healthcare organizations coordinate patient movement without compromising the accuracy of actual location records. Taction Software supports HL7 interface development, Mirth Connect configuration, patient and encounter matching, and transfer workflow integration. Our engineers can help organizations implement event-specific processing, map location fields, prevent duplicate transfer plans, and establish dependable monitoring procedures. Whether you are connecting a hospital information system to a bed management platform or improving existing ADT channels, accurate integration supports more consistent patient movement information.

Custom HL7 Pending Transfer Interfaces

We develop HL7 A15 interfaces based on source and destination requirements. Implementation includes patient matching, location mapping, message validation, routing, and acknowledgment handling.

Mirth Connect Channel Development

Our engineers configure Mirth Connect channels for pending transfer notifications, including event filters, JavaScript transformations, destination connectivity, and exception handling.

Bed Management and Location Mapping

We help organizations distinguish assigned locations from proposed destinations. These controls support accurate bed planning and reduce incorrect occupancy updates.

Production Monitoring and Support

We support HL7 interfaces through monitoring, failure alerts, mapping changes, and recovery procedures. These services help maintain dependable transfer notifications as healthcare workflows evolve.

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