HL7 ADT A60 Message: Update Allergy Information, Structure, AL1 Segments & Examples

The HL7 A60message is a patient administration event used to communicate updates to a patient's allergy information between healthcare applications. Officially known as ADT A60: Update Allergy Information, this event allows authorized clinical systems to distribute allergy records to EHRs, pharmacy applications, and other connected platforms. Allergy information may include an allergen, allergy type, severity, reaction, and identification date. Accurate exchange helps healthcare organizations maintain consistent allergy documentation across systems. This guide explains the A60 message structure, AL1 segment fields, sample messages, Mirth Connect transformations, acknowledgments, troubleshooting, and implementation best practices.

What Is an HL7 ADT A60 Message?

An HL7 ADT A60 message communicates allergy information updates associated with a patient. It belongs to the HL7 Version 2 patient administration event family and is intended for systems that support the A60 trigger event. Unlike a general patient demographic update, A60 specifically identifies an allergy information update.

A60 messages can help synchronize allergy information between clinical applications, but the event alone does not guarantee that every destination has applied the same allergy reconciliation rules. Receiving applications must interpret the message according to the HL7 version, implementation profile, and authoritative allergy data source. For the wider event family, see our HL7 ADT messages guide.

Purpose of the HL7 A60 Event

A60 communicates updated allergy information to connected healthcare applications. The receiving system uses the notification to identify the patient and process allergy data according to its supported reconciliation workflow.

When Is an ADT A60 Message Generated?

An A60 notification may be generated when a clinician or authorized application records an allergy, modifies allergy details, or updates allergy information that must be shared with another system.

Which Healthcare Systems Use A60 Messages?

EHRs, hospital information systems, pharmacy applications, medication management platforms, and clinical integration engines may exchange A60 notifications when their interfaces support allergy updates.

How A60 Supports Allergy Information Exchange

A60 provides a structured mechanism for communicating allergy details through HL7 Version 2 messages. Consistent processing helps reduce differences between allergy records maintained by connected applications.

Why Accurate A60 Processing Matters

Allergy information can affect clinical decision support and medication safety. Incorrect mapping, unsupported codes, or accidental removal of existing records may create serious downstream problems requiring clinical reconciliation.

HL7 ADT A60 Message Structure and Segments

HL7 A60 uses the delimiter-based message format defined by HL7 Version 2. The message identifies the source, patient, event, and allergy information being communicated. The AL1 segment is central to many A60 workflows in practice. An AL1 segment can describe the allergy type, allergen code or description, severity, reaction, and identification date.

Note on the standard structure: in HL7 v2.4 and later, the formal ADT_A60 message structure carries allergies in the IAM (Patient Adverse Reaction Information) segment rather than AL1. IAM adds an action code (add, update, delete) and a unique allergy identifier, which makes record-level updates explicit. Many production interfaces still send AL1 in A60 messages, so confirm which segment your sender uses before building the mapping. The exact message structure and required segments depend on the HL7 version and implementation profile.

MSH Segment: Message Header

MSH identifies the sending and receiving applications, message timestamp, event type, control identifier, and HL7 version. MSH-9 identifies the A60 allergy update event.

EVN Segment: Event Information

EVN provides administrative information about the allergy update event, including its recorded timestamp. This supports event tracking and integration troubleshooting.

PID Segment: Patient Identification

PID identifies the patient associated with the allergy information. Accurate patient matching is essential before any allergy record is created or modified.

AL1 Segment: Patient Allergy Information

AL1 contains structured allergy information. Multiple AL1 segments may be present when the interface communicates more than one allergy entry.

Optional Segments and Profile Requirements

Additional segments may be supported by the applicable HL7 message structure, including IAM in the standard ADT_A60 definition. The interface specification must define segment cardinality, allergy update semantics, and any additional clinical context.

HL7 ADT A60 Message Example With Field Explanation

Consider a hospital where a clinician documents a patient's allergy to penicillin. The allergy is classified as a drug allergy, with a severe reaction involving hives and breathing difficulty. The EHR records the allergy and sends an A60 notification to a connected clinical application.

The receiving system validates the patient identifier and interprets the AL1 segment according to its allergy terminology mapping. The following sample illustrates the main fields using HL7 v2.5 conventions.

Complete HL7 ADT A60 Sample Message

MSH|^~\&|EHR|HOSPITAL|PHARMACY|MAIN|20261022143000||ADT^A60^ADT_A60|MSG60001|P|2.5
EVN|A60|20261022142500
PID|1||MRN600001^^^HOSPITAL^MR||BROWN^EMILY||19870521|F
AL1|1|DA|PENICILLIN^Penicillin|SV|Hives and breathing difficulty|20261022

All patient information is fictional. The allergen code in this example is illustrative, not a standardized medication terminology identifier.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies EHR as the sending application and PHARMACY as the destination. ADT^A60^ADT_A60 identifies the allergy information update event and message structure, while MSH-10 provides the message control identifier.

EVN Segment Explained

EVN identifies the administrative event and its recorded timestamp. The receiving application can use this information for audit tracking and message reconciliation.

PID-3: Patient Identifier Explained

PID-3 contains the patient identifier MRN600001. The receiving application must match this identifier and its assigning authority before processing allergy information.

AL1-2 and AL1-3 Explained

AL1-2 identifies the allergy type, while AL1-3 contains the allergy code and description. In this example, DA indicates a drug allergy, and the substance is penicillin.

AL1-4, AL1-5, and AL1-6 Explained

AL1-4 represents allergy severity, AL1-5 describes the reaction, and AL1-6 provides the identification date. These fields help receiving systems interpret the documented allergy.

Important HL7 ADT A60 Fields and AL1 Mapping

Accurate A60 integration depends on correct patient identification and consistent interpretation of allergy data. MSH identifies the message and sender, while PID provides patient identity. AL1 contains the clinical allergy details.

A receiving application must understand the allergy terminology, severity coding, and whether the message represents a new record, modification, or broader allergy-list synchronization. The AL1 segment alone does not provide a universal record-level update operation or stable allergy identifier. Where both systems support it, the IAM segment's action code (IAM-6) and unique identifier (IAM-7) close that gap. Our HL7 parsing and data mapping team can document field-level rules for either segment.

AL1-1: Set ID

AL1-1 identifies the sequence of the AL1 segment within the message. It should not be assumed to be a permanent allergy record identifier across different messages.

AL1-2: Allergen Type Code

AL1-2 identifies the allergy category, such as drug, food, or environmental allergy. The destination must validate supported codes and local terminology mappings.

AL1-3: Allergen Code and Description

AL1-3 identifies the allergen through a coded or descriptive value. Standardized terminology and coding system identifiers should be used where supported by the implementation.

AL1-4: Allergy Severity Code

AL1-4 represents severity using a coded value. Severity should be mapped according to the applicable HL7 value set and the receiving application's supported clinical terminology.

AL1-5 and AL1-6: Reaction and Identification Date

AL1-5 communicates allergy reaction information, while AL1-6 records the identification date. Both require appropriate data type handling and preservation of clinical meaning.

How HL7 ADT A60 Allergy Update Workflows Operate

An A60 workflow begins when an authorized clinician or application records or updates allergy information. The source application verifies the patient and allergy details. It then generates an A60 message containing the relevant allergy segments.

An integration engine validates the message and routes it to connected applications. The receiving system matches the patient, maps the allergen and reaction terminology, and processes the information according to its allergy reconciliation rules.

Step 1: Record or Update Allergy Information

An authorized clinical workflow records allergy details, including the allergen, reaction, and severity where available. The source application determines whether the update should be distributed.

Step 2: Validate the Patient and Allergy Data

The source verifies patient identity and checks allergy data for required fields, terminology, and supported values before generating the notification.

Step 3: Generate the A60 Message

The source creates an A60 message containing patient identification and one or more AL1 segments representing the allergy information being communicated.

Step 4: Transform and Route the Allergy Update

An integration engine validates the message, maps terminology where necessary, and forwards the allergy information to authorized destination applications.

Step 5: Reconcile and Acknowledge the Result

The destination applies its supported allergy reconciliation rules, records the processing outcome, and returns an acknowledgment according to the interface agreement.

How to Implement HL7 ADT A60 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route HL7 A60 messages between EHRs, pharmacy systems, medication management applications, and other healthcare platforms. A typical integration receives an A60 notification through an MLLP listener, validates the event, extracts patient and allergy information, and forwards the data to an authorized clinical application.

Allergy updates require special care because the meaning of an update is not always equivalent to replacing an entire allergy list. The destination must distinguish new information, corrected records, duplicate entries, and potentially conflicting allergy details. An integration engine should not independently delete existing allergies or override clinical review requirements. Mirth Connect development services can support these requirements.

Configure the Mirth Connect Source Connector

Create a channel with an MLLP Listener and HL7 v2.x inbound data type. Configure trusted senders, transport security, message retention, acknowledgment processing, and appropriate access controls for protected health information.

Filter HL7 ADT A60 Messages

Use a JavaScript filter to identify A60 notifications and prevent unrelated ADT events from entering the allergy processing workflow.

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 === 'A60' &&
       version === '2.5';

This example targets HL7 v2.5. Production implementations should also validate MSH-9.3, the sender's approved identity, message structure, segment cardinality, and the agreed implementation profile.

Extract Patient and Allergy Information

A source transformer can extract the patient identifier and process repeating AL1 segments. The following example builds a structured representation of the allergy information without directly modifying the destination's clinical records.

function component(node, fieldName, componentName) {
    if (node.length() === 0) {
        return '';
    }

    var fieldNode = node[fieldName];

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

    return fieldNode[componentName].toString().trim();
}

var msh = msg['MSH'];
var pid = msg['PID'];

var messageType = component(
    msh, 'MSH.9', 'MSH.9.1'
);

var triggerEvent = component(
    msh, 'MSH.9', 'MSH.9.2'
);

var version = component(
    msh, 'MSH.12', 'MSH.12.1'
);

var controlId = component(
    msh, 'MSH.10', 'MSH.10.1'
);

var patientId = component(
    pid, 'PID.3', 'PID.3.1'
);

var patientAuthority = component(
    pid, 'PID.3', 'PID.3.4'
);

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

if (!patientId || !controlId) {
    throw new Error(
        'Missing patient ID or message control ID'
    );
}

var allergies = [];

for each (var al1 in msg['AL1']) {

    var setId = component(
        al1, 'AL1.1', 'AL1.1.1'
    );

    var allergyType = component(
        al1, 'AL1.2', 'AL1.2.1'
    );

    var allergenCode = component(
        al1, 'AL1.3', 'AL1.3.1'
    );

    var allergenDescription = component(
        al1, 'AL1.3', 'AL1.3.2'
    );

    var codingSystem = component(
        al1, 'AL1.3', 'AL1.3.3'
    );

    var severity = component(
        al1, 'AL1.4', 'AL1.4.1'
    );

    var reaction = component(
        al1, 'AL1.5', 'AL1.5.1'
    );

    var identificationDate = component(
        al1, 'AL1.6', 'AL1.6.1'
    );

    if (!allergenCode && !allergenDescription) {
        throw new Error(
            'AL1 segment missing allergen information'
        );
    }

    allergies.push({
        setId: setId,
        type: allergyType,
        allergen: {
            code: allergenCode,
            description: allergenDescription,
            codingSystem: codingSystem
        },
        severity: severity,
        reaction: reaction,
        identificationDate: identificationDate
    });
}

if (allergies.length === 0) {
    throw new Error(
        'No AL1 segments found in A60 message'
    );
}

var allergyEvent = {
    eventType: 'A60',

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

    allergies: allergies,

    messageControlId: controlId,
    hl7Version: version
};

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

This example is designed for a Mirth Connect JavaScript transformer using E4X. It illustrates basic extraction, not a complete clinical allergy reconciliation engine. In particular, production implementations should preserve repeated PID identifiers, complete HD assigning authorities, coded reaction repetitions, and terminology components required by the destination. If your sender uses IAM instead of AL1, iterate over msg['IAM'] and map IAM-3, IAM-4, IAM-5, IAM-6 and IAM-7 instead.

Transform A60 Into a Destination Request

The integration engine can create a JSON payload for an approved allergy management API. The payload should request reconciliation rather than automatically replacing the patient's complete allergy list.

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

var request = {
    eventType: 'A60',
    action: 'requestAllergyReconciliation',

    patient: event.patient,

    allergyEntries: event.allergies,

    processingStatus:
        'pending_clinical_validation',

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

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

This JSON structure is illustrative, not a standardized HL7 API. The destination must determine whether each allergy entry represents new information, an update to an existing record, or a potential conflict.

Validate Allergy Terminology and Severity

Confirm that allergen codes, coding systems, severity values, and reaction information are supported by the receiving application. Route unrecognized or ambiguous clinical terminology for review rather than silently discarding it.

Configure Destination Processing and Error Handling

Use an approved clinical API or supported HL7 interface. Configure duplicate detection, controlled retries, clinical exception handling, acknowledgment processing, and monitoring for allergy updates that cannot be safely reconciled.

HL7 ADT A60 ACK Message Examples and Error Handling

HL7 acknowledgments allow a sending application to determine whether an A60 notification was accepted or rejected according to the configured processing agreement. A typical acknowledgment includes MSH and MSA segments. ERR may provide additional diagnostic information when validation or application processing fails.

In original acknowledgment mode, AA indicates application acceptance, AE indicates an application error, and AR indicates rejection. The interface must distinguish message acceptance from successful clinical reconciliation. An AA response should not be interpreted as proof that every allergy entry has been accepted into the destination's active allergy list.

Successful A60 ACK: AA

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

MSH|^~\&|PHARMACY|MAIN|EHR|HOSPITAL|20261022143001||ACK^A60^ACK|ACK60001|P|2.5
MSA|AA|MSG60001

Application Error ACK: AE

An AE acknowledgment may indicate a processing error, such as an unsupported allergy code, invalid patient identifier, or destination validation failure.

MSH|^~\&|PHARMACY|MAIN|EHR|HOSPITAL|20261022143002||ACK^A60^ACK|ACK60002|P|2.5
MSA|AE|MSG60001
ERR|||102^Data Type Error^HL70357|E

The error is illustrative. Actual ERR values and field locations must follow the destination's HL7 version and implementation profile.

Application Rejection ACK: AR

An AR acknowledgment indicates that the application rejected the message. Possible reasons include an unsupported event, unauthorized sender, or invalid message structure.

MSH|^~\&|PHARMACY|MAIN|EHR|HOSPITAL|20261022143003||ACK^A60^ACK|ACK60003|P|2.5
MSA|AR|MSG60001

Correlate ACK Responses With Allergy Updates

MSA-2 should match the original MSH-10 message control identifier. Monitoring records should associate each acknowledgment with the patient, source system, allergy entries, and processing outcome.

Handle Failed Acknowledgments and Safe Retries

Before resending an unacknowledged A60 message, verify whether the destination already processed it. Retried notifications must not create duplicate allergy records or erase later clinically reviewed information.

Common HL7 ADT A60 Integration Errors and Troubleshooting

HL7 A60 integration failures commonly involve patient identifier mismatches, unsupported allergen terminology, severity mapping differences, and duplicate allergy records. An application may recognize the patient but fail to interpret the allergen code because the source and destination use different terminology systems.

Another destination may treat the AL1 segment as a complete allergy list when the source intended to communicate only a specific update. These differences can produce incomplete or inaccurate clinical records. A reliable implementation requires explicit reconciliation rules, terminology validation, and clinical exception handling.

Allergen Codes Are Not Recognized

The destination may not recognize a local allergen code. Preserve the original coding system and description, apply approved terminology mappings, and route unresolved codes for review.

AL1 Severity Codes Are Mapped Incorrectly

A severity code may not have the same interpretation in every destination application. Validate the applicable value set and document how severity is represented in the receiving system.

Allergy Reactions Are Lost During Transformation

AL1-5 may contain reaction information that requires specific parsing or terminology handling. A transformation that extracts only a single text component may discard important details.

Duplicate Allergy Entries Are Created

Repeated A60 messages or inconsistent allergen matching can create duplicate entries. Use destination-supported record matching and clinical reconciliation rather than assuming AL1-1 is a permanent identifier.

Existing Allergies Are Accidentally Removed

A destination may incorrectly interpret an A60 message as replacing the entire allergy list. Define whether the interface sends incremental changes or a complete snapshot before enabling updates.

Sender Uses IAM but Destination Expects AL1

A sender following the standard ADT_A60 structure may send IAM segments while the receiver only parses AL1, so allergies silently disappear. Confirm the segment in the interface specification and map IAM to AL1, or the reverse, in the integration engine when needed.

HL7 ADT A60 vs A08, AL1, and FHIR AllergyIntolerance

HL7 A60, A08, AL1, IAM, and FHIR AllergyIntolerance are related to healthcare information exchange, but they represent different concepts. A60 and A08 are HL7 Version 2 trigger events. AL1 and IAM are segments used to represent allergy information within supported messages. FHIR AllergyIntolerance is a resource for exchanging allergy and intolerance information through FHIR-based interfaces.

Understanding these differences helps integration teams choose appropriate message handling and mapping strategies.

A60 vs A08: Allergy-Specific and General Updates

A60 specifically identifies an allergy information update. A08 is a broader patient information update event. The correct event depends on the source application's supported workflow and interface agreement.

A60 vs AL1 and IAM: Event and Segment

A60 identifies the purpose of the message, while AL1 or IAM carries the allergy information. AL1 may appear in several message structures, such as A01, A04 and A08, and is not itself a trigger event. IAM is the segment defined for the standard ADT_A60 structure.

A60 vs FHIR AllergyIntolerance

A60 is an HL7 Version 2 event. FHIR AllergyIntolerance is a structured clinical resource. Mapping between them requires attention to clinical status, verification status, coding, reactions, and available source information. Our HL7 v2 vs FHIR guide covers how the two standards differ.

A60 vs Pharmacy Medication Messages

A60 communicates allergy updates, while pharmacy messages address medication orders, dispensing, or administration workflows. Allergy information may influence medication safety checks but does not itself constitute a medication order.

Best Practices for Reliable HL7 A60 Integration

Reliable HL7 A60 integration requires accurate patient matching, structured allergy terminology, and clearly defined clinical reconciliation rules. Healthcare organizations should identify the authoritative source of allergy information and document how receiving applications process new, changed, or conflicting entries.

Interfaces must preserve clinical meaning, prevent duplicate records, and avoid unsafe assumptions about allergy-list replacement. The implementation should also support auditability, access controls, exception monitoring, and testing with realistic clinical scenarios.

Use Standardized Allergy Terminology Where Possible

Prefer supported standardized allergen and reaction terminology with explicit coding system identifiers. Preserve original source values so clinical teams can investigate unmapped or ambiguous entries.

Define Allergy Update and Replacement Rules

Document whether A60 messages represent incremental changes, full allergy-list snapshots, or another sender-specific convention. Do not delete existing allergy records without an explicitly authorized workflow.

Preserve Clinical Details and Source Provenance

Retain available severity, reaction, identification date, and source information. These details help clinicians evaluate allergy records and investigate discrepancies between connected applications.

Implement Safe Duplicate Detection

Use destination-supported allergy matching and message tracking. Do not rely solely on AL1-1, which identifies segment sequence rather than a universally stable allergy record.

Monitor Clinical Reconciliation Failures

Alert integration and clinical teams when patient matching, terminology mapping, or allergy reconciliation fails. Maintain an exception workflow that supports timely investigation without silently losing allergy information.

Frequently Asked Questions About HL7 ADT A60 Messages

HL7 A60 integration raises questions about allergy update events, allergy segment fields, clinical terminology, and synchronization between EHRs and pharmacy applications. The following answers address common implementation requirements.

Need Help With HL7 ADT A60 Integration?

Allergy information exchange requires reliable communication between EHRs, pharmacy applications, medication management platforms, and other clinical systems. Taction Software supports HL7 interface development, Mirth Connect implementation, clinical data mapping, and healthcare interoperability.

Our engineers can help organizations implement A60 workflows, configure AL1 and IAM segment transformations, investigate integration errors, and establish monitoring and reconciliation procedures.

HL7 Allergy Information Interface Development

We develop HL7 allergy information interfaces based on source and destination requirements, including patient matching, allergy segment mapping, terminology handling, and clinical data validation.

Mirth Connect Development and Integration

Our engineers configure Mirth Connect channels for allergy notifications, including JavaScript transformations, secure routing, acknowledgment handling, and exception management.

EHR and Pharmacy System Integration

We support integration between EHRs, pharmacy applications, medication management platforms, and other clinical systems using approved allergy information exchange workflows.

Production Monitoring and Troubleshooting

We help investigate unsupported allergy codes, missing reaction information, duplicate entries, acknowledgment failures, and inconsistent downstream allergy records.

Need help with HL7 allergy integration? Explore our HL7 interface messaging services and EHR and EMR integration services to discuss your requirements.