If you’re working in healthcare IT, you’ve probably heard about HL7—but what exactly are HL7 message types and HL7 event types? These two concepts form the backbone of communication between electronic health systems. Whether you’re integrating an EMR, building a lab interface, or troubleshooting a connection between systems, understanding these terms is critical.
This guide will break it all down: what they are, how they relate, and why they matter.
What is HL7?
HL7 (Health Level Seven) is a set of international standards for the exchange of clinical and administrative data between healthcare systems. These standards are designed to make sure data flows consistently and accurately across systems—regardless of the vendor or platform.
HL7 v2 is the most widely adopted version, and it’s message-based. That means data is exchanged in structured messages. Every message has a specific purpose and follows a predictable format.
That’s where HL7 message types and HL7 event types come in.
HL7 Message Types: The What
An HL7 message type tells you what kind of data is being sent. It defines the structure of the message and its overall purpose. In HL7, each message type is represented by a three-character code.
Here are the most common HL7 message types you’ll encounter:
| Code | Name | Purpose | Most common trigger |
| ADT | Admit, Discharge, Transfer | Patient movement and demographic updates | A01 (admit), A03 (discharge), A08 (update) |
| ORM | Order (Pharmacy/Treatment) | Placing orders — legacy message | O01 (new order) |
| OMG / OML / OMP | Order messages (v2.4+) | Modern replacements for ORM, split by domain (general, lab, pharmacy) | O19 / O21 / O09 |
| ORU | Observation Result | Returning lab and diagnostic results | R01 (unsolicited result) |
| ORR | Order Response | Acknowledging or responding to an order | O02 |
| SIU | Scheduling Information Unsolicited | Appointments and scheduling events | S12 (new), S15 (cancel) |
| MDM | Medical Document Management | Clinical documents — notes, summaries | T02 (new doc), T04 (status change) |
| DFT | Detailed Financial Transaction | Billing and charges for services rendered | P03 (post charge) |
| MFN | Master Files Notification | Syncing reference data (providers, codes) | M02 (staff/practitioner) |
| BAR | Billing Account Record | Adding or updating billing accounts | P01 (add account) |
| VXU | Vaccination Update | Immunization records | V04 |
| ACK | Acknowledgment | Confirms receipt of any message | (paired with all of the above) |
A practical note most guides skip: ORM is deprecated in favor of OMG, OML, and OMP from HL7 v2.4 onward. Many legacy systems still send ORM, so you’ll see both in the wild—but if you’re building a new interface, you’ll likely work with the newer order messages.
Each message type has a defined structure, made up of segments like PID (patient info), OBR (order request), OBX (observation result), and others. But structure alone isn’t enough—you also need to know why the message is being sent.
That’s where HL7 event types come in.
Going deeper on ADT
ADT is the highest-volume message family and has 50+ event types of its own. This guide covers where ADT sits among the other message types; for the full ADT event-type reference (A01–A40), segment breakdowns, and a sample message, see our complete HL7 ADT guide.
HL7 Event Types: The Why
If HL7 message types tell us what kind of data is being sent, then HL7 event types explain why the message was triggered in the first place.
An event type is paired with a message type to create a complete message trigger, written like this: ADT^A01, where:
- ADT is the message type (Admit, Discharge, Transfer)
- A01 is the event type (Patient Admit)
Together, they tell the receiving system, “This is an admit message for a patient.”
Examples of Event Types by Message Type
ADT (Admit, Discharge, Transfer)
| Event Type | Trigger | Description |
| A01 | Admit | Patient is being admitted |
| A02 | Transfer | Patient is being transferred |
| A03 | Discharge | Patient is being discharged |
| A04 | Register | Outpatient registration |
| A08 | Update | Update patient information |
| A11 | Cancel Admit | Admission was canceled |
ORM (Order Message)
| Event Type | Description |
| O01 | New order |
| O02 | Order acknowledgment |
ORU (Observation Result)
| Event Type | Description |
| R01 | Unsolicited result (most common) |
| R02 | Query response (less common) |
SIU (Scheduling)
| Event Type | Description |
| S12 | New appointment booking |
| S13 | Appointment reschedule |
| S14 | Appointment modification |
| S15 | Appointment cancellation |
Why HL7 Message Types and Event Types Matter
Here’s why understanding both HL7 message types and HL7 event types is crucial:
1. System Integration
When building interfaces between systems—say, from an EMR to a lab—you need to know what messages to expect and how to process them. Knowing the exact type (ORM^O01) tells your system how to read and handle the message correctly.
2. Workflow Mapping
In a hospital, a single patient admission triggers several actions across departments: registration, room assignment, medication orders, and more. Each action may generate different message types and event types. Mapping these out ensures that all systems stay in sync.
3. Troubleshooting
If data isn’t flowing correctly between systems, one of the first things you check is the message logs. Knowing the message and event type helps identify where something went wrong or what’s missing.
4. Compliance and Auditing
Healthcare data is sensitive. When systems are audited, being able to track exactly what message was sent and why (based on message type and event type) helps maintain transparency and accountability.
Real-World Example: A Patient Visit
Let’s say a patient walks into a hospital. Here’s how HL7 message types and event types are used at every step:
- Registration — ADT^A04 (Outpatient Registration)
- Admission — ADT^A01 (Admit a patient)
- Doctor orders bloodwork — ORM^O01 (Order for lab test)
- Lab results are ready — ORU^R01 (Lab sends results)
- Discharge — ADT^A03 (Discharge the patient)
Each step triggers a specific combination of message and event types. Receiving systems know how to process these messages and update records accordingly.
How a System Knows the Message Type (MSH-9 and ACKs)
The examples above explain which message gets sent. But how does a receiving system actually know what it’s looking at—and how does the sender know the message arrived? Two things make that work.
Where the message type lives: MSH-9
Every HL7 v2 message starts with a Message Header segment (MSH). The message type and event type are carried in field 9 of that segment (MSH-9), written as messageType^eventType^messageStructure. The receiving system reads MSH-9 first to know how to parse everything that follows.
MSH|^~\&|EPIC|HOSP|LAB|HOSP|20260115093000||ADT^A01^ADT_A01|MSG00001|P|2.5.1
Here, ADT^A01^ADT_A01 in the 9th field tells the receiver: this is an admit message, parse it using the ADT_A01 structure.
The ACK every message expects
Most HL7 v2 messages are answered with an ACK (acknowledgment). The sender doesn’t consider a message delivered until it gets one back. The three responses you’ll see are:
- AA — Application Accept (message received and processed)
- AE — Application Error (received but a problem occurred)
- AR — Application Reject (message refused)
Understanding ACK handling is where most real interface troubleshooting actually happens. If messages are “sending” but nothing is updating downstream, the ACK response is usually the first place to look.
HL7 Version Differences
While this guide focuses on HL7 v2.x (specifically versions 2.3–2.6, which are most common), newer systems may use HL7 v3 or FHIR (Fast Healthcare Interoperability Resources). These use a different structure—often more XML or JSON based—but the concept of message types and events still applies.
If you’re in a modern health IT environment, you may see both HL7 v2 and FHIR operating side by side.
Final Takeaways
- HL7 message types define the general purpose of a message (ADT, ORM, ORU, etc.)
- HL7 event types describe the specific trigger for that message (A01, O01, R01, etc.)
- Together, they form message triggers like ADT^A01 or ORU^R01, which guide system behavior.
- The message and event type are carried in MSH-9, and most messages expect an ACK in return.
- Understanding all of this is key to designing, maintaining, and troubleshooting healthcare data systems.
Quick Reference: Most Common HL7 Message/Event Combos
| Message Type | Event Type | Description |
| ADT | A01 | Admit patient |
| ADT | A03 | Discharge patient |
| ADT | A08 | Update patient info |
| ORM | O01 | New order |
| ORU | R01 | Observation result |
| SIU | S12 | Schedule new appointment |
Need help mapping your current HL7 feed or designing interface logic for your software? Taction Software builds and maintains HL7 interfaces across ADT, ORM, ORU, MDM, and more. Get in touch and we’ll break it down, message by message.
