HL7 ADT A37 Message: Unlink Patient Information, Structure, Segments & Examples

The HL7 A37 message is an Admit, Discharge, Transfer (ADT) event used to unlink patient information that was previously associated incorrectly. Known as ADT A37: Unlink Patient Information, it belongs to the HL7 Version 2 patient administration message family.

Healthcare applications often maintain relationships between patient identifiers, registration records, and enterprise master patient index (EMPI) identities. When an authorized identity management process determines that two identifiers have been linked incorrectly, an A37 message can communicate the unlink operation. For example, a hospital may discover that records belonging to two different individuals were mistakenly associated under a single identity relationship. After reviewing the records, authorized staff approve separating the incorrect linkage.

An A37 message helps connected applications recognize that the previously established relationship should no longer be treated as valid. However, unlinking is not the same as deleting patient information, canceling an encounter, or automatically reversing a completed patient merge. The receiving application must apply the appropriate identity reconciliation rules.

This guide explains HL7 A37 message structure, examples, PID segments, Mirth Connect implementation, acknowledgment handling, troubleshooting, and best practices.

What Is an HL7 ADT A37 Message?

An HL7 ADT A37 message communicates an unlink operation involving patient information. It is used when patient identity relationships need to be corrected after an authorized process determines that records or identifiers should no longer be associated.

A37 is the counterpart of A24 (Link Patient Information): A24 creates a link between two patient records, and A37 removes it. A37 differs from a merge event because its purpose is to remove an inappropriate relationship rather than combine identifiers. The event is relevant to patient registration systems, enterprise master patient indexes, and EHR environments that maintain multiple patient identifiers.

Understanding A37 within the broader HL7 ADT messaging framework helps integration teams distinguish unlink operations from merges and demographic updates.

Purpose of the HL7 A37 Event

A37 communicates that an existing patient identity linkage should be removed. Receiving applications use the event to correct the relevant relationship while preserving appropriate patient and clinical records.

When Is an ADT A37 Message Generated?

An A37 notification may be generated after authorized identity management staff determine that two patient records or identifiers were incorrectly linked and approve separating them.

Which Healthcare Systems Receive A37 Messages?

Enterprise master patient indexes, patient registration systems, EHRs, health information exchanges, and other identity-aware applications may receive A37 notifications when their interfaces support unlink workflows.

How A37 Supports Patient Identity Accuracy

A37 helps connected applications correct inappropriate identity associations. Proper processing reduces the risk of unrelated patient information being presented under a shared identity relationship.

Why Accurate A37 Processing Matters

Incorrect unlink processing can fragment a legitimate patient record or leave unrelated identities connected. Reliable integration requires identity verification, relationship validation, authorization, and audit records.

HL7 ADT A37 Message Structure and Segments

An HL7 ADT A37 message follows the segment-based format defined by HL7 Version 2. Important information includes the message header, event details, and the identification of both patient records involved in the unlink operation.

For HL7 v2.5, the A37 event uses the ADT_A37 message structure. Instead of an MRG segment, ADT_A37 carries two PID segments, one for each patient record, and each PID may be followed by optional PD1, PV1, and DB1 segments. This mirrors the ADT_A24 structure used to create the link. Unlike a routine demographic update, A37 must identify the relationship being separated, and receiving applications should validate that relationship before making changes.

MSH Segment: Message Header

MSH identifies the sending application, receiving application, message timestamp, trigger event, message control identifier, and HL7 version. MSH-9 identifies A37 as the unlink event.

EVN Segment: Event Information

EVN records event metadata, including the event timestamp. Receiving applications can use this information to investigate when the unlink operation was initiated.

First PID Segment: First Patient Record

The first PID identifies one of the two patient records involved in the unlink operation. Receiving systems should validate the complete patient identifier context, including assigning authorities where available.

Second PID Segment: Second Patient Record

The second PID identifies the other patient record in the relationship being removed. Parsers must read both PID segments; reading only the first one loses half of the relationship.

Version-Specific Unlink Requirements

The supported HL7 version determines the exact message structure and field definitions. Production interfaces should follow the agreed implementation guide rather than assuming every unlink workflow uses identical fields, and should not reuse merge-event (MRG) mappings for A37.

HL7 ADT A37 Message Example With Field Explanation

The following HL7 A37 example illustrates a fictional patient identity relationship that has been determined to be incorrect. The source application is an enterprise master patient index, and the destination is an EHR.

The example uses HL7 v2.5 conventions. The first PID-3 identifies one patient record, and the second PID-3 identifies the other record whose link is being removed. The receiving system should validate the existing linkage and the authorized unlink decision before modifying patient identity associations.

Complete HL7 ADT A37 Sample Message

MSH|^~\&|EMPI|HOSPITAL|EHR|MAIN|20261014140000||ADT^A37^ADT_A37|MSG37001|P|2.5
EVN|A37|20261014135500
PID|1||P370001^^^HOSPITAL^MR||THOMPSON^SARAH||19830719|F
PID|2||P370002^^^HOSPITAL^MR||THOMSON^SARAH||19810302|F

All patient information is fictional. The example communicates an unlink request involving patient identifiers P370001 and P370002, which belong to two different people with similar names. It does not authorize the destination to delete clinical records or automatically reverse historical transactions.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies EMPI as the sending application and EHR as the receiver. ADT^A37^ADT_A37 identifies the unlink event and message structure.

EVN Segment Explained

EVN identifies the A37 event and records its timestamp. The receiving application can use the timestamp when reviewing the identity reconciliation history.

First PID-3: Patient Identifier Explained

The first PID-3 identifies one patient record involved in the unlink operation. The assigning authority helps distinguish the identifier from similar values in other systems.

Second PID-3: Linked Patient Identifier Explained

The second PID-3 identifies the other patient record. The receiving application should use both identifiers together to locate the exact relationship being separated.

Understanding the Unlink Direction

A37 identifies a relationship to be removed rather than a surviving and prior record to be merged. Neither PID is "surviving"; the destination must confirm which identity association between the two records is affected.

Important HL7 ADT A37 Fields and Mapping

Reliable HL7 A37 integration depends on accurate patient matching and correct interpretation of the identity relationship being unlinked. MSH-9 identifies the event, MSH-10 supports message tracking, and MSH-12 identifies the HL7 version. PID-3 in each of the two PID segments identifies one of the patient records in the relationship.

Receiving applications should validate both identifiers and their assigning authorities before changing identity relationships. An A37 message should not be treated as a request to delete records or automatically separate every clinical transaction associated with a previous merge. Clear HL7 v2 integration specifications help prevent these errors.

MSH-9: Identifying the A37 Event

MSH-9 identifies A37 as the trigger event. Integration engines should route the notification through an identity unlink workflow rather than a patient merge or demographic update.

First PID-3: Identifying the First Patient Record

PID-3 in the first PID segment provides one patient identifier involved in the unlink operation. Receiving systems should validate its assigning authority and current identity relationships.

Second PID-3: Identifying the Related Patient Record

PID-3 in the second PID segment provides the other patient identifier. The destination should use it to locate the specific identity relationship targeted by the unlink request.

MSH-10: Tracking the Unlink Notification

MSH-10 contains the message control identifier. Integration teams use it for acknowledgment correlation, duplicate detection, and operational audit records.

EVN-2: Reviewing the Unlink Event Timestamp

EVN-2 records the event timestamp. It helps integration teams investigate when the unlink decision was communicated and whether subsequent identity changes occurred.

How HL7 ADT A37 Messages Work in Healthcare Integration

An HL7 ADT A37 workflow begins when an authorized identity management process identifies an incorrect relationship between patient records. The source application determines which linkage must be removed and generates an A37 notification. An integration engine receives the message, validates the identifiers, and routes the request to the destination.

The receiving application locates the existing relationship, verifies that unlinking is permitted, and applies its approved identity reconciliation procedure. Because unlinking can affect access to clinical information, the process must preserve record integrity and maintain a detailed audit history.

Step 1: An Incorrect Patient Linkage Is Identified

An authorized identity management process determines that two patient records or identifiers were incorrectly associated. The relationship is reviewed before an unlink request is approved.

Step 2: Generate the A37 Unlink Notification

The source application creates an A37 message containing both patient records and the event information required by the supported HL7 implementation profile.

Step 3: Validate the Identity Relationship

The integration engine checks the event type, both patient identifiers, assigning authorities, and message metadata. Invalid or ambiguous requests enter an exception workflow.

Step 4: Apply the Authorized Unlink Operation

The receiving application verifies the existing linkage and applies its approved unlink procedure. It should preserve clinical records and avoid unintended changes to unrelated identities.

Step 5: Acknowledge and Audit the Outcome

The destination returns an acknowledgment according to the configured processing mode. Audit records document the identifiers, relationship, source event, and processing result.

How to Implement HL7 ADT A37 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route HL7 ADT A37 messages between enterprise master patient indexes, registration systems, EHRs, and other identity-aware healthcare applications. A typical implementation receives an A37 notification through an MLLP listener, validates the message type and both patient identifiers, and forwards a controlled unlink request to the destination identity management application.

Unlike routine demographic updates, unlinking can change which clinical records are associated with a patient identity. The receiving system must therefore verify that the relationship exists and that the unlink operation has been authorized. Organizations can use Mirth Connect development services to build these interfaces with validation, monitoring, and exception handling.

Configure the HL7 Source Connector

Create a Mirth Connect channel with an MLLP Listener and HL7 v2.x inbound processing. Configure source authentication, message validation, acknowledgment handling, and appropriate retention policies.

Filter HL7 ADT A37 Messages

Use a JavaScript filter to identify A37 notifications. Route unlink events separately from merge events such as A40 and demographic updates such as A31.

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

This example assumes the interface supports HL7 v2.5. Production channels should also validate the sending application, facility, message structure, and agreed implementation profile.

Extract Both Patient Identities

Use a JavaScript transformer to extract the identifiers from both PID segments, including assigning authorities and the message control identifier. In Mirth Connect, repeated segments are available as an indexed list, so msg['PID'][0] and msg['PID'][1] address the two patient records.

Mirth Connect JavaScript transformer:

// ADT_A37 carries two PID segments, one per patient record.
function getComponent(segmentNode, field, component) {
    var fieldName = segmentNode.name().toString() + '.' + field;
    var componentName = fieldName + '.' + component;

    var node = segmentNode[fieldName];

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

    var value = node[0][componentName];

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

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

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

var messageType = getComponent(msh, 9, 1);
var triggerEvent = getComponent(msh, 9, 2);
var hl7Version = getComponent(msh, 12, 1);

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

if (pidSegments.length() !== 2) {
    throw new Error(
        'A37 must contain exactly two PID segments'
    );
}

var firstPid = pidSegments[0];
var secondPid = pidSegments[1];

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

var linkedPatientId = getComponent(secondPid, 3, 1);
var linkedAuthority = getComponent(secondPid, 3, 4);
var linkedIdType = getComponent(secondPid, 3, 5);

var controlId = getComponent(msh, 10, 1);
var eventTimestamp = getComponent(msg['EVN'], 2, 1);

if (!patientId || !linkedPatientId) {
    throw new Error(
        'A37 missing required patient identifiers'
    );
}

if (!patientAuthority || !linkedAuthority) {
    throw new Error(
        'A37 missing required assigning authority'
    );
}

if (patientId === linkedPatientId &&
    patientAuthority === linkedAuthority) {
    throw new Error(
        'Cannot unlink an identifier from itself'
    );
}

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

var unlinkEvent = {
    eventType: 'A37',
    hl7Version: hl7Version,

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

    relatedPatient: {
        identifier: linkedPatientId,
        assigningAuthority: linkedAuthority,
        identifierType: linkedIdType
    },

    messageControlId: controlId,
    eventTimestamp: eventTimestamp
};

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

This example assumes the message has been parsed into Mirth Connect's XML representation. It processes the first identifier occurrence in each PID and is intended for an interface requiring populated assigning authorities.

Production implementations must handle repeating identifiers, full HD assigning-authority components, optional PD1/PV1/DB1 segments between the two PIDs, and any additional relationship identifiers required by the destination.

Transform A37 Into an Identity Unlink Request

Create a destination-specific request that identifies the patient relationship to be separated. The receiving application should validate the current relationship before applying the change.

Example JSON transformation:

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

var request = {
    eventType: 'A37',
    action: 'requestPatientIdentityUnlink',

    patient: event.patient,
    relatedPatient: event.relatedPatient,

    processingStatus: 'pending_validation',

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

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

This payload is illustrative and is not a standardized HL7 API. The receiving identity management service must independently validate the relationship, authorization, and affected records.

Validate the Existing Identity Linkage

Confirm that the two patient identifiers are currently linked in the destination system. If the relationship does not exist or has already changed, route the request for reconciliation.

Configure Acknowledgment and Exception Handling

Configure ACK responses according to the interface agreement. Invalid identifiers, unknown relationships, unauthorized requests, and partial reconciliation failures should enter a monitored exception workflow.

HL7 ADT A37 ACK Message Examples and Error Handling

HL7 acknowledgments allow sending applications to determine whether an A37 notification was accepted or rejected under the configured processing mode. A typical acknowledgment contains MSH and MSA segments, with ERR available to communicate additional error information.

In original acknowledgment mode, AA indicates application acceptance, AE indicates an application error, and AR indicates rejection. For identity unlink operations, the interface agreement should distinguish message acceptance from completion of the underlying identity reconciliation. A successful acknowledgment does not necessarily confirm that every downstream application has updated its identity relationships.

Successful ACK Response: AA

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

MSH|^~\&|EHR|MAIN|EMPI|HOSPITAL|20261014140001||ACK^A37^ACK|ACK37001|P|2.5
MSA|AA|MSG37001

Application Error Response: AE

An AE acknowledgment indicates an application processing error. The destination may be unable to locate the existing relationship or validate the supplied identifiers.

MSH|^~\&|EHR|MAIN|EMPI|HOSPITAL|20261014140002||ACK^A37^ACK|ACK37002|P|2.5
MSA|AE|MSG37001
ERR|||204^Unknown Key Identifier^HL70357|E

Application Rejection Response: AR

An AR acknowledgment indicates rejection by the receiving application. Unsupported events, unauthorized sources, or invalid interface profiles may cause rejection.

MSH|^~\&|EHR|MAIN|EMPI|HOSPITAL|20261014140003||ACK^A37^ACK|ACK37003|P|2.5
MSA|AR|MSG37001

Correlate ACK Responses With Unlink Requests

MSA-2 references the original message control identifier. Integration teams use this value to associate acknowledgments, retries, and processing outcomes with the corresponding unlink request.

Handle Failed Acknowledgments and Retries

Before retrying, inspect the current identity relationship. An unlink request that was already completed should not be reapplied in a way that affects another relationship.

Common HL7 ADT A37 Integration Errors and Troubleshooting

HL7 A37 integration problems often involve incorrect patient identifiers, missing identity relationships, inconsistent assigning authorities, and confusion between unlinking and reversing a patient merge. A destination may reject an A37 message because the two identifiers are not currently linked or because the relationship has already been corrected.

Other failures occur when a source provides incomplete identifier domains, when a parser reads only the first PID segment, or when an integration engine treats A37 as an A40 merge event. Troubleshooting should examine the original message, both PID segments, identity relationship history, acknowledgment responses, and destination reconciliation rules. Accurate HL7 parsing and data mapping helps reduce these problems.

Existing Patient Relationship Cannot Be Found

The receiving application may not recognize the relationship identified by the two PID-3 values. Verify both identifiers, their assigning authorities, and the destination's current identity graph.

Only One PID Segment Is Read

A transformer written for single-patient events may read only the first PID, or look for an MRG segment that A37 does not contain. Validate that both PID segments are parsed and that identifier components match the agreed HL7 implementation guide.

A37 Is Mistaken for a Merge Event

A37 communicates unlinking, not merging. Mapping it to A40 or another merge operation can create additional incorrect identity associations instead of removing the intended relationship.

Unlinking Affects the Wrong Clinical Records

An incorrect identity relationship may involve encounters, orders, or results. The destination must determine which records belong to each patient through an authorized reconciliation process.

Duplicate or Out-of-Sequence Unlink Notifications

Repeated or delayed A37 messages may arrive after the relationship has already changed. Apply idempotency checks and inspect the current identity state before processing.

HL7 ADT A37 vs A34, A40, A43, and A47

HL7 Version 2 includes separate patient administration events for identity linking, merging, identifier changes, and unlinking. A37 communicates the removal of a patient identity linkage and is the direct counterpart of A24, which creates the link. Legacy A34 and later A40 events concern patient identifier merging.

A43 addresses moving patient information under a patient identifier list, while A47 concerns changing a patient identifier list. Although these events may contain similar patient identifiers, their intended effects are different. Receiving applications must apply event-specific processing rules.

A37 vs A34: Unlink and Legacy Merge

A34 historically communicates a patient ID merge, while A37 communicates an unlink operation. The destination must not treat unlinking as another merge or automatically undo every historical merge effect.

A37 vs A40: Removing and Combining Relationships

A40 merges patient identifiers, while A37 unlinks patient information. These operations affect identity relationships in opposite ways but are not necessarily exact reversals of each other.

A37 vs A43: Unlinking and Moving Patient Information

A43 concerns moving patient information between identifiers. A37 concerns unlinking an identity relationship. Moving clinical records requires additional validation beyond removing an identifier association.

A37 vs A47: Unlinking and Changing Identifiers

A47 changes patient identifiers under its supported workflow. A37 removes an identity linkage. Changing an identifier does not automatically require unlinking two patient records.

Best Practices for Reliable HL7 A37 Integration

Reliable HL7 A37 integration requires accurate identity matching, controlled authorization, and careful preservation of clinical information. Healthcare organizations should document which system is authoritative for patient identity relationships and which applications maintain downstream identity associations.

Interfaces must validate both patient identifiers, including their issuing domains, before unlinking. They should also account for duplicate messages, delayed events, and identity relationships that have already changed. Because incorrect unlinking can affect patient safety and clinical data access, audit records and reconciliation procedures are essential.

Verify Both Patient Identities Before Unlinking

Confirm that both identifiers exist and that the relationship being removed is the intended one. Reject ambiguous requests and mismatched identifier domains.

Require an Authorized Identity Reconciliation Decision

Only process unlink operations approved by the designated identity management workflow. A technically valid HL7 message should not independently authorize a high-impact identity change.

Preserve Clinical Records and Their Ownership

Do not automatically delete, duplicate, or redistribute clinical records during unlinking. Use the destination's approved reconciliation procedures to preserve accurate patient-record associations.

Prevent Duplicate and Out-of-Sequence Processing

Use message control identifiers, timestamps, and current relationship state to avoid repeated unlink operations or older notifications overriding more recent identity corrections.

Maintain Audit Records and Exception Monitoring

Record both patient identifiers, the affected relationship, source event, authorization, and processing outcome. Monitor rejected messages and unresolved downstream inconsistencies.

Frequently Asked Questions About HL7 ADT A37 Messages

HL7 A37 integration raises questions about patient identity unlinking, identifier relationships, and differences between unlink, merge, and change events. Healthcare developers need to understand which patient identifiers are involved, how the existing relationship is identified, and why unlinking must not automatically delete or redistribute clinical records. These considerations become especially important when an enterprise master patient index coordinates patient identities across several applications. The following answers address common technical questions using HL7 Version 2 conventions. Actual requirements depend on the supported version and implementation profile.

Need Help With HL7 ADT A37 Integration?

Accurate patient identity management helps healthcare organizations maintain reliable clinical information across EHRs, registration systems, and enterprise master patient indexes. Taction Software supports HL7 interface development, Mirth Connect configuration, patient identity reconciliation, and healthcare application integration.

Our engineers can help organizations implement A37 unlink workflows, validate patient identifier relationships, manage exceptions, and establish dependable acknowledgment and monitoring procedures. Whether you are connecting an EMPI to an EHR or improving existing ADT interfaces, controlled identity reconciliation helps protect the integrity of patient information.

Custom HL7 Patient Identity Interfaces

We develop HL7 A37 interfaces based on source and destination requirements, including patient matching, relationship validation, unlink processing, and acknowledgment handling.

Mirth Connect Channel Development

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

EHR and Enterprise Master Patient Index Integration

We help organizations connect EHRs, registration platforms, and enterprise master patient indexes through reliable HL7 messaging and approved identity reconciliation workflows.

Production Monitoring and Support

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

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