Who maintains the list of HL7 trigger events?

HL7 International maintains them as part of the HL7 v2 standard and publishes the codes as table 0003 in HL7 Terminology. Sites and vendors sometimes add local Z events, which need documenting in the interface specification because no other system will recognize them.

Do we need to handle every ADT event?

No. Start from what the receiving system does, list the events that change its data and filter out the rest in the interface engine. For every event you process, include its cancel and merge events too, because missing them leaves records in the wrong state.

What is an HL7 trigger event example from a hospital?

A nurse admits a patient from the emergency department, and the EHR sends ADT^A01 to the lab, pharmacy and bed management systems. When the patient moves to another floor the next day, the EHR sends ADT^A02 and each receiver updates the patient's location.

Health Tech & Interoperability

HL7 Trigger Events

An HL7 trigger event is the real-world event, such as an admission, a transfer or a new lab result, that causes a system to send an HL7 v2 message. The event code travels in MSH-9 with the message type, for example ADT^A01 for an admit, so the receiving system knows what happened and how to process it.

Key takeaways

A trigger event is the event that causes an HL7 v2 message to be sent
MSH-9 carries message code, trigger event and message structure, for example ADT^A01^ADT_A01
ADT events describe patient movement; ORM^O01 and ORU^R01 carry orders and results
Several events share one message structure, so parsing and processing are separate decisions
In FHIR, the event code moves to MessageHeader.eventCoding

What an HL7 trigger event means

HL7 v2 messaging is event driven. Nothing is sent until something happens in the source system: a patient is registered, admitted, moved or discharged, or a result is finalized. Each event has a three-character code, and one message type can carry many events. ADT messages alone cover admissions, transfers, discharges, registrations, updates, cancellations and merges.

MSH-9, the message type field in the message header, has three parts: the message code (ADT), the trigger event (A01) and the message structure (ADT_A01). The structure tells the parser which segments to expect. Several events share one structure, so one parser can serve a group of events while the processing differs for each.

Agnotic Technologies builds HL7 v2 interfaces that subscribe only to the events a downstream system needs and handle each one deliberately. Transport, interface engines and message mapping are covered on our HL7 v2 integration page.

Why do interfaces filter by trigger event?

Most receiving systems need only some events. A lab system may need registrations and admissions to create the patient, but not every bed move. Filtering in the interface engine keeps unwanted events out and keeps the receiver's logic small.

A08, update patient information, needs the most care. Source systems often send it for small changes, sometimes several times in a minute. A receiver that treats each A08 as new data can overwrite good values, create duplicate work or fire an alert twice. A safer pattern compares the update with what is stored and records only real changes.

What happens when an event is cancelled?

Cancel events reverse an earlier one: A11 cancels an admit and A13 cancels a discharge. A receiver that ignores them will show patients as admitted or discharged when they are not. Any interface that processes A01 or A03 should also decide what to do with A11 and A13, and with A40 patient merges.

Which common trigger events should you know?

Message and event	Real-world event	What a receiving system usually does
ADT^A01	Admit or visit notification	Opens an inpatient encounter and places the patient on a unit and bed
ADT^A02	Transfer a patient	Moves the patient to a new unit, room or bed and updates location lists
ADT^A03	Discharge or end visit	Closes the encounter and starts discharge follow-up work
ADT^A04	Register a patient	Creates or updates the patient and an outpatient or emergency visit
ADT^A08	Update patient information	Compares demographics or visit data with what is stored and applies real changes
ORM^O01	Order message	Creates or changes an order in the lab, radiology or pharmacy system
ORU^R01	Unsolicited transmission of an observation	Files results against the order and the patient, and flags abnormal values

Facts and primary sources

HL7 publishes trigger event codes as code system v2-0003, the concepts specifying the trigger event for Version 2.x interface messages, used in the MSH segment.
Source: HL7 Terminology, v2-0003 event type
In HL7 table 0003, A01 is admit or visit notification, A03 is discharge or end visit, A08 is update patient information and R01 is unsolicited transmission of an observation message.
Source: HL7 Terminology, v2-0003 event type
The HL7 message structure ADT_A01 is shared by the A01, A04, A08 and A13 events.
Source: HL7 Terminology, v2-0354 message structure
The HL7 v2-to-FHIR mapping guide maps MSH-9 Message Type to the FHIR MessageHeader.eventCoding element.
Source: HL7 v2 to FHIR mapping, MSH to MessageHeader

Explore this on Agnotic

Where an HL7 trigger event shows up in how we build.

IntegrationHL7 v2 integration services GlossaryHL7 and HL7 v2 ComparisonFHIR vs HL7 v2 comparison IntegrationMirth Connect interface development

Frequently asked questions

The message type names the kind of message, such as ADT for patient administration or ORU for results. The trigger event names what happened, such as A03 for a discharge. Together they tell the receiver how to read the message and what to do with it.