Interoperability
HL7 v2 ADT messages explained: A01, A02, A03, A08 and more
ADT is the HL7 v2 message type for patient administration events. Each message carries a trigger event: A01 is an admit or visit notification, A02 a transfer, A03 a discharge or end of visit and A08 an update to patient information. Receiving systems use them to keep an accurate picture of who is where.
The trigger events you'll see most
HL7 keeps the codes in two tables: table 0076 lists message types (ADT, ORU, SIU and so on) and table 0003 lists the trigger events. Every ADT event below is answered with a general acknowledgement (ACK). The names are HL7's own.
| Event | HL7 name |
|---|---|
| A01 | Admit/visit notification |
| A02 | Transfer a patient |
| A03 | Discharge/end visit |
| A04 | Register a patient |
| A05 | Pre-admit a patient |
| A08 | Update patient information |
| A11 | Cancel admit/visit notification |
| A13 | Cancel discharge/end visit |
| A28 / A31 | Add / update person information |
| A40 | Merge patient: patient identifier list |
What's inside an ADT message
An ADT message is a sequence of segments. The ones that matter most for patient flow are the message header (MSH), the event type (EVN), patient identification (PID) and the patient visit (PV1). HL7's V2 to FHIR guide maps them roughly as you would expect: PID to a FHIR Patient, PV1 to an Encounter, MSH to a MessageHeader and EVN to a Provenance record. The visit segment is what turns "this person" into "this stay", which is why so many downstream systems depend on it.
Where ADT feeds go wrong
- Cancellations. A11 cancels an admission and A13 cancels a discharge. A receiving system that only handles the "forward" events ends up showing patients in beds they never reached, or gone from beds they're still in.
- Merges. A40 tells you two identifiers belong to one patient. Downstream systems have to merge their own records, and get it wrong if they ignore the event.
- Local variation. HL7 notes that sites support different fields and even put the same data element in different places. Two hospitals' "A02" can carry different detail.
- Updates as snapshots. v2 usually re-sends the whole record. A field left out generally means "keep what you have", while two double quotes mean "delete this value", and receivers have to honour both.
Why operations teams should care
Bed state, ward lists, porter requests, housekeeping and discharge tracking all start from the ADT stream. When an operational dashboard is wrong, the cause is often an ADT event that was missed, arrived late or wasn't reversed. Before automating anything that depends on bed state, ask the integration team which events your PAS actually sends, which ones the receiving system handles, and what happens to a message it can't understand.
What it does not mean
- An A03 doesn't mean the bed is ready. It records the end of the visit. Cleaning and handing the bed to the next patient are separate steps that need their own signal.
- An A08 isn't only a demographics change. HL7 names it "update patient information", and sites use it for many kinds of change; check what yours sends.
- The same event code doesn't mean the same content everywhere. Implementation varies between systems and sites.
Where Thalix fits
In Thalix, the hl7v2 driver receives ADT (and ORU, orders, scheduling and documents) and maps them to FHIR R4. Every identifier a source sends, such as a hospital number or NHS number, links to one Thalix patient, and conflicts are raised for a person to review rather than merged automatically. Senders get their acknowledgement only after the event is durably logged. In the demo, ADT from a simulated hospital fills Ward 4, and the Bed turnaround workflow starts when a bed goes to cleaning: housekeeping confirms it's clean, which frees it, and the ward is told it's ready.
Thalix is at pilot stage. Demos run on synthetic data, and a hospital deployment needs its own clinical safety case, information governance approval and security review. We don't claim any certification or assessment result the product doesn't have.
Questions people ask
What is the difference between A01 and A04?
In HL7's table, A01 is an admit or visit notification and A04 is register a patient. Which one your PAS sends for which kind of attendance is a local configuration choice, so check your own interface specification.
What does an A40 message do?
A40 is HL7's merge patient (patient identifier list) event. It tells receiving systems that identifiers belong to one patient, so they can merge their own records.
How is an ADT message acknowledged?
HL7's event table pairs each of these ADT events with ACK, the general acknowledgement message type in table 0076.
Sources
Each source below is an official page, read and checked in October 2026. Where a page and this guide differ, the official page wins.
- HL7 table 0003: event type HL7 Terminology · checked October 2026
- HL7 table 0076: message type HL7 Terminology · checked October 2026
- V2 to FHIR: segment maps HL7 · checked October 2026
- Comparison: HL7 v2 messaging (FHIR R5) HL7 · checked October 2026
General information only, written for hospital digital, IT, operations and clinical safety teams. It isn't legal, regulatory, information governance or clinical safety advice, and it doesn't replace your own organisation's processes or the official guidance linked above.