The ADT (Admit, Discharge, Transfer) family is the most common reason a hospital HL7 interface exists. Every downstream system — laboratory, radiology, pharmacy, billing, dietary, and more — depends on the ADT feed to keep its patient roster synchronized with the admissions/registration system. When a new interface is built, upgraded, or migrated, ADT test data is the first thing an integration engineer needs. This guide walks through the five most frequently tested ADT trigger events, what each one represents clinically, the segment structure receivers expect, and how to generate valid test messages without touching real PHI using our HL7 Message Generator.
Why ADT Testing Is Different From Other HL7 Testing
ORM and ORU test messages verify a single transaction: a lab order and its result. ADT testing is fundamentally stateful. An ADT^A08 update only makes sense against a previously admitted patient (via A01 or A04); an A03 discharge only makes sense for an inpatient who was previously admitted. Receivers that enforce this state — most mature EHRs do — will reject A08 or A03 messages that reference a patient they have no record of. Proper ADT testing therefore requires generating sequences of messages, not individual messages: A01 → A08 → A03, for example, with consistent PID-3 patient ID and PV1-19 visit number across all three.
The Golden Thread: Patient ID and Visit Number
In an ADT sequence, the Patient ID (PID-3) identifies the person and the Visit Number (PV1-19) identifies the specific hospital encounter. These two fields must remain identical across all messages referring to the same visit. Mismatched values — even a single typo in a long MRN format — cause downstream systems to either create duplicate patient records (data quality disaster) or silently reject the message (production incident). Our generator keeps these values consistent when you fill sample data once and generate multiple message types for the same patient.
ADT^A01 — Patient Admit
Generated when a patient is formally admitted as an inpatient. Triggers the downstream population of patient data in every system that subscribes to the ADT feed. Required segments: MSH, EVN, PID, PV1. Typical optional segments in production: AL1 (allergies), DG1 (diagnoses), IN1 (insurance), NK1 (next of kin), OBX (vitals at admission).
A minimal valid A01 structure:
MSH|^~\&|SENDING_APP|SENDING_FAC|RECEIVING_APP|RECEIVING_FAC|20260420120000||ADT^A01|MSG000001|P|2.5 EVN|A01|20260420120000 PID|||TEST000001||TEST^PATIENT^A||19000101|U PV1||I|WARD1^101^A||||1001^DOCTOR^TEST
Open the generator, select ADT^A01 from the dropdown, click "Fill with sample data" and the above structure (with configurable values) appears in the preview. Copy the message, paste into your integration engine's test channel, verify the engine accepts it, and confirm downstream systems receive the propagated patient record. This is the entry point of essentially every ADT test cycle.
ADT^A04 — Register Outpatient / Outpatient Visit
Similar to A01 but for outpatient visits (clinic appointments, same-day procedures, emergency room visits that do not result in admission). The PV1-2 Patient Class field distinguishes: I for inpatient (A01), O for outpatient (A04), E for emergency. Many receivers have different routing rules for A01 vs A04 — a billing system may treat an inpatient admit very differently from an outpatient registration. Test both independently.
In practice, many hospitals generate A04 for the initial arrival and A01 later if the outpatient becomes admitted ("direct admit to OR" conversions, ED-to-inpatient). Your test cycle should include this conversion: A04 → A01 for the same patient, verifying downstream systems reconcile the change in patient class without creating a duplicate record.
ADT^A08 — Update Patient Information
The single most important ADT message to test thoroughly. A08 is the event that fires whenever any demographic field, insurance detail, visit attribute, or physician assignment changes on an existing patient. In a large hospital, A08 volume exceeds A01+A03 combined — corrections to names, insurance updates, physician transfers, allergy additions all flow as A08.
The challenge with A08: every field in the message is a potential "change" candidate, but most fields are typically the same as the previous version. Receivers must perform a diff against their stored record to determine what actually changed. Poorly written receivers may assume the entire message is an overwrite and reset fields that weren't intended to change. Your A08 test cases should include:
- Name correction (PID-5 change).
- DOB correction (PID-7 change — rare but consequential because it may affect pediatric/adult routing).
- Insurance update (IN1 added/modified).
- Physician transfer (PV1-7 change).
- Location change without transfer (PV1-3 change — e.g., bed swap within the same ward).
- Allergy addition (AL1 added).
For each, verify that downstream systems update the changed field and do not overwrite unchanged fields. The common failure mode is that a system silently drops an allergy because the A08 message didn't include an existing AL1 segment; the receiver interpreted the absence as "allergy was removed." Real-world production incidents from this pattern have caused actual patient harm, making A08 round-trip testing the highest-priority ADT QA activity.
ADT^A03 — Patient Discharge
Generated when a patient is formally discharged. Triggers downstream cleanup: billing finalization, pharmacy order deactivation, bed-management release, dietary system stop. Required segments: MSH, EVN, PID, PV1. PV1-36 Discharge Disposition is critical — values like "Home" vs "Transfer to SNF" vs "Expired" route differently in downstream systems.
Test cases for A03 should include the standard scenarios (routine home discharge, transfer-to-facility discharge, against-medical-advice discharge, expired-in-hospital) and verify that billing, pharmacy, and bed-management systems update correctly for each. An A03 that does not fire correctly leaves "ghost" patients occupying beds in the bed-management system even after the real patient has gone home — a common source of bed-availability reporting errors in hospitals.
ADT^A11 — Cancel Admit
The least-tested but most damaging-when-broken ADT event. A11 fires when an admit (A01) was recorded in error and must be fully undone — typically within minutes of the original A01, when a registrar realizes they admitted the wrong patient or used the wrong visit number. Downstream systems must reverse everything they did in response to the A01: remove the patient from any worklists, cancel any auto-generated orders, release any assigned beds, remove any registered visit number.
A11 is particularly error-prone in downstream systems because it is rare — a receiver that was not tested against A11 may treat it as an unknown message type and ignore it, leaving the erroneous patient record in place. Your integration test cycle should specifically include: A01 → A11 → verify the patient is completely absent from every downstream system as if the original A01 had never fired. Failing this test in production means a patient is permanently registered in a system when they should never have been.
Building a Full ADT Test Sequence
A comprehensive ADT test sequence against an integration engine looks like this:
- Message 1: ADT^A04 for outpatient registration (patient TEST^PATIENT^A, visit V000001). Verify downstream routing.
- Message 2: ADT^A01 for admission conversion (same patient, same visit). Verify patient class updates everywhere.
- Message 3: ADT^A08 for name correction (same patient, same visit, PID-5 changed). Verify exactly PID-5 updates; all other fields unchanged downstream.
- Message 4: ADT^A08 for physician transfer (PV1-7 changed). Verify physician-driven routing updates (e.g., surgeon-attributed order routing) correctly.
- Message 5: ADT^A08 for location change (PV1-3 changed, bed swap). Verify bed management updates.
- Message 6: ADT^A03 for discharge (same patient, same visit). Verify billing finalizes, pharmacy stops, bed released.
Use our generator to produce each message, keeping PID-3 and PV1-19 consistent across the sequence. Send each in order to the test integration engine, allow downstream propagation, and verify system state after each message using the receiver's admin console. When all six pass, the engine is ready for production ADT traffic.
For a regression suite that runs automatically: save each generated message to a text file, write a small shell or Python script that sends them sequentially to the engine's HL7 receiver, and parse the ACK responses to confirm each was accepted. On any rejection, the test suite fails loudly before the change reaches production.
Common Failures and How to Diagnose Them
"Message rejected — unknown trigger event"
MSH-9 value is not what the receiver expects. Check both the event code (A01, A03, etc.) and the message structure code, e.g., ADT^A01^ADT_A01 for full specification. Some receivers require all three; most accept just ADT^A01.
"PID-3 required" or "Patient not found"
The receiver expects PID-3 to match a known patient ID format (specific assigning authority, specific ID type code). Generate with a realistic MRN format: TEST000001^^^HOSPMRN^MR where "HOSPMRN" matches the receiver's configured assigning authority.
"Duplicate visit"
PV1-19 visit number collides with an existing visit in the receiver's database. Use a unique value per test cycle: include the current date and a counter, e.g., V20260420001.
A08 processed but downstream fields unchanged
The receiver may be configured to ignore A08 entirely (some are) or to only process specific field changes. Check the receiver's event-handler configuration to verify the A08 update path is enabled and covers the fields you are trying to change.
Integration Engine Specifics
Mirth Connect
Create a channel of type "HL7 v2.x MLLP Listener," paste generated messages into the "Send Message" dialog, and monitor the channel log. Mirth will report ACK or NAK based on your destination's response. Combine with the channel's message-preprocessing capabilities to test transformations against synthetic data.
Rhapsody / Cloverleaf
Similar pattern: a test endpoint that accepts HL7 messages over MLLP, replays your generated message, and logs both the input and the translated output. Useful for verifying transformation maps during integration engineering.
Custom or Commercial EHR Engines
Most commercial EHRs offer a test environment that mirrors production routing. Generate your messages with our tool, transmit via the EHR's test interface, and use the EHR's audit log to verify expected downstream behavior.
Running the Generator
Open the HL7 Message Generator, pick the ADT trigger event from the dropdown, click "Fill with sample data" to populate required fields with obviously fake values (TEST^PATIENT, DOB 19000101, SENDING_APP), and customize whatever your test case needs. The preview updates live. Use Copy to pull the message into your integration engine's test dialog, or click "Open in HL7 Viewer" to inspect structure segment-by-segment before sending.
All five ADT trigger events are supported with their correct required-segment structure. Every message produced parses cleanly through our HL7 parser in the test suite, so structural correctness is guaranteed — any failure you see downstream comes from semantic issues (wrong code-table values, missing fields your specific receiver requires), which is exactly what interface testing is supposed to catch.