HL7 ADT Messages:
The Complete Reference (A01-A62)

ADT is the nervous system of a hospital information architecture. Every other integration — labs, radiology, pharmacy, billing, bed management, dietary, the patient portal, the clinical data warehouse — reacts to events that flow through the ADT feed. Get ADT right and everything downstream has a chance. Get it wrong and every system disagrees about who the patient is, where they are, and whether they are still in the hospital.

This reference covers every HL7 v2.5 ADT trigger event from A01 through A62, explains each of the core segments (MSH, EVN, PID, PV1, NK1, ROL) with real field-level detail, and walks through the Mirth Connect channel patterns we deploy in production. For broader context, start with our HL7 integration guide and our HL7 v2 message structure explainer.

If you need production help with an ADT feed — building a new one, fixing one that drifted, or bridging v2 ADT to FHIR Patient/Encounter — our Mirth Connect helpdesk runs interfaces for more than 100 US healthcare organizations. Skip to section 10 if you are looking for Mirth channel specifics.

1. What ADT Is (and Why It Matters)

ADT stands for Admission, Discharge, and Transfer. In HL7 terms, an ADT message is one of the ADT^Annn event-triggered messages — where Annn is a specific trigger event like A01 (admit), A03 (discharge), or A08 (update).

ADT messages carry three broad categories of information:

• Patient identity and demographics — who the patient is, how to contact them, their insurance, their next of kin.
• Visit context — what kind of visit (inpatient, ER, outpatient, observation), which location (unit, room, bed), which providers, what visit number.
• State changes — the triggering event (the patient got admitted, transferred, discharged, merged, updated).

ADT volume dominates the rest of the HL7 traffic in most hospitals. A medium-sized US hospital typically emits 50,000 to 200,000 ADT messages per day across its registration, bed management, and clinical systems. Every other interface consumes some subset of ADT to stay aligned with patient state. If you need a refresher on the underlying v2 anatomy, see HL7 v2 message structure explained.

ADT consumers — who is listening

• Ancillary systems (lab, radiology, pharmacy) — need current visit and location for routing orders and results.
• Billing and revenue cycle — need discharges to drop bills and merges to avoid duplicate accounts.
• Bed management — need transfers (A02) and discharges (A03) to keep availability accurate.
• Clinical data warehouse / analytics — needs demographic changes for longitudinal patient views.
• Patient portal — needs registration events so portal accounts can be created.
• Health information exchange (HIE) — relays ADT to regional partners for continuity of care.
• Downstream integrations to claims scrubbing, quality reporting, population health, care coordination.

2. Trigger Events Master List (A01-A62)

Here is the complete list of ADT trigger events defined through HL7 v2.5, with frequency indicators based on what we see in production at US hospitals. "Very High" means you will see it within minutes of connecting; "Legacy" means it has been replaced by a newer trigger.

Not every ADT trigger is in active use. The ones you will actually encounter in 90% of US hospital integrations are: A01, A02, A03, A04, A08, A11, A12, A13, A28, A31, and A40. Build your receiver to handle those well, and implement the long tail on an as-needed basis.

3. Core Segments: MSH, EVN, PID, PV1, NK1, ROL

Every ADT message is made of the same handful of segments. Master these and you understand 95% of ADT.

MSH - Message Header

Always the first segment. Defines encoding characters, sender/receiver, message type, timestamp, and control ID.

MSH|^~\&|EPIC|HOSPITAL|MIRTH|INTEGRATION|20260421143022||ADT^A01^ADT_A01|000123456|P|2.5

• MSH-1 Field separator (|).
• MSH-2 Encoding characters (^~\&).
• MSH-3 Sending application (EPIC).
• MSH-4 Sending facility (HOSPITAL).
• MSH-5 Receiving application (MIRTH).
• MSH-6 Receiving facility (INTEGRATION).
• MSH-7 Date/time of message (YYYYMMDDHHMMSS).
• MSH-9 Message type (ADT^A01^ADT_A01).
• MSH-10 Message control ID (unique per message, used for ACK correlation).
• MSH-11 Processing ID (P=Production, T=Test, D=Debug).
• MSH-12 Version ID (2.3, 2.4, 2.5, 2.5.1, 2.7).

EVN - Event Type

Carries event-specific metadata: when the event actually happened (vs when the message was sent), who triggered it, and the reason.

EVN|A01|20260421143000|||JONES^MARY^^^^RN^^^^^^^12345

• EVN-1 Event type code (usually matches MSH-9 trigger).
• EVN-2 Recorded date/time.
• EVN-4 Event reason code.
• EVN-5 Operator ID (who performed the event).
• EVN-6 Event occurred (the true clinical time of the event, often different from recorded time).

PID - Patient Identification

The patient identity segment. Critical fields for MPI linking, billing, and downstream matching.

PID|1||MRN12345^^^HOSP^MR~SSN123-45-6789^^^USA^SS||DOE^JANE^MARIE^^MS^^L|SMITH^JANE^MARIE^^^^M|19850412|F||2106-3^White^HL70005|123 MAIN ST^^SEATTLE^WA^98101^USA^H||^PRN^PH^^^206^5551234|^WPN^PH^^^206^5559876|en^English^HL70296|M^Married^HL70002|CHR^Christian^HL70006|ACC00987654|123-45-6789|||N^Not Hispanic or Latino^HL70189||||||||||N

• PID-3 Patient identifier list — this is where the MRN lives. It repeats (separated by ~) so multiple identifier types (MRN, SSN, Medicaid ID, HIE ID) can coexist. This is the single most important field in the ADT world.
• PID-5 Patient name. Components: family^given^middle^suffix^prefix^degree^name-type-code. L = Legal name.
• PID-6 Mother's maiden name.
• PID-7 Date/time of birth.
• PID-8 Administrative sex (M, F, O, U, A, N).
• PID-10 Race (HL7 table 0005 or CDC race codes).
• PID-11 Patient address.
• PID-13 Home phone.
• PID-14 Work phone.
• PID-18 Patient account number.
• PID-19 SSN (many facilities suppress this).
• PID-22 Ethnic group.
• PID-29 Patient death date/time (populated on deceased patients).
• PID-30 Patient death indicator.

PV1 - Patient Visit

The visit-level segment. Present on A01, A02, A03, A04, A08 and many others — anywhere there is a visit context.

PV1|1|I|7N^701^A^MAINHOSP^^^WEST^7|E|||1234567890^SMITH^JOHN^A^^^MD^^^^^^NPI|||MED||||1|||1234567890^SMITH^JOHN^A^^^MD^^^^^^NPI|INP|VN00045678|COMM|||||||||||||||||HOSP|ACC|||20260421143000

• PV1-2 Patient class (I=Inpatient, O=Outpatient, E=Emergency, P=Preadmit, R=Recurring, B=Obstetrics, C=Commercial Account, N=Not Applicable, U=Unknown).
• PV1-3 Assigned patient location — the bed. Format: point-of-care^room^bed^facility^status^person-location-type^building^floor.
• PV1-4 Admission type (A=Accident, E=Emergency, L=Labor/Delivery, R=Routine, N=Newborn, U=Urgent, C=Elective).
• PV1-6 Prior patient location (set on transfers).
• PV1-7 Attending doctor.
• PV1-8 Referring doctor.
• PV1-9 Consulting doctor (repeats).
• PV1-10 Hospital service code.
• PV1-14 Admit source.
• PV1-17 Admitting doctor.
• PV1-19 Visit number — THE critical visit identifier for all downstream correlation.
• PV1-36 Discharge disposition (populated on A03).
• PV1-44 Admit date/time.
• PV1-45 Discharge date/time.

NK1 - Next of Kin / Associated Parties

Repeating segment. Contains emergency contacts, guarantors, spouses, guardians, employers, and anyone else with a defined relationship to the patient.

NK1|1|DOE^JOHN^A|SPO^SPOUSE^HL70063|123 MAIN ST^^SEATTLE^WA^98101|^PRN^PH^^^206^5551234|^WPN^PH^^^206^5557890|N^Next of Kin^HL70131||||19700815|||||||||||||||||||||||||||JOHN.DOE@EMAIL.COM
NK1|2|DOE^ROBERT^S|FTH^FATHER^HL70063|456 OAK AVE^^TACOMA^WA^98402|^PRN^PH^^^253^5553456||C^Emergency Contact^HL70131

ROL - Role

Optional, repeating. Associates a person with a role (attending, admitting, PCP, case manager). More granular than PV1's provider fields.

ROL|1|AD|AT^Attending^HL70443|1234567890^SMITH^JOHN^A^^^MD^^^^^^NPI|20260421143000
ROL|2|AD|PP^Primary Care Provider^HL70443|2345678901^JOHNSON^LISA^B^^^MD^^^^^^NPI

4. A01 - Admit/Visit Notification

A01 creates an inpatient visit. It is sent when a patient is formally admitted to the hospital — bed assigned, visit number generated, clock starts ticking.

A01 segment structure

• MSH — required
• EVN — required
• PID — required
• PD1 — optional (patient additional demographics)
• ROL — optional, repeating
• NK1 — optional, repeating
• PV1 — required
• PV2 — optional
• DB1 — optional (disability)
• OBX — optional, repeating (height/weight/smoking/etc.)
• AL1 — optional, repeating (allergies)
• DG1 — optional, repeating (diagnosis)
• DRG — optional
• PR1 — optional, repeating (procedures)
• GT1 — optional (guarantor)
• IN1/IN2/IN3 — optional, repeating (insurance)
• ACC — optional (accident)
• UB1/UB2 — optional

Full A01 sample

MSH|^~\&|EPIC|GENERAL_HOSP|MIRTH|INTEGRATION|20260421143022||ADT^A01^ADT_A01|MSG0001234567|P|2.5
EVN|A01|20260421143000|||JONES^MARY^^^^RN^^^^^^^98765
PID|1||MRN12345^^^GENERAL_HOSP^MR||DOE^JANE^MARIE^^MS^^L||19850412|F||2106-3^White^HL70005|123 MAIN ST^^SEATTLE^WA^98101^USA^H||^PRN^PH^^^206^5551234|^WPN^PH^^^206^5559876|en^English^HL70296|M^Married^HL70002|CHR|ACC00987654|123-45-6789|||N^Not Hispanic or Latino^HL70189
PD1|||GENERAL_HOSP^^HOSP1|1234567890^JOHNSON^LISA^B^^^MD
NK1|1|DOE^JOHN^A|SPO^SPOUSE^HL70063|123 MAIN ST^^SEATTLE^WA^98101|^PRN^PH^^^206^5551234||N
PV1|1|I|7N^701^A^GENERAL_HOSP^^^WEST^7|E|||1234567890^SMITH^JOHN^A^^^MD^^^^^^NPI|||MED||||1|||1234567890^SMITH^JOHN^A^^^MD^^^^^^NPI|INP|VN00045678|COMM|||||||||||||||||HOSP|||20260421143000
PV2||EM|CHEST PAIN - R/O MI|||||||||||||||||||||N|||||||N||||||N
AL1|1|DA|PEN^Penicillin^HL70131|SV^Severe|Rash and hives|20200101
AL1|2|FA|EGG^Eggs^HL70131|MO^Moderate|Hives
DG1|1||I21.9^Acute myocardial infarction, unspecified^I10|ACUTE MI||A|||||||||1
GT1|1|1|DOE^JANE^MARIE|||123 MAIN ST^^SEATTLE^WA^98101|^PRN^PH^^^206^5551234|||SELF||||||||F
IN1|1|BCBS|BCBS001|BLUECROSS BLUESHIELD OF WA|P O BOX 12345^^SEATTLE^WA^98101|||GRP001234|EMPLOYER INC|||20260101|20261231|||DOE^JANE^MARIE|SEL^Self^HL70063|19850412|123 MAIN ST^^SEATTLE^WA^98101|||||||||||||||XYZ987654321

What to actually do with an A01 downstream

• Upsert the patient in the MPI using PID-3 as the primary key.
• Create the visit keyed on PV1-19 (visit number).
• Assign bed per PV1-3.
• Store allergies (AL1) and diagnoses (DG1).
• Propagate to lab/rad so they can route future orders.

5. A03 - Discharge/End Visit

A03 terminates the visit. PV1-45 gets a discharge timestamp, PV1-36 gets a discharge disposition, and bed management marks the bed dirty.

MSH|^~\&|EPIC|GENERAL_HOSP|MIRTH|INTEGRATION|20260424091500||ADT^A03^ADT_A03|MSG0002345678|P|2.5
EVN|A03|20260424091000|||JONES^MARY^^^^RN
PID|1||MRN12345^^^GENERAL_HOSP^MR||DOE^JANE^MARIE^^MS^^L||19850412|F||2106-3|123 MAIN ST^^SEATTLE^WA^98101
PV1|1|I|7N^701^A^GENERAL_HOSP|E|||1234567890^SMITH^JOHN^A^^^MD||||||||||||VN00045678|COMM|||||||||||||||||HOSP|01^Discharged to home^HL70112|||20260421143000|20260424091000
DG1|1||I21.9^Acute myocardial infarction, unspecified^I10||A
DG1|2||E11.9^Type 2 diabetes mellitus without complications^I10||A
PR1|1||9328^Coronary artery bypass graft^HCPCS|CABG x 3|20260422
OBX|1|NM|21612-7^Length of Stay^LN||3|d^day^UCUM|||||F

Discharge dispositions (PV1-36) to recognize

• 01 — Discharged to home or self care
• 02 — Discharged/transferred to another short-term general hospital
• 03 — Discharged/transferred to SNF
• 04 — Discharged/transferred to ICF
• 05 — Discharged/transferred to another type of institution
• 06 — Discharged/transferred to home under care of organized home health
• 07 — Left against medical advice
• 20 — Expired (patient died)
• 30 — Still patient
• 40-43 — Expired (specific location variants)
• 50 — Hospice - home
• 51 — Hospice - medical facility

6. A04 - Register a Patient

A04 registers an outpatient visit — ER, clinic, observation, day surgery. Structurally identical to A01 but semantically different: PV1-2 is O (outpatient) or E (emergency), not I.

MSH|^~\&|EPIC|GENERAL_HOSP|MIRTH|INTEGRATION|20260421081230||ADT^A04^ADT_A01|MSG0003456789|P|2.5
EVN|A04|20260421081200
PID|1||MRN98765^^^GENERAL_HOSP^MR||NGUYEN^LINH^T^^MS^^L||19920308|F||2028-9^Asian^HL70005|456 PINE ST^^BELLEVUE^WA^98005|||^PRN^PH^^^425^5554321
PV1|1|E|ED^E03^1^GENERAL_HOSP^^^MAIN^1|E|||3456789012^LEE^KEVIN^M^^^MD^^^^^^NPI||EMR||||1|||3456789012^LEE^KEVIN^M^^^MD||ED|VN00067890|SELF|||||||||||||||||||||20260421081200
PV2||EM|LACERATION - LEFT HAND|||||||||||||||||||||N
AL1|1|DA|NKA^No Known Allergies^HL70131
DG1|1||S61.402A^Unspecified open wound of left hand, initial encounter^I10||A

The classic A01 vs A04 error: EHR mis-configures an inpatient admission as A04 (or vice versa). Your bed management will show a patient who does not exist in the right state. Solution: validate PV1-2 against the expected patient class whenever you receive A01 or A04, and alert on mismatches.

7. A08 - Update Patient Information

A08 is the catch-all update event. Any material change to the patient's demographics, visit, insurance, diagnosis, or guarantor triggers an A08. Expect them to be frequent — every phone number correction, insurance verification, or name change generates one.

MSH|^~\&|EPIC|GENERAL_HOSP|MIRTH|INTEGRATION|20260421160400||ADT^A08^ADT_A01|MSG0004567890|P|2.5
EVN|A08|20260421160330|||RODRIGUEZ^CARLOS^^^^REG
PID|1||MRN12345^^^GENERAL_HOSP^MR||DOE^JANE^MARIE^^MS^^L||19850412|F||2106-3|456 CEDAR AVE^^SEATTLE^WA^98102^USA^H||^PRN^PH^^^206^5559999|^WPN^PH^^^206^5558888|en|M|CHR|ACC00987654|123-45-6789|||N
PV1|1|I|7N^701^A^GENERAL_HOSP|E|||1234567890^SMITH^JOHN^A^^^MD||||||||||||VN00045678|COMM
IN1|1|CIGNA|CIGNA001|CIGNA HEALTHCARE|P O BOX 55555^^HARTFORD^CT^06152|||GRP004567|EMPLOYER INC|||20260101|20261231||PPO|DOE^JANE^MARIE|SEL|19850412|456 CEDAR AVE^^SEATTLE^WA^98102|||||||||||||||ABC123456789

A08 processing strategy

• Full replace vs delta — most EHRs send the complete patient record on every A08, not just the changed fields. Design your downstream to accept full replace and compute the delta internally if auditing is needed.
• Order matters — if three A08s arrive for the same visit within seconds, processing them out of order means the final state is wrong. Use MSH-7 timestamps and per-visit queues.
• Insurance updates are separate — many EHRs send A08 for demographic changes and A31 for insurance changes. Read your spec.

8. A11/A12/A13 - Cancel Admit, Transfer, Discharge

Hospital registrars make mistakes. A11, A12, and A13 are the "undo" triggers. They undo an A01, A02, or A03 respectively.

A11 - Cancel Admit (undo A01)

MSH|^~\&|EPIC|GENERAL_HOSP|MIRTH|INTEGRATION|20260421151000||ADT^A11^ADT_A09|MSG0005678901|P|2.5
EVN|A11|20260421150945|20260421143000||JONES^MARY^^^^RN|20260421143000
PID|1||MRN12345^^^GENERAL_HOSP^MR||DOE^JANE^MARIE^^MS^^L||19850412|F
PV1|1|I|7N^701^A^GENERAL_HOSP|E|||1234567890^SMITH^JOHN^A^^^MD||||||||||||VN00045678

A12 - Cancel Transfer (undo A02)

MSH|^~\&|EPIC|GENERAL_HOSP|MIRTH|INTEGRATION|20260422103000||ADT^A12^ADT_A12|MSG0006789012|P|2.5
EVN|A12|20260422102930|20260422101500|||20260422101500
PID|1||MRN12345^^^GENERAL_HOSP^MR||DOE^JANE^MARIE^^MS^^L||19850412|F
PV1|1|I|7N^701^A^GENERAL_HOSP||||1234567890^SMITH^JOHN^A^^^MD|||||||||||ICU^I01^A^GENERAL_HOSP|VN00045678

A13 - Cancel Discharge (undo A03)

MSH|^~\&|EPIC|GENERAL_HOSP|MIRTH|INTEGRATION|20260424094500||ADT^A13^ADT_A01|MSG0007890123|P|2.5
EVN|A13|20260424094430|20260424091000|||20260424091000
PID|1||MRN12345^^^GENERAL_HOSP^MR||DOE^JANE^MARIE^^MS^^L||19850412|F
PV1|1|I|7N^701^A^GENERAL_HOSP|E|||1234567890^SMITH^JOHN^A^^^MD||||||||||||VN00045678|COMM|||||||||||||||||HOSP|||20260421143000

Operational tip: cancel messages arrive seconds to hours after the event being cancelled, occasionally days. Design downstream consumers to gracefully handle a late cancel that undoes billing work already in flight. Many integration problems resolve with better cancel handling.

9. A28/A31/A40 - Person Management & Merges

The person-management triggers operate on the MPI without a visit context.

A28 - Add Person Information

Adds a person to the MPI — typically from a registration system that creates patient records prior to any encounter.

MSH|^~\&|REG|GENERAL_HOSP|MIRTH|INTEGRATION|20260420140000||ADT^A28^ADT_A05|MSG0008901234|P|2.5
EVN|A28|20260420140000|||RODRIGUEZ^CARLOS^^^^REG
PID|1||MRN54321^^^GENERAL_HOSP^MR||KIM^SOOYOUNG^E^^MS^^L||19780922|F||2028-9^Asian|789 MAPLE DR^^REDMOND^WA^98052|||^PRN^PH^^^425^5556789
PD1|||GENERAL_HOSP^^HOSP1|1234567890^JOHNSON^LISA^B^^^MD
NK1|1|KIM^DAVID|SPO^SPOUSE^HL70063|789 MAPLE DR^^REDMOND^WA^98052|^PRN^PH^^^425^5556789

A31 - Update Person Information

Demographics-only update with no visit. Common on MPI-to-MPI flows and between hospital registration and downstream patient directories.

MSH|^~\&|REG|GENERAL_HOSP|MIRTH|INTEGRATION|20260421103000||ADT^A31^ADT_A05|MSG0009012345|P|2.5
EVN|A31|20260421103000
PID|1||MRN54321^^^GENERAL_HOSP^MR||KIM^SOOYOUNG^E^^MRS^^L||19780922|F||2028-9|222 BIRCH LN^^BELLEVUE^WA^98004|||^PRN^PH^^^425^5557890
PD1|||GENERAL_HOSP^^HOSP1|1234567890^JOHNSON^LISA^B^^^MD

A40 - Merge Patient (Patient Identifier List)

Patient deduplication. Two MRNs pointed at the same human — the registrar collapses them into one. A40 carries an MRG segment identifying the losing MRN, and PID carries the winning MRN.

MSH|^~\&|MPI|GENERAL_HOSP|MIRTH|INTEGRATION|20260421113000||ADT^A40^ADT_A39|MSG0010123456|P|2.5
EVN|A40|20260421113000|||JOHNSON^PATRICIA^^^^MPI
PID|1||MRN12345^^^GENERAL_HOSP^MR||DOE^JANE^MARIE^^MS^^L||19850412|F
MRG|MRN99999^^^GENERAL_HOSP^MR||ACC_OLD12345||||DOE^JANE^M||MRN_OLD_ENT

Downstream responsibilities on A40:

• Re-link every historical record (orders, results, visits, notes) from the losing MRN to the winning MRN.
• Keep an audit trail of the merge so it can be unmerged if the registrar made a mistake.
• Propagate the merge downstream so other systems also reconcile.
• Handle the case where the losing MRN was itself previously merged into a third MRN.

10. Mirth Connect Channel Patterns for ADT

Production ADT pipelines in Mirth Connect share a consistent architecture.

10.1 Inbound ADT listener (Mirth as receiver)

• Source connector: MLLP listener on a documented port (commonly 6661, 6662).
• Inbound data type: HL7 v2.x.
• Response: Auto-generate ACK after successful persistence; NACK with specific error codes on failure.
• Source filter: Ignore non-ADT message types that shouldn't be on this channel.
• Preprocessor: Log raw message, extract correlation ID (MSH-10), record latency.

// Preprocessor - extract key fields to channel map
var msg = new XML(message);
channelMap.put('messageControlId', msg['MSH']['MSH.10'].toString());
channelMap.put('triggerEvent', msg['MSH']['MSH.9']['MSH.9.2'].toString());
channelMap.put('patientMrn', msg['PID']['PID.3']['PID.3.1'].toString());
channelMap.put('visitNumber', msg['PV1']['PV1.19']['PV1.19.1'].toString());
channelMap.put('sendingApp', msg['MSH']['MSH.3'].toString());
return message;

10.2 Routing destinations

A typical hospital ADT feed fans out to 5-15 destinations. Common patterns:

• Database writer — insert into a normalized visit/patient store via the JDBC connector.
• FHIR transformer — convert to Patient/Encounter and POST to a FHIR server. See our FHIR integration guide.
• Downstream MLLP — push to billing, lab, radiology, pharmacy, bed management.
• File writer — archive the raw message for audit and replay.
• Kafka / message broker — fan out to analytics and operational consumers.

10.3 Trigger-based routing filter

// Destination filter - only route A01/A04/A08 to billing
var triggerEvent = channelMap.get('triggerEvent').toString();
var billingTriggers = ['A01', 'A04', 'A08', 'A03', 'A11', 'A13'];
return billingTriggers.indexOf(triggerEvent) !== -1;

10.4 Field mapping template (HL7 to normalized DB)

// Transformer - extract ADT fields for insert
var m = new XML(message);
$('mrn', m['PID']['PID.3']['PID.3.1'].toString());
$('familyName', m['PID']['PID.5']['PID.5.1'].toString());
$('givenName', m['PID']['PID.5']['PID.5.2'].toString());
$('dob', m['PID']['PID.7']['PID.7.1'].toString());
$('sex', m['PID']['PID.8'].toString());
$('visitNumber', m['PV1']['PV1.19']['PV1.19.1'].toString());
$('patientClass', m['PV1']['PV1.2'].toString());
$('location', m['PV1']['PV1.3']['PV1.3.1'].toString() + '^' +
              m['PV1']['PV1.3']['PV1.3.2'].toString() + '^' +
              m['PV1']['PV1.3']['PV1.3.3'].toString());
$('attendingNpi', m['PV1']['PV1.7']['PV1.7.1'].toString());
$('admitDateTime', m['PV1']['PV1.44']['PV1.44.1'].toString());
$('dischargeDateTime', m['PV1']['PV1.45']['PV1.45.1'].toString());
$('triggerEvent', m['MSH']['MSH.9']['MSH.9.2'].toString());

10.5 Handling merges (A40) in downstream DB

// On A40, re-link historical records
var m = new XML(message);
if (channelMap.get('triggerEvent') == 'A40') {
  var winningMrn = m['PID']['PID.3']['PID.3.1'].toString();
  var losingMrn  = m['MRG']['MRG.1']['MRG.1.1'].toString();
  $('winningMrn', winningMrn);
  $('losingMrn', losingMrn);
  // Downstream destination will execute: UPDATE orders SET mrn = :winningMrn WHERE mrn = :losingMrn
}

11. Common ADT Integration Pitfalls

11.1 Treating A04 like A01

Your billing system will try to bill outpatient visits as inpatient. Your bed management will reserve beds for patients who never got admitted. Always check PV1-2 and dispatch to the right handler.

11.2 Missing A40 merge logic

If you ignore A40, you will have duplicate patients in your downstream systems forever. Every clinical data warehouse we have touched has some merge cleanup debt.

11.3 Out-of-order processing

A03 before A01 is the classic example. Always preserve order per visit number. If your destination is a single database, per-visit serialization is usually enough.

11.4 NK1 duplication

Most EHRs send the complete NK1 list on every A08. Naive append logic creates N duplicates after N updates. Full replace on the NK1 collection is the right default.

11.5 Ignoring cancels

A11/A12/A13 are easy to overlook during initial implementation. Then in week three, a "mystery" admission appears that was actually cancelled. See our common HL7 integration errors post for more patterns.

11.6 Character set assumptions

Some senders encode extended characters as Latin-1 or Windows-1252 while your receiver expects UTF-8. Apostrophes in names like O'Brien become question marks. Test encoding explicitly with MSH-18.

11.7 Relying on free-text fields

Diagnosis description, admit reason, and discharge notes are prone to change. Always key off of coded fields (DG1-3, PV1-36) rather than their display names.

12. Frequently Asked Questions

Related Reading

• HL7 Integration: The Complete Guide
• FHIR Integration Guide
• EHR Integration Guide
• Healthcare Interoperability Guide
• Mirth Connect: The Complete Guide
• HL7 v2 Message Structure Explained
• HL7 v2 vs v3 vs FHIR
• HL7 ACK/NAK Explained
• MLLP Protocol Explained
• HL7 Testing Tools & Sample Messages
• Common HL7 Integration Errors
• HL7 ORM/ORU Lab Workflow
• HL7 SIU Scheduling Messages
• HL7 MDM Document Messages
• Mirth Connect MLLP Connection Refused
• Mirth Helpdesk
• Services
• Contact Us