HL7 ADT A14 Message: Pending Admit, Structure, Segments & Examples

The HL7 A14 message is an Admit, Discharge, Transfer (ADT) notification used to communicate a pending patient admission. Also known as ADT A14 or Pending Admit, this HL7 Version 2 event allows healthcare applications to share information about an anticipated admission before the patient is formally admitted. Hospitals may use A14 messages to support pre-admission coordination, administrative preparation, and communication between patient administration systems and connected applications. Unlike an A01 admission notification, A14 does not establish that the admission has occurred. This guide covers HL7 ADT A14 message structure, sample messages, field mapping, Mirth Connect implementation, acknowledgments, and troubleshooting.

What Is an HL7 ADT A14 Message?

An HL7 ADT A14 message communicates that a patient admission is pending. It belongs to the HL7 v2 patient administration message family and allows receiving applications to prepare for an anticipated admission without treating the encounter as an active admission. A14 notifications may contain patient identifiers, anticipated visit information, and other administrative details. The event is particularly useful when systems need advance notice before a formal admission notification arrives. Understanding A14 alongside other HL7 ADT message types helps healthcare integration teams distinguish pending encounters from confirmed admissions.

Purpose of the HL7 A14 Event

The A14 event informs receiving applications that a patient admission is anticipated but has not yet occurred. It supports advance administrative preparation without automatically changing the encounter to admitted status.

When Is an ADT A14 Message Generated?

An A14 notification may be generated when a hospital records a pending admission in its patient administration system. The exact trigger depends on the organization's admission workflow and software configuration.

Which Healthcare Systems Receive A14 Messages?

EHRs, patient administration systems, bed management platforms, and other connected applications may receive A14 notifications. Each destination processes pending admission information according to its supported workflow and interface specification.

How A14 Supports Pre-Admission Coordination

A14 helps applications prepare patient and encounter information before admission. Receiving systems may establish a pending record or update an existing pre-admission record without marking the patient as formally admitted.

Why Accurate A14 Processing Matters

Incorrect A14 processing can create premature admissions, duplicate encounters, or inaccurate patient status. Reliable interfaces must distinguish pending admissions from confirmed admissions and apply appropriate matching and update rules.

HL7 ADT A14 Message Structure and Segments

An HL7 ADT A14 message follows the segment-based format defined by HL7 Version 2. Common segments include MSH, EVN, PID, and PV1, with additional segments determined by the HL7 version and interface profile. MSH identifies the sender, receiver, message type, and version. EVN records event information, PID identifies the patient, and PV1 provides visit context. In HL7 v2.5, A14 uses the ADT_A05 message structure. Developers should distinguish the trigger event from its associated message structure and validate required segments against the destination's implementation guide.

MSH Segment: Message Header

MSH identifies the sending and receiving applications, message timestamp, control identifier, and HL7 version. MSH-9 identifies the A14 pending admission event and its associated message structure.

EVN Segment: Event Information

EVN contains metadata associated with the pending admission event, including its recorded timestamp. Receiving applications may use this information for auditing and evaluating message processing order.

PID Segment: Patient Identification

PID contains patient identifiers and demographic information. Receiving applications use these values to identify the patient and associate pending admission details with the correct record.

PV1 Segment: Patient Visit Information

PV1 provides visit-related information, including patient class, location, provider, and visit number when available. The receiving application must interpret these fields within the pending admission workflow.

Optional Segments in A14 Messages

Additional segments may communicate next-of-kin, insurance, or supplementary visit information. Their inclusion depends on the sending system, HL7 version, and agreed interface specification.

HL7 ADT A14 Message Example With Field Explanation

The following HL7 ADT A14 example illustrates a fictional patient with a pending inpatient admission. The message uses HL7 v2.5 conventions and includes patient identification, event metadata, and anticipated visit information. MSH-9 identifies the event as ADT^A14^ADT_A05. PID-3 identifies the patient, PV1-2 contains the planned patient class, and PV1-19 contains the visit identifier. The example illustrates a pending admission rather than an actual admission. Production implementations should follow the sending application's rules for planned locations, patient classification, and encounter identifiers.

Complete HL7 ADT A14 Sample Message

MSH|^~\&|ADT_SYSTEM|HOSPITAL|EHR|MAIN|20261013100000||ADT^A14^ADT_A05|MSG14001|P|2.5
EVN|A14|20261013095500
PID|1||P678901^^^HOSPITAL^MR||MILLER^DANIEL||19660422|M
PV1|1|I|WARD5^510^A||||2468^PATEL^NEHA||||||||||||V14001

All patient information is fictional. The sample represents an anticipated inpatient admission. The presence of I in PV1-2 does not by itself mean that the admission has occurred.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies ADT_SYSTEM as the sending application and EHR as the receiver. ADT^A14^ADT_A05 specifies the pending admission event and associated message structure, while MSG14001 supports tracking.

EVN Segment Explained

EVN identifies the A14 event and records its timestamp. Integration teams may use this information to investigate delayed pending admission notifications and unexpected event sequencing.

PID-3: Patient Identifier Explained

PID-3 identifies fictional patient Daniel Miller through identifier P678901. Receiving applications should validate the identifier and assigning authority before associating the pending admission with an existing patient record.

PV1-2: Patient Class Explained

PV1-2 contains the patient class associated with the anticipated visit. Its interpretation should follow the source interface specification and must not independently trigger confirmed admission processing.

PV1-19: Visit Number Explained

PV1-19 identifies the visit associated with the pending admission when populated. Reliable encounter matching helps prevent duplicate records when a later admission notification is received.

Important HL7 ADT A14 Fields and Mapping

Reliable HL7 A14 integration depends on accurate patient identification, visit matching, and pending status handling. Important fields include MSH-9 for event identification, PID-3 for patient matching, PV1-2 for patient class, and PV1-19 for visit identification. Planned location and provider information may also be included. Receiving systems should distinguish pending admission details from confirmed encounter information and avoid activating clinical or billing workflows prematurely. Developers should document mandatory fields, supported values, and pending encounter behavior before implementing HL7 v2 integration.

MSH-9: Identifying the Pending Admission Event

MSH-9 identifies the A14 trigger event. Integration engines use this field to apply pending admission logic rather than confirmed admission, discharge, transfer, or registration 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 admission information with the correct patient record.

PV1-2: Planned Patient Classification

PV1-2 contains the patient class associated with the anticipated visit. Receiving applications should interpret this value according to pending admission rules and avoid prematurely activating inpatient workflows.

PV1-3: Planned Patient Location

PV1-3 may contain an assigned or anticipated location. Receiving applications should distinguish planned location information from confirmed patient occupancy or physical movement.

PV1-19: Pending Encounter Identification

PV1-19 may identify the pending encounter. Accurate visit matching helps receiving systems connect later admission notifications to the appropriate record without creating unnecessary duplicates.

How HL7 ADT A14 Messages Work in Healthcare Integration

An HL7 ADT A14 workflow begins when a healthcare organization records a pending admission. The source patient administration system generates an A14 notification containing patient identifiers and anticipated visit information. An integration engine receives the message, validates its structure, and routes it to connected applications. Receiving systems locate or establish the appropriate pending encounter according to their interface requirements. When the admission actually occurs, a separate admission notification may update the encounter. Reliable processing requires accurate matching, duplicate prevention, acknowledgment handling, and monitoring to maintain consistent patient and visit information.

Step 1: Pending Admission Is Recorded

The patient administration system records an anticipated admission. The source application generates an A14 notification containing patient identifiers and available visit information.

Step 2: Message Validation

The integration engine validates the HL7 structure, A14 event, patient identifiers, and visit information. Invalid notifications should enter a controlled exception workflow rather than create active admissions.

Step 3: Identify or Establish the Pending Encounter

Receiving applications locate the patient and any existing pending encounter. If permitted by the interface specification, they may establish a pending visit record.

Step 4: Maintain Pending Admission Status

The destination stores or updates the pending admission information without automatically treating the patient as formally admitted. Subsequent admission events should follow the agreed encounter transition rules.

Step 5: Acknowledgment and Monitoring

The receiving application returns an acknowledgment under the configured HL7 processing mode. Integration teams monitor failures, delays, and reconciliation exceptions to maintain consistent pending admission information.

How to Implement HL7 ADT A14 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route HL7 ADT A14 messages through configurable integration channels. A typical workflow receives pending admission notifications over MLLP, checks the trigger event, extracts patient and planned visit information, and forwards the data to authorized destinations. Unlike confirmed admission processing, A14 handling should preserve the distinction between anticipated and active encounters. Developers must also address duplicate notifications, patient matching, and acknowledgment behavior. Mirth Connect development services can support implementation and ongoing maintenance of these interfaces.

Configure an HL7 Source Connector

Create a channel with an MLLP listener and select the appropriate HL7 v2 data type. Configure transport security, source authentication where supported, message validation, and acknowledgment settings.

Filter ADT A14 Messages

Use a source filter to accept A14 notifications and exclude unrelated events. This ensures pending admission processing does not accidentally receive confirmed admission, discharge, or transfer messages.

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

Extract Patient and Pending Visit Information

A JavaScript transformer can extract patient identifiers, visit numbers, planned locations, and patient class. Validate identifiers before routing the message and retain the event's pending admission meaning.

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 patientClass =
    msg['PV1']['PV1.2']['PV1.2.1'].toString();

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

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

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

if (!patientId || !assigningAuthority) {
    throw new Error(
        'Missing patient identifier or assigning authority'
    );
}

if (!messageControlId) {
    throw new Error('Missing message control ID');
}

channelMap.put('patientId', patientId);
channelMap.put('assigningAuthority', assigningAuthority);
channelMap.put('visitNumber', visitNumber);
channelMap.put('patientClass', patientClass);
channelMap.put('plannedUnit', plannedUnit);
channelMap.put('plannedRoom', plannedRoom);
channelMap.put('messageControlId', messageControlId);

This example assumes Mirth Connect has parsed the HL7 message into its XML representation. Production channels should support repeating patient identifiers and additional identifier components.

Transform A14 Data for Destination Systems

Transform pending admission data into the destination's required format while preserving the distinction between planned and active admissions. Avoid automatically activating inpatient encounters or opening billing accounts.

Example JSON transformation:

var pendingAdmission = {
    eventType: 'A14',
    status: 'pending',
    patient: {
        id: channelMap.get('patientId'),
        assigningAuthority:
            channelMap.get('assigningAuthority')
    },
    visitNumber: channelMap.get('visitNumber'),
    plannedPatientClass:
        channelMap.get('patientClass'),
    plannedLocation: {
        unit: channelMap.get('plannedUnit'),
        room: channelMap.get('plannedRoom')
    },
    messageControlId:
        channelMap.get('messageControlId')
};

var jsonPayload = JSON.stringify(pendingAdmission);

channelMap.put('jsonPayload', jsonPayload);

The destination must define how pending notifications are stored, updated, or displayed. The JSON structure above is illustrative rather than a standard HL7-to-JSON specification.

Test and Monitor A14 Processing

Test valid pending admissions, duplicate notifications, missing identifiers, delayed admission confirmations, and destination errors. Confirm that receiving applications do not mistake A14 for a completed admission.

HL7 ADT A14 ACK Message Examples and Error Handling

HL7 acknowledgment messages allow sending systems to determine whether pending admission 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. The receiving application may also return detailed errors through the ERR segment. An accepted A14 message does not establish that the patient was admitted. Integration teams should distinguish successful message processing from subsequent admission events.

Successful ACK Response: AA

An AA acknowledgment indicates application-level acceptance under the configured acknowledgment mode. MSA-2 identifies the original A14 notification, allowing the sender to correlate the response.

MSH|^~\&|EHR|MAIN|ADT_SYSTEM|HOSPITAL|20261013100001||ACK^A14^ACK|ACK14001|P|2.5
MSA|AA|MSG14001

Application Error Response: AE

An AE acknowledgment indicates that an application error occurred during processing. Missing patient identifiers, invalid visit information, or unsupported pending admission workflows may cause errors.

MSH|^~\&|EHR|MAIN|ADT_SYSTEM|HOSPITAL|20261013100002||ACK^A14^ACK|ACK14002|P|2.5
MSA|AE|MSG14001
ERR|||204^Unknown Key Identifier^HL70357|E

Application Rejection Response: AR

An AR acknowledgment indicates that the destination rejected the message. The sender should investigate the reason before correcting or retransmitting the pending admission notification.

MSH|^~\&|EHR|MAIN|ADT_SYSTEM|HOSPITAL|20261013100003||ACK^A14^ACK|ACK14003|P|2.5
MSA|AR|MSG14001

Correlate ACK Responses With Original Messages

MSA-2 contains the original message control identifier. Integration engines use this value to match responses to transmitted A14 messages and track successful or unsuccessful processing.

Handle Failed Acknowledgments Safely

Separate transport failures from application validation errors. Use controlled retries, duplicate detection, and exception queues to prevent repeated pending notifications from creating inconsistent records.

Common HL7 ADT A14 Integration Errors and Troubleshooting

HL7 A14 integration problems often involve pending admissions being interpreted as confirmed admissions, unmatched patient identifiers, duplicate records, or incorrectly mapped planned locations. These issues can affect patient administration, bed management, and downstream clinical applications. An A14 message may also arrive without a visit number, depending on the sending workflow. Troubleshooting should begin with the original message, interface specification, acknowledgment response, and receiving application behavior. Consistent HL7 parsing and data mapping helps reduce implementation errors and supports accurate pre-admission coordination.

Pending Admission Treated as Confirmed Admission

A destination may incorrectly process A14 as A01 and activate an encounter prematurely. Use event-specific logic and verify that pending admission messages do not trigger confirmed admission workflows.

Duplicate Records After A01 Arrives

A receiving application may create one record for A14 and another for A01. Define patient and encounter correlation rules so later admission notifications are matched appropriately.

Missing Visit Number in PV1-19

Some pending admission workflows may not yet have a finalized visit identifier. Document whether PV1-19 is required and how destinations correlate records when it is unavailable.

Incorrect Planned Location Mapping

An anticipated location may be mistaken for actual patient occupancy. Distinguish planned locations from confirmed assignments and avoid triggering physical transfer or bed occupancy changes prematurely.

Out-of-Sequence or Delayed Messages

A14 may arrive after the actual admission notification because of transport delays. Receiving applications should evaluate event state and avoid reverting an active encounter to pending status.

HL7 ADT A14 vs A01, A05, A15, and A27

HL7 ADT trigger events distinguish anticipated admissions from confirmed patient movements and cancellations. A14 provides advance notice of a planned admission without implying that a pre-admission account must be opened. A05 represents pre-admission and may support registration activities before admission. A01 communicates the actual admission or visit notification. A15 communicates a pending transfer, while A27 cancels a pending admission. Correct event interpretation prevents premature encounter activation, duplicate records, and inaccurate patient status across healthcare applications.

A14 vs A01: Pending and Actual Admission

A14 communicates that admission is anticipated, while A01 communicates an actual admission or visit notification. Receiving systems should not treat advance notice as confirmation that the patient has arrived.

A14 vs A05: Pending Admit and Pre-Admit

A14 provides advance admission notification without implying that an account should be opened for pre-admission testing. A05 supports pre-admission workflows where advance registration may be required.

A14 vs A15: Pending Admission and Transfer

A14 concerns an anticipated admission, while A15 concerns an anticipated transfer. These events have different encounter and location implications and should follow separate processing rules.

A14 vs A27: Notification and Cancellation

A14 communicates a pending admission, while A27 cancels that pending admission. Receiving systems should correlate the cancellation with the appropriate pending record or notification.

Best Practices for Reliable HL7 A14 Integration

Reliable HL7 A14 integration depends on clearly separating planned admission information from confirmed encounter activity. Healthcare organizations should document which applications receive advance notifications, how patient and visit identifiers are matched, and whether pending records are created. Interfaces should define supported fields, planned location handling, duplicate detection, acknowledgment behavior, and event sequencing. Because pending admission messages may contain protected health information, secure transmission and access controls are important. Validation, monitoring, and reconciliation help maintain accurate information as a patient progresses from pending admission to actual admission.

Preserve Pending Admission Status

Ensure A14 notifications remain classified as pending. Avoid automatically activating encounters, starting inpatient billing, or recording physical arrival without a separate authorized workflow.

Match Later Admission Notifications Correctly

Define how A14 notifications correlate with subsequent A01 events. Use available patient and visit identifiers while accommodating cases where the final encounter number is assigned later.

Validate Planned Locations and Providers

Check location and provider fields against destination requirements. Treat anticipated assignments as planning information unless the receiving application explicitly supports another interpretation.

Protect Patient Information During Transmission

Use appropriate transport security, access restrictions, and operational logging controls. Avoid exposing unnecessary patient demographics or identifiers in error notifications and monitoring dashboards.

Monitor Pending Admission Lifecycle Events

Track pending notifications, confirmed admissions, cancellations, and exceptions. Reconcile unresolved pending records so outdated admission plans do not remain active indefinitely.

Frequently Asked Questions About HL7 ADT A14 Messages

HL7 A14 integration raises questions about planned admissions, encounter creation, patient matching, and the difference between pending and confirmed events. Healthcare developers and IT teams must understand how A14 relates to A01, A05, and A27 before implementing destination workflows. The following questions address common technical concerns using HL7 v2.5 conventions. Actual processing requirements depend on the sending application, receiving system, and agreed interface implementation guide.

Need Help With HL7 ADT A14 Integration?

Reliable pending admission messaging helps healthcare organizations prepare for patient arrivals without creating inaccurate active encounters. Taction Software supports HL7 interface development, Mirth Connect channel configuration, patient matching, and admission workflow integration. Our engineers can help organizations implement event-specific processing, prevent duplicate records, and establish dependable acknowledgment and monitoring procedures. Whether you are connecting a patient administration system to an EHR or improving existing pre-admission workflows, careful message validation and lifecycle management support more consistent patient information across connected healthcare applications.

Custom HL7 Pending Admission Interfaces

We develop HL7 A14 interfaces based on sending and receiving application requirements. Implementation includes event validation, patient identification, planned visit mapping, routing, and acknowledgment handling.

Mirth Connect Channel Development

Our engineers configure Mirth Connect channels for pending admission notifications, including message filtering, JavaScript transformations, destination connectivity, and exception handling.

Patient Matching and Admission Lifecycle Mapping

We help organizations correlate pending admission notifications with subsequent admission events. These controls support accurate encounter transitions and reduce unnecessary duplicate records.

Production Monitoring and Support

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

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