HL7 ADT A38 Message: Cancel Pre-Admit, Structure, Segments & Examples

The HL7 A38 message is an Admit, Discharge, Transfer (ADT) event used to cancel a previously recorded pre-admission. Officially known as ADT A38: Cancel Pre-Admit, it belongs to the HL7 Version 2 patient administration message family.

Healthcare organizations use pre-admission workflows to register patients before their expected admission. These workflows may support planned inpatient admissions, scheduled procedures, bed planning, insurance verification, and administrative preparation. An A05 event can communicate a pre-admission. If that pre-admission is subsequently canceled, an A38 message informs connected applications that the corresponding pre-admission should no longer be treated as active.

For example, a hospital may pre-register a patient for an upcoming inpatient procedure. If the admission is canceled before the patient is formally admitted, the patient administration system can generate an A38 notification. A38 cancels a pre-admission, not a completed admission or discharge. Receiving systems must identify the correct pre-admission record and apply the cancellation according to their workflow rules.

This guide explains HL7 A38 message structure, segments, sample messages, Mirth Connect implementation, acknowledgment handling, troubleshooting, and best practices.

What Is an HL7 ADT A38 Message?

An HL7 ADT A38 message communicates the cancellation of a previously recorded pre-admission event. It is used when a patient administration system needs to notify connected applications that an existing pre-admission should be canceled.

The event is associated with A05, which represents a pre-admission notification. A38 allows receiving applications to update the corresponding administrative state. A38 should not be interpreted as a patient discharge, a completed admission reversal, or a request to delete the patient's demographic record.

Understanding A38 within the broader HL7 ADT messaging framework helps integration teams distinguish pre-admission cancellation from other patient administration events.

Purpose of the HL7 A38 Event

A38 communicates that a previously recorded pre-admission should be canceled. Receiving applications use the notification to update the relevant pre-admission state while preserving the patient's demographic and historical records.

When Is an ADT A38 Message Generated?

An A38 notification may be generated when a planned admission is canceled, an administrative pre-admission was created incorrectly, or an authorized workflow determines that the pre-admission should no longer remain active.

Which Healthcare Systems Receive A38 Messages?

EHRs, patient administration systems, admission planning applications, bed management platforms, scheduling systems, and financial applications may receive A38 notifications when they support pre-admission cancellation.

How A38 Supports Admission Planning Accuracy

A38 helps connected applications remove canceled pre-admissions from active planning workflows. Correct processing reduces inconsistencies between registration systems, admission planning applications, and departmental dashboards.

Why Accurate A38 Processing Matters

Incorrect A38 processing can cancel the wrong pre-admission or interfere with an encounter that has already progressed to admission. Reliable integration requires accurate encounter matching and status validation.

HL7 ADT A38 Message Structure and Segments

An HL7 ADT A38 message follows the pipe-delimited format used by HL7 Version 2. The message header identifies the cancellation event, while patient and visit information help the receiving application locate the relevant pre-admission.

In HL7 v2.5, A38 uses the ADT_A38 message structure. The core message includes MSH, EVN, PID, and PV1, with additional segments available according to the version and interface profile. Receiving systems should use the exact HL7 implementation guide agreed with the sender, particularly when optional visit and administrative information is included.

MSH Segment: Message Header

MSH identifies the sending application, receiving application, message timestamp, event type, control identifier, and HL7 version. MSH-9 identifies A38 as the Cancel Pre-Admit event.

EVN Segment: Event Information

EVN provides information about the cancellation event, including its timestamp. Receiving applications can use this information when investigating event timing and processing history.

PID Segment: Patient Identification

PID identifies the patient associated with the pre-admission. Receiving systems should validate patient identifiers and assigning authorities before changing an administrative record.

PV1 Segment: Patient Visit Information

PV1 provides visit information, including patient class and visit number. These fields help the destination identify the pre-admission being canceled.

Optional Segments and Interface Requirements

Additional patient, administrative, or visit information may be supported by the implementation profile. Their presence and requirements should be validated against the target HL7 version.

HL7 ADT A38 Message Example With Field Explanation

The following HL7 ADT A38 example illustrates a fictional patient whose planned admission has been canceled before the patient was formally admitted. The example uses HL7 v2.5 conventions and identifies ADT^A38^ADT_A38 in MSH-9.

PID-3 identifies the patient, while PV1-19 identifies the relevant visit number. The destination should match the cancellation to the existing pre-admission and verify that it remains eligible for cancellation.

Complete HL7 ADT A38 Sample Message

MSH|^~\&|REGISTRATION|HOSPITAL|EHR|MAIN|20261015103000||ADT^A38^ADT_A38|MSG38001|P|2.5
EVN|A38|20261015102500
PID|1||P380001^^^HOSPITAL^MR||ANDERSON^LAURA||19860912|F
PV1|1|P|PREADM^001^A||||1234^SMITH^ANNA||||||||||||V38001

All patient information is fictional. In this example, P380001 identifies the patient, and V38001 identifies the pre-admission visit. The receiving application should validate these identifiers before canceling the pre-admission.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies REGISTRATION as the sender and EHR as the receiver. ADT^A38^ADT_A38 identifies the cancellation event and message structure, while MSH-12 specifies HL7 version 2.5.

EVN Segment Explained

EVN identifies A38 and records the event timestamp. This information helps receiving applications investigate when the cancellation was initiated and how it relates to earlier admission planning events.

PID-3: Patient Identifier Explained

PID-3 identifies fictional patient Laura Anderson using patient identifier P380001. The assigning authority provides context for matching the correct patient record.

PV1-2: Patient Class Explained

PV1-2 identifies the patient class. In this illustrative interface, P represents a pre-admission classification, which must be confirmed against the sending application's supported values.

PV1-19: Visit Number Explained

PV1-19 identifies visit V38001. Receiving applications can use this value with PID-3 to locate the pre-admission record targeted by the cancellation.

Important HL7 ADT A38 Fields and Mapping

Reliable HL7 A38 integration depends on accurate patient and pre-admission matching. MSH-9 identifies the cancellation event, MSH-10 provides a unique message control identifier, and MSH-12 identifies the HL7 version. PID-3 identifies the patient, while PV1-19 provides visit context. PV1-2 may indicate the patient class used by the sending application.

Receiving applications should not cancel every planned encounter for a patient simply because an A38 notification arrives. The event must be associated with the correct pre-admission. Clear HL7 v2 integration specifications help maintain consistent pre-admission workflows.

MSH-9: Identifying the A38 Event

MSH-9 identifies A38 as the trigger event. Integration engines should route it through pre-admission cancellation logic rather than discharge, transfer, or completed admission processing.

PID-3: Matching the Correct Patient

PID-3 provides patient identifiers and assigning authorities. The receiving application should validate the complete identifier context before locating the pre-admission.

PV1-19: Identifying the Pre-Admission Visit

PV1-19 identifies the visit associated with the cancellation. Accurate matching prevents an A38 message from affecting another planned or active encounter for the same patient.

PV1-2: Evaluating Patient Class

PV1-2 provides patient class information. The destination should interpret it according to the source system's configuration rather than relying on an assumed universal pre-admission code.

EVN-2: Evaluating Cancellation Timing

EVN-2 records the event timestamp. Receiving applications can use it with the pre-admission history to investigate delayed messages and determine whether cancellation remains appropriate.

How HL7 ADT A38 Messages Work in Healthcare Integration

An HL7 ADT A38 workflow begins when an authorized source application determines that a previously recorded pre-admission must be canceled. The source generates an A38 message identifying the patient and relevant visit. An integration engine validates the notification and routes it to connected applications.

The destination locates the original pre-admission, confirms that cancellation is permitted, and updates the administrative state. If the patient has already been admitted, the destination should not blindly apply A38. It should follow the approved encounter reconciliation process.

Step 1: A Pre-Admission Is Recorded

A patient administration system sends an A05 notification for a planned admission. Connected systems create or update the corresponding pre-admission record.

Step 2: The Planned Admission Is Canceled

An authorized workflow determines that the pre-admission should be canceled. The source generates an A38 notification identifying the affected patient and visit.

Step 3: Validate the A38 Notification

The integration engine checks the event type, patient identifier, visit number, and message metadata. Invalid or incomplete notifications enter an exception workflow.

Step 4: Cancel the Appropriate Pre-Admission

The receiving application locates the matching pre-admission and verifies its current status. It then applies the cancellation according to the destination's approved workflow.

Step 5: Update Downstream Systems and Acknowledge

Connected applications update their supported pre-admission states. The destination returns an acknowledgment and records the processing outcome for monitoring and audit purposes.

How to Implement HL7 ADT A38 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route HL7 A38 messages between hospital registration systems, EHRs, scheduling applications, and admission planning platforms. A typical implementation receives an A38 notification through an MLLP listener, verifies the cancellation event, extracts the patient and visit identifiers, and forwards a cancellation request to the appropriate destination.

The destination must determine whether the referenced pre-admission exists and remains eligible for cancellation. A38 should not automatically reverse an actual admission or remove unrelated scheduling records. Organizations can use Mirth Connect development services to implement these workflows with monitoring, validation, and exception handling.

Configure the HL7 Source Connector

Create a channel with an MLLP Listener and HL7 v2.x inbound data type. Configure the listener port, transport security, sending application restrictions, and acknowledgment settings according to the interface agreement.

Filter HL7 ADT A38 Messages

Use a JavaScript filter to identify A38 notifications. This prevents other patient administration events from entering the pre-admission cancellation 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();

var version =
    msg['MSH']['MSH.12']['MSH.12.1'].toString();

return messageType === 'ADT' &&
       triggerEvent === 'A38' &&
       version === '2.5';

This filter is intended for an interface configured for HL7 v2.5. Production channels should also validate message structure, sending facility, and the supported interface profile.

Extract Patient and Visit Information

Use a JavaScript transformer to extract the patient identifier, visit number, patient class, event timestamp, and message control identifier.

Mirth Connect JavaScript transformer:

function getComponent(segment, field, component) {
    var fieldName = segment + '.' + field;
    var componentName = fieldName + '.' + component;

    var fieldNode = msg[segment][fieldName];

    if (fieldNode.length() === 0) {
        return '';
    }

    var componentNode = fieldNode[componentName];

    if (componentNode.length() === 0) {
        return '';
    }

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

var messageType = getComponent('MSH', 9, 1);
var triggerEvent = getComponent('MSH', 9, 2);
var version = getComponent('MSH', 12, 1);

var patientId = getComponent('PID', 3, 1);
var patientAuthority = getComponent('PID', 3, 4);
var patientIdType = getComponent('PID', 3, 5);

var visitNumber = getComponent('PV1', 19, 1);
var patientClass = getComponent('PV1', 2, 1);

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

var sendingApplication = getComponent('MSH', 3, 1);
var sendingFacility = getComponent('MSH', 4, 1);

if (messageType !== 'ADT' ||
    triggerEvent !== 'A38' ||
    version !== '2.5') {
    throw new Error(
        'Unsupported HL7 message or version'
    );
}

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

if (!visitNumber) {
    throw new Error(
        'Missing pre-admission visit number'
    );
}

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

var cancellationEvent = {
    eventType: 'A38',
    hl7Version: version,

    patient: {
        identifier: patientId,
        assigningAuthority: patientAuthority,
        identifierType: patientIdType
    },

    preAdmission: {
        visitNumber: visitNumber,
        patientClass: patientClass
    },

    source: {
        application: sendingApplication,
        facility: sendingFacility
    },

    eventTimestamp: eventTimestamp,
    messageControlId: messageControlId
};

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

This transformer assumes Mirth Connect has parsed the message into XML. It reads the first patient identifier occurrence and applies a local policy requiring a visit number and assigning authority.

Production implementations should handle repeating identifiers, full assigning-authority components, and any destination-specific pre-admission identifier.

Transform A38 Into a Cancellation Request

Create a destination-specific request that identifies the pre-admission and preserves the original message metadata.

Example JSON transformation:

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

var request = {
    eventType: 'A38',
    action: 'cancelPreAdmission',

    patient: event.patient,
    preAdmission: event.preAdmission,

    processingStatus: 'pending_validation',

    source: event.source,

    sourceEvent: {
        messageControlId: event.messageControlId,
        timestamp: event.eventTimestamp,
        hl7Version: event.hl7Version
    }
};

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

This JSON payload is illustrative and not a standardized HL7 API. The destination must validate the pre-admission record and apply its own cancellation authorization rules.

Validate the Existing Pre-Admission

Locate the corresponding A05 pre-admission using patient and visit identifiers. Verify that the record has not progressed to an actual admission before applying the cancellation.

Configure Acknowledgment and Exception Handling

Configure the source response according to the interface agreement. Unknown visits, already-admitted patients, and conflicting administrative states should enter a monitored exception workflow.

HL7 ADT A38 ACK Message Examples and Error Handling

HL7 acknowledgment messages allow sending applications to determine whether an A38 cancellation notification was accepted or rejected under the configured acknowledgment mode. A typical acknowledgment contains MSH and MSA segments. The ERR segment can communicate additional information about validation or processing failures.

In original acknowledgment mode, AA indicates application acceptance, AE indicates an application error, and AR indicates rejection. The interface agreement should distinguish successful message receipt from completion of the underlying pre-admission cancellation.

Successful ACK Response: AA

An AA acknowledgment indicates application acceptance under the configured mode. MSA-2 references the original A38 message control identifier.

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261015103001||ACK^A38^ACK|ACK38001|P|2.5
MSA|AA|MSG38001

Application Error Response: AE

An AE acknowledgment indicates an application processing error. An unknown visit or a pre-admission that is no longer eligible for cancellation may cause the destination to return an error.

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261015103002||ACK^A38^ACK|ACK38002|P|2.5
MSA|AE|MSG38001
ERR|||204^Unknown Key Identifier^HL70357|E

Application Rejection Response: AR

An AR acknowledgment indicates rejection. Unsupported events, invalid interface profiles, or unauthorized source applications may cause the destination to reject the cancellation.

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261015103003||ACK^A38^ACK|ACK38003|P|2.5
MSA|AR|MSG38001

Correlate ACK Responses With Cancellation Events

MSA-2 contains the original message control identifier. Integration teams use this value to correlate acknowledgments, retries, and downstream cancellation results.

Handle Duplicate Messages and Retries

Use idempotency checks and current pre-admission status validation. A repeated A38 message should not cancel a different visit or modify an encounter that has already progressed.

Common HL7 ADT A38 Integration Errors and Troubleshooting

HL7 A38 integration problems frequently involve missing pre-admission records, incorrect visit numbers, inconsistent patient identifiers, and out-of-sequence notifications. A destination may reject an A38 message because it never received the original A05 event. Another common problem occurs when the patient has already been admitted and the destination cannot safely apply a pre-admission cancellation.

Incorrect mapping can also cause A38 to be treated as a discharge or admission cancellation. Troubleshooting should examine the original message, patient and visit identifiers, encounter status, acknowledgment response, and source event history. Accurate HL7 parsing and data mapping helps prevent these issues.

Original A05 Pre-Admission Cannot Be Found

The receiving system may not have received the original A05 notification. Review message delivery logs, visit identifiers, and existing pre-admission records before retrying.

Incorrect Patient or Visit Number

PID-3 or PV1-19 may not match the destination's records. Validate identifier domains, encounter references, and patient registration history.

A38 Arrives After the Patient Is Admitted

The pre-admission may have progressed to an actual admission. The destination should reject or reconcile the cancellation rather than automatically reversing the active encounter.

A38 Is Mistaken for an Admission Cancellation

A38 cancels a pre-admission, while A11 cancels an admission. Incorrect event mapping can change the wrong administrative state and create downstream inconsistencies.

Duplicate Cancellation Messages Cause Conflicts

Transport retries may deliver the same A38 message more than once. Use message identifiers and pre-admission state checks to prevent unintended repeat processing.

HL7 ADT A38 vs A05, A11, A13, and A28

HL7 Version 2 defines separate patient administration events for pre-admission, admission cancellation, discharge cancellation, and patient information updates. A05 communicates a pre-admission, while A38 cancels it. A11 cancels an admission, and A13 cancels a discharge.

A28 adds person information without necessarily establishing a pre-admission. Although these events may contain similar patient identifiers, their administrative effects differ.

A38 vs A05: Pre-Admission and Cancellation

A05 communicates that a patient has been pre-admitted. A38 cancels a previously recorded pre-admission. The destination should match the cancellation to the correct original visit.

A38 vs A11: Pre-Admission and Admission Cancellation

A38 cancels a pre-admission, while A11 cancels an admission. Receiving systems should distinguish planned admission records from encounters that have already been formally admitted.

A38 vs A13: Pre-Admission and Discharge Cancellation

A13 cancels a discharge event, while A38 cancels a pre-admission. These events apply to different stages of patient administration and require different processing rules.

A38 vs A28: Administrative and Demographic Events

A28 communicates the addition of person information. A38 concerns a pre-admission cancellation and should not be used to delete or deactivate the patient's demographic record.

Best Practices for Reliable HL7 A38 Integration

Reliable HL7 A38 integration requires accurate encounter matching, controlled cancellation processing, and consistent administrative status updates. Healthcare organizations should document how pre-admission events are created, canceled, and represented across connected applications.

Interfaces must distinguish planned admissions from completed admissions and prevent delayed cancellation messages from affecting active encounters. Strong acknowledgment handling, monitoring, and audit records help maintain consistent pre-admission information.

Validate the Original Pre-Admission Record

Confirm that the referenced A05 pre-admission exists and remains eligible for cancellation. Unknown or conflicting records should enter a controlled reconciliation workflow.

Preserve Patient Demographic and Encounter History

Do not delete patient demographics or unrelated encounter records when processing A38. Preserve the historical pre-admission and cancellation information required by the destination.

Apply Event Sequencing and Idempotency Controls

Use message control identifiers, timestamps, and current encounter status to prevent duplicate cancellations and older messages from overriding more recent administrative changes.

Coordinate Downstream Admission Planning Updates

Confirm that connected scheduling, bed management, and admission planning systems reflect the approved cancellation without incorrectly changing unrelated reservations or encounters.

Maintain Security, Monitoring, and Audit Records

Use secure transport, appropriate access controls, and audit logging. Record cancellation requests and outcomes while limiting unnecessary patient information in operational logs.

Frequently Asked Questions About HL7 ADT A38 Messages

HL7 A38 integration raises questions about pre-admission cancellation, patient matching, and the distinction between planned and completed admissions. Healthcare developers need to understand how A38 relates to A05, which identifiers are important, and how receiving applications should handle delayed or duplicate cancellations. The following answers address common technical questions using HL7 Version 2 conventions. Actual requirements depend on the supported HL7 version and interface specification.

Need Help With HL7 ADT A38 Integration?

Accurate pre-admission messaging helps healthcare organizations maintain consistent admission planning information across EHRs, registration systems, and departmental applications. Taction Software supports HL7 interface development, Mirth Connect configuration, patient and visit mapping, and healthcare application integration.

Our engineers can help organizations implement A38 cancellation workflows, validate pre-admission records, manage message exceptions, and establish dependable monitoring and acknowledgment procedures. Whether you are connecting a hospital registration system to an EHR or improving existing ADT interfaces, reliable cancellation processing helps maintain accurate administrative information.

Custom HL7 Pre-Admission Interfaces

We develop HL7 A38 interfaces based on source and destination requirements, including patient matching, visit validation, cancellation processing, and acknowledgment handling.

Mirth Connect Channel Development

Our engineers configure Mirth Connect channels for pre-admission notifications, including JavaScript transformations, event filtering, secure routing, and exception management.

EHR and Patient Administration Integration

We help organizations connect EHRs, registration platforms, and admission planning systems through reliable HL7 messaging and controlled pre-admission workflows.

Production Monitoring and Support

We support HL7 interfaces through monitoring, failure alerts, mapping updates, and reconciliation procedures that help maintain dependable patient administration messaging.

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