The HL7 ADT A39 message is a patient administration event used to communicate the merging of two patient IDs belonging to the same person. Officially called ADT A39: Merge Person - Patient ID, this event supports legacy healthcare interfaces that maintain patient identifiers in PID-2. The message identifies the correct surviving patient ID and the previous incorrect ID that must be merged.
A39 is retained for backward compatibility, and HL7 recommends A40 for newer patient identifier list merges. This guide covers A39 message structure, PID and MRG mapping, examples, Mirth Connect integration, acknowledgments, troubleshooting, and implementation best practices.
What Is an HL7 ADT A39 Message?
An HL7 ADT A39 message communicates a patient ID merge when records for the same person were incorrectly maintained under two different identifiers. The receiving application uses the message to identify which patient ID survives and which previous ID should no longer be used for future transactions.
A39 specifically concerns the legacy PID-2 Patient ID field. It differs from A40, which uses the modern patient identifier list in PID-3. Because incorrect patient merges can affect clinical records, identity reconciliation, and patient safety, receiving systems must validate merge direction and identifier ownership. See the HL7 ADT messages guide for the full event family.
Purpose of the HL7 A39 Event
A39 notifies connected systems that two patient IDs have been consolidated into one. It helps synchronize patient identity changes across legacy registration, EHR, and clinical applications.
When Is an ADT A39 Message Generated?
An A39 message may be generated when a legacy patient administration system identifies duplicate patient IDs and completes an authorized merge into the correct surviving patient record.
Which Healthcare Systems Receive A39 Messages?
Legacy EHRs, patient registration applications, master patient indexes, laboratory systems, radiology platforms, and health information exchanges may receive A39 notifications when their interfaces support PID-2-based merges.
Why A39 Is Retained for Backward Compatibility
HL7 retained A39 for older implementations using PID-2. Since HL7 v2.3.1, A40 has been the recommended event for merging patient identifier lists.
Why Accurate A39 Processing Matters
An incorrect merge can associate medical records with the wrong person. The destination must verify both identifiers, their assigning authorities, and the intended surviving identity before processing.
HL7 ADT A39 Message Structure and Segments
In HL7 Version 2.5, A39 uses the ADT_A39 message structure. Its required components include MSH, EVN, and a repeating patient group containing PID and MRG. PD1 and PV1 are optional within each patient group, and SFT is optional. The repeating group allows the message to represent multiple patient merge operations.
The PID segment contains the correct surviving patient ID, while MRG identifies the previous incorrect patient ID. For A39, the defining fields are PID-2 and MRG-4, not PID-3 and MRG-1.
HL7 ADT A39 Message Structure
MSH
[{SFT}]
EVN
{
PID
[PD1]
MRG
[PV1]
}The patient group repeats according to the HL7 v2.5 message structure.
MSH Segment: Message Header
MSH identifies the sender, receiver, timestamp, message control ID, and HL7 version. MSH-9 identifies the event as ADT^A39^ADT_A39.
EVN Segment: Event Information
EVN records administrative information about the merge, including the recorded event timestamp. It supports audit trails and processing history.
PID Segment: Correct Target Patient ID
PID-2 identifies the correct surviving patient ID. This is the target identifier into which the incorrect source ID is merged.
MRG Segment: Previous Patient ID
MRG-4 identifies the incorrect source patient ID. The receiving application must merge this identifier into the correct target specified in PID-2.
Optional PD1 and PV1 Segments
PD1 can carry additional patient demographic information, while PV1 can provide visit context. Neither replaces the required patient merge identifiers.
HL7 ADT A39 Message Example With Field Explanation
Consider a hospital that maintains patient identifiers in an older registration application. The same patient has accidentally been assigned two IDs. The correct patient ID is PAT390001, while the duplicate ID is PAT390099. After the registration team verifies that both identifiers belong to the same person, the source system performs an authorized merge. The registration application generates an A39 notification instructing connected systems to associate the previous ID with the correct surviving patient ID.
Complete HL7 ADT A39 Sample Message
MSH|^~\&|REGISTRATION|HOSPITAL|EHR|MAIN|20261022153000||ADT^A39^ADT_A39|MSG39001|P|2.5
EVN|A39|20261022153000
PID|1|PAT390001|||WILSON^EMILY||19880215|F
MRG||||PAT390099All patient information is fictional. In this example, PAT390001 is the correct target patient ID in PID-2. PAT390099 is the incorrect source patient ID in MRG-4.
Incorrect source · MRG-4
PAT390099
Prior Patient ID
Correct target · PID-2
PAT390001
Patient ID
Merge previous ID into correct ID.
Explore each segment and its key fields:
Illustrative ADT^A39 — HL7 v2.5 (fictional data)
Select a segment to see what it carries
MSH — Message Header
RequiredADT^A39^ADT_A39 identifies the patient ID merge event and its message structure. Receiving systems should validate all three components where supported.
| Field | Meaning | Value in this message |
|---|---|---|
| MSH-3 | Sending application | REGISTRATION |
| MSH-5 | Receiving application | EHR |
| MSH-7 | Message creation time | 20261022153000 |
| MSH-9 | Message type | ADT^A39^ADT_A39 |
| MSH-10 | Message control ID | MSG39001 |
| MSH-12 | HL7 version | 2.5 |
MSH-9: Message Type and Trigger Event
ADT^A39^ADT_A39 identifies the patient ID merge event and its message structure. Receiving systems should validate all three components where supported.
EVN-2: Recorded Date and Time
EVN-2 records when the merge event was entered. This timestamp helps downstream systems reconstruct the administrative history of patient identity changes.
PID-2: Correct Target Patient ID
PID-2 contains PAT390001, the surviving patient ID. It identifies the correct target patient record after the merge.
MRG-4: Incorrect Source Patient ID
MRG-4 contains PAT390099, the previous patient ID. The destination must not reverse the source and target values.
Why PID-3 and MRG-1 Are Different
PID-3 and MRG-1 are central to modern A40 merges. Legacy A39 specifically identifies the merge using PID-2 and MRG-4, so mapping these events identically is unsafe.
Important HL7 ADT A39 Fields and Mapping
An A39 message must distinguish the correct target patient ID from the incorrect source patient ID. This distinction determines which identifier remains active and which identifier is retired from future transactions. The interface should also validate the identifier domains, patient demographics, event history, and authorization behind the merge.
Unlike newer patient merge events, A39 relies on legacy fields that may not be populated in modern EHR implementations. Mapping those fields incorrectly can cause records to be linked to the wrong patient. Our HL7 parsing and data mapping team can document legacy identifier mapping across every receiving system.
| HL7 Field | Description | Integration Purpose |
|---|---|---|
| MSH-3 | Sending Application | Identify authorized source |
| MSH-4 | Sending Facility | Identify originating facility |
| MSH-9 | ADT^A39^ADT_A39 | Identify merge event |
| MSH-10 | Message Control ID | Deduplication and tracking |
| MSH-12 | HL7 Version | Validate message format |
| EVN-2 | Recorded Date/Time | Record merge timestamp |
| PID-2 | Patient ID | Correct target identifier |
| PID-3 | Patient Identifier List | Additional identity context |
| PID-5 | Patient Name | Demographic context |
| MRG-4 | Prior Patient ID | Incorrect source identifier |
PID-2: Correct Target Identifier
PID-2 identifies the surviving patient ID. The receiving system should verify that this identifier belongs to the intended patient before updating identity relationships.
MRG-4: Previous Patient Identifier
MRG-4 identifies the patient ID that is being merged into the correct target. The previous identifier should remain traceable through an appropriate historical or audit mechanism.
PID-3: Patient Identifier List
PID-3 may contain additional identifiers according to the interface profile. However, it does not replace PID-2 as the defining target field for the legacy A39 event.
MSH-10: Message Control Identifier
MSH-10 allows the receiving application to correlate acknowledgments and identify repeated messages. It helps prevent a merge from being applied multiple times.
EVN-2: Recorded Event Timestamp
EVN-2 provides the administrative event timestamp. It supports merge history, troubleshooting, and reconciliation when messages are delivered out of sequence.
How HL7 ADT A39 Patient Merge Workflows Operate
An A39 workflow starts when an authorized patient identity management process confirms that two patient IDs refer to the same person. The registration system identifies the correct target and incorrect source. It then generates an A39 notification containing the identifiers in PID-2 and MRG-4.
An integration engine validates the message and forwards it to participating applications. Each receiving system processes the merge using its approved identity management functions and preserves historical references as required.
Step 1: Identify Duplicate Patient IDs
The registration or master patient index team investigates duplicate records using verified demographic, clinical, and administrative information.
Step 2: Confirm the Correct Target ID
The team selects the patient ID that will remain active. The source identifier must be clearly distinguished from the target identifier.
Step 3: Generate the A39 Message
The source application creates an A39 message with the correct target in PID-2 and the previous ID in MRG-4.
Step 4: Validate and Route the Merge
The integration engine checks the message structure, required identifiers, sending system, and applicable validation rules before forwarding the merge.
Step 5: Reconcile Downstream Records
Receiving applications update supported identity relationships and maintain appropriate historical references. Failed or partially completed merges require investigation.
How to Implement HL7 ADT A39 Using Mirth Connect
Mirth Connect can receive legacy A39 messages, extract the correct and previous patient IDs, and route the merge to approved applications. Because the message changes patient identity relationships, it should not be treated as a routine demographic update.
The implementation must validate PID-2 and MRG-4, prevent reversed merge direction, and handle repeated patient groups where supported. New interfaces should consider A40 rather than adopting A39 unless backward compatibility is required.
Configure the Mirth Connect Source Connector
Create an MLLP Listener using HL7 v2.x inbound data type. Configure trusted senders, secure transport, acknowledgments, and appropriate message access controls.
Filter HL7 ADT A39 Messages
var type =
msg['MSH']['MSH.9']['MSH.9.1'].toString();
var event =
msg['MSH']['MSH.9']['MSH.9.2'].toString();
var structure =
msg['MSH']['MSH.9']['MSH.9.3'].toString();
var version =
msg['MSH']['MSH.12']['MSH.12.1'].toString();
return type === 'ADT' &&
event === 'A39' &&
structure === 'ADT_A39' &&
version === '2.5';Extract Correct and Previous Patient IDs
The following transformer illustrates extraction for a single patient merge group.
function component(segment, field, number) {
if (!segment ||
segment[field].length() === 0) {
return '';
}
return segment[field][0]
[field + '.' + number]
.toString().trim();
}
var msh = msg['MSH'];
var pid = msg['PID'];
var mrg = msg['MRG'];
var event =
component(msh, 'MSH.9', 2);
if (event !== 'A39') {
throw new Error('Unexpected ADT event');
}
if (pid.length() === 0 ||
mrg.length() === 0) {
throw new Error(
'Missing PID or MRG segment'
);
}
var targetPatientId =
component(pid, 'PID.2', 1);
var sourcePatientId =
component(mrg, 'MRG.4', 1);
var controlId =
component(msh, 'MSH.10', 1);
if (!targetPatientId ||
!sourcePatientId ||
!controlId) {
throw new Error(
'Missing required merge identifiers'
);
}
if (targetPatientId === sourcePatientId) {
throw new Error(
'Source and target IDs are identical'
);
}
var mergeEvent = {
eventType: 'A39',
operation: 'mergeLegacyPatientId',
correctTargetPatientId:
targetPatientId,
incorrectSourcePatientId:
sourcePatientId,
messageControlId:
controlId,
processingStatus:
'pending_identity_validation'
};
channelMap.put(
'legacyPatientMerge',
JSON.stringify(mergeEvent)
);This example is for a single merge group and an agreed identifier domain. Production implementations must correctly process repeating patient groups and validate full identifier components, assigning authorities, and patient identity evidence.
Transform A39 Into a Controlled Merge Request
var event = JSON.parse(
channelMap.get('legacyPatientMerge')
);
var request = {
operation: 'validatePatientIdMerge',
sourcePatientId:
event.incorrectSourcePatientId,
targetPatientId:
event.correctTargetPatientId,
approvalRequired: true,
sourceMessageId:
event.messageControlId
};
channelMap.put(
'jsonPayload',
JSON.stringify(request)
);This JSON is an illustrative application payload, not a standardized HL7 or FHIR API. The receiving system must approve and validate the identity relationship before applying the merge.
Handle Repeating Patient Groups
HL7 A39 supports repeating patient groups. Production processing should iterate through each PID/MRG group and preserve the relationship between its source and target identifiers.
Configure Merge Monitoring and Audit Logging
Monitor invalid identifiers, duplicate messages, rejected merges, and unresolved downstream records. Preserve historical references and restrict access to sensitive identity information.
HL7 ADT A39 ACK Message Examples and Error Handling
An HL7 acknowledgment communicates whether the receiving application accepted or rejected the A39 message. The ACK generally includes MSH and MSA segments, with ERR providing additional diagnostic information when processing fails. In original acknowledgment mode, AA indicates application acceptance, AE indicates an application error, and AR indicates rejection.
For patient merges, acknowledgment handling should be supplemented with application-level reconciliation because accepting the message does not necessarily mean every downstream record has been merged.
Successful A39 ACK: AA
MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022153001||ACK^A39^ACK|ACK39001|P|2.5
MSA|AA|MSG39001Application Error ACK: AE
MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022153002||ACK^A39^ACK|ACK39002|P|2.5
MSA|AE|MSG39001
ERR|||204^Unknown Key Identifier^HL70357|EApplication Rejection ACK: AR
MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022153003||ACK^A39^ACK|ACK39003|P|2.5
MSA|AR|MSG39001Correlate ACKs With Merge Requests
MSA-2 should reference the original MSH-10 message control ID. Maintain separate records of the actual merge processing outcome.
Handle Duplicate and Failed Messages
Before retrying an A39 notification, determine whether the destination already processed the merge. Avoid repeated or conflicting identity changes.
Common HL7 ADT A39 Integration Errors and Troubleshooting
A39 integration errors often occur because legacy patient ID fields are no longer used consistently across modern healthcare systems. The most important risks include incorrect source-to-target mapping, missing MRG-4 values, unsupported message structures, and incomplete downstream reconciliation.
An interface may also incorrectly treat A39 as A40 and extract PID-3 and MRG-1 instead of PID-2 and MRG-4. Troubleshooting should begin with the agreed HL7 version, the original merge decision, and the actual identifiers contained in the message. Our HL7 interface messaging team can help trace merge failures across downstream systems.
PID-2 and MRG-4 Are Reversed
The receiving application may accidentally treat the incorrect source ID as the correct target. Verify merge direction before processing.
PID-2 Is Missing
Some modern applications no longer populate PID-2. A legacy A39 interface cannot reliably identify the target without the required value.
MRG-4 Is Missing or Incorrect
Without MRG-4, the receiving system cannot identify the previous patient ID. Reject or quarantine the message for investigation.
A39 Is Processed Using A40 Mapping
A40 uses PID-3 and MRG-1 for the patient identifier list merge. Applying these fields to A39 can produce incorrect results.
Repeated Patient Groups Are Ignored
An A39 message may contain multiple patient groups. A transformer that processes only the first PID/MRG pair can leave other merges incomplete.
HL7 ADT A39 vs A40, A34, A36, and A47
HL7 defines several patient identity events that may appear similar but serve different purposes. A39 is a legacy merge event based on the Patient ID field. A40 is the preferred event for merging patient identifier lists. A34 and A36 are also legacy merge events, while A47 changes a patient identifier list without representing the same merge operation. Understanding these distinctions prevents incorrect transformations and patient identity updates.
| HL7 Event | Meaning | Primary Fields |
|---|---|---|
| A39 | Merge Person - Patient ID | PID-2, MRG-4 |
| A40 | Merge Patient - Patient Identifier List | PID-3, MRG-1 |
| A34 | Merge Patient Information - Patient ID Only | Legacy merge fields |
| A36 | Merge Patient ID and Account Number | Patient and account identifiers |
| A47 | Change Patient Identifier List | PID-3, MRG-1 |
A39 vs A40: Legacy and Modern Patient Merge
A39 merges legacy patient IDs using PID-2 and MRG-4. A40 merges patient identifier lists using PID-3 and MRG-1 and is preferred for modern integrations.
A39 vs A34: Different Legacy Merge Events
Both A39 and A34 are retained for backward compatibility. Their intended identifier scope and message structure differ, so they require separate interface mappings.
A39 vs A36: Patient ID and Account Merge
A39 focuses on a patient ID merge. A36 combines patient identifier and account number merging in a legacy workflow.
A39 vs A47: Merge and Identifier Change
A39 consolidates records previously maintained under two patient IDs. A47 changes a patient identifier list. A change does not necessarily imply that two patient records were merged.
Best Practices for Reliable HL7 A39 Integration
A39 interfaces should be maintained with clear documentation of legacy identifier semantics and merge direction. Healthcare organizations should verify the identity relationship before allowing any merge to affect clinical records. Integration teams should also confirm whether receiving systems still support PID-2 and MRG-4 or require translation into a newer interface workflow.
Testing should cover missing identifiers, duplicate notifications, reversed mappings, repeated patient groups, and partial downstream failures.
Validate Patient Identity Before Merging
Confirm that the source and target identifiers belong to the same person using an approved identity verification process. Do not rely solely on matching names.
Preserve Source and Target Direction
Always identify the correct target from PID-2 and the incorrect source from MRG-4. Prevent reversed merges through explicit validation rules.
Support Repeating Patient Groups
Process each patient group independently and preserve the correct PID/MRG pairing. Do not assume that every A39 message contains only one merge.
Maintain Historical Identifiers
Preserve previous identifiers and merge history where supported. This allows historical records and external references to remain traceable.
Prefer A40 for New Integrations
Avoid introducing A39 into new systems unless required for compatibility. Use A40 when both applications support patient identifier list merging.
Frequently Asked Questions About HL7 ADT A39 Messages
What does A39 mean in HL7?
A39 is an HL7 ADT event called Merge Person - Patient ID. It communicates that records maintained under two different legacy patient IDs have been merged into one correct patient identity. A39 is retained for backward compatibility.
What is the difference between HL7 A39 and A40?
A39 uses PID-2 for the correct patient ID and MRG-4 for the previous patient ID. A40 uses PID-3 and MRG-1 to merge patient identifier lists and is the recommended event for newer integrations.
Which HL7 fields are important in A39?
The defining fields are PID-2, which identifies the correct target patient ID, and MRG-4, which identifies the incorrect source patient ID. MSH-9 and MSH-10 identify and track the message.
What is the HL7 A39 message structure?
In HL7 Version 2.5, A39 uses the ADT_A39 structure. It includes MSH, EVN, and repeating patient groups containing PID and MRG, with optional PD1 and PV1 segments.
Can Mirth Connect process HL7 A39 messages?
Yes. Mirth Connect can receive, validate, transform, and route A39 messages. Implementations should validate PID-2 and MRG-4, support repeating patient groups, and preserve merge audit history.
Is HL7 A39 deprecated?
A39 is retained for backward compatibility rather than recommended for new implementations. Since HL7 Version 2.3.1, A40 has been the preferred event for patient identifier list merges.
Need Help With HL7 ADT A39 Integration?
Legacy patient ID merges require accurate coordination between EHRs, registration applications, master patient indexes, and other clinical systems. Taction Software supports HL7 interface development, Mirth Connect implementation, patient identity reconciliation, and modernization of legacy healthcare interfaces.
Legacy HL7 Patient Merge Interfaces
We help healthcare organizations maintain A39 interfaces, validate source-to-target mappings, and preserve historical patient identifiers.
Mirth Connect Development and Integration
Our engineers develop Mirth Connect channels for legacy patient ID merges, including validation, transformations, acknowledgments, secure routing, and monitoring.
EHR and Master Patient Index Integration
We support integration between EHRs, patient registration platforms, master patient indexes, and clinical applications using approved identity management workflows.
Migration From A39 to A40
We help assess legacy A39 integrations and plan transitions to A40 where supported by the participating applications.
Need help with HL7 patient ID merge integration? Explore HL7 Integration and Taction Software's EHR integration services to discuss your requirements.