How to Read HL7 Messages
Reading HL7 messages is a practical skill for anyone who works with healthcare interfaces, electronic health records, lab systems, radiology systems, billing systems, or integration engines. HL7 messages can look intimidating at first because they are compact, full of symbols, and often contain many codes. Once you understand the structure, however, a message becomes a readable set of segments, fields, components, and values that describe an event in a healthcare workflow.
1. Know What HL7 Means
HL7 stands for Health Level Seven. HL7 International develops standards for exchanging healthcare information between systems. In everyday interface work, when people say “an HL7 message,” they often mean an HL7 Version 2 message. HL7 v2 is widely used in hospitals and healthcare organizations for patient admission events, lab orders, lab results, radiology results, scheduling, billing, and many other workflows.
This guide focuses on reading HL7 v2-style messages. FHIR, CDA, and HL7 v3 are different HL7 standards with different formats. If you are looking at pipe-delimited lines that begin with segments such as MSH, PID, PV1, OBR, and OBX, you are likely reading an HL7 v2 message.
2. Start With the Segment Names
An HL7 v2 message is made of segments. Each segment usually appears on its own line and begins with a three-character segment ID. The segment ID tells you what kind of information the line contains. For example:
- MSH means message header.
- PID means patient identification.
- PV1 means patient visit.
- ORC means common order.
- OBR means observation request.
- OBX means observation result.
- MSA means message acknowledgment.
Before you try to interpret every field, scan the segment names. They tell you the story of the message.
3. Learn the Delimiters
HL7 v2 messages use special characters to separate data. The most common field separator is the pipe character: |. Components inside a field are usually separated by a caret: ^. Repeating values are often separated by a tilde: ~. Subcomponents are commonly separated by an ampersand: &.
The MSH segment defines the delimiters at the start of the message. A common beginning looks like this:
MSH|^~&|SendingApp|SendingFacility|ReceivingApp|ReceivingFacility|202607151030||ADT^A01|12345|P|2.5.1
After MSH, the pipe separates fields. The characters after the first pipe usually define encoding characters: component, repetition, escape, and subcomponent separators.
4. Read the MSH Segment First
The MSH segment is the message header. It tells you who sent the message, who should receive it, when it was created, what type of message it is, the message control ID, processing mode, and HL7 version. For troubleshooting, MSH is one of the most important segments.
In this example, ADT^A01 indicates an admit or registration event. 12345 is the message control ID. P often indicates production processing. 2.5.1 indicates the HL7 version used by the message.
When an interface fails, compare MSH values with what the receiving system expects. Wrong sending facility, wrong message type, wrong version, or duplicate control IDs can cause problems.
5. Read the PID Segment for Patient Identity
The PID segment carries patient identification information. It may include patient IDs, name, date of birth, sex, address, phone number, and other demographic details depending on the implementation. A simplified PID segment might look like this:
PID|||123456^^^HospitalMRN||Doe^Jane||19800514|F
Here, the patient identifier appears in a field containing an ID and assigning authority. The name uses components, with family name and given name separated by a caret. Always be careful with patient data. Use test data when learning, and follow privacy rules such as HIPAA or your organization’s policies when handling real messages.
6. Read PV1 for Visit or Encounter Details
The PV1 segment describes the patient visit or encounter. It may include patient class, assigned location, attending provider, admission type, visit number, and related visit details. In hospital interfaces, PV1 helps receiving systems know whether the patient is inpatient, outpatient, emergency, or another class.
If an order or result is not routing correctly, visit location and patient class are often worth checking. Interface rules may depend on department, facility, unit, or provider fields.
7. Understand Order and Result Segments
Many clinical messages include order and result information. ORC gives common order control information. OBR describes the ordered test or observation request. OBX carries the actual result values or observations.
A simplified result might include:
OBR|1||LAB123|CBC^Complete Blood Count OBX|1|NM|WBC^White Blood Cells||6.4|10*3/uL|4.0-11.0|N
In the OBX segment, the value type may be numeric, text, coded, date/time, or another type. The observation identifier tells you what was measured. The result value, units, reference range, and abnormal flag help interpret the observation.
8. Count Fields Carefully
HL7 fields are position-based. This means the meaning of a value depends on where it appears in the segment. Empty fields still count. For example, two pipes with nothing between them mean an empty field. Do not remove empty fields casually, because that shifts later fields into the wrong positions.
When reading a message manually, use an HL7 viewer, parser, or a spreadsheet-like field counter. Counting by eye can work for short examples, but it becomes risky with long segments.
9. Know That Implementations Vary
HL7 v2 is flexible, and real-world interfaces often use local conventions. Two systems may both send ADT messages but populate optional fields differently. One organization may use certain Z-segments, which are custom segments. Another may rely on specific codes, local tables, or routing rules.
Always read the interface specification or implementation guide for the system you are supporting. The HL7 standard gives the structure, but the local interface agreement tells you how that structure is actually used.
10. Use a Safe Troubleshooting Process
When troubleshooting, start with the message type, sender, receiver, timestamp, and control ID in MSH. Then confirm patient identifiers in PID, visit details in PV1, order details in ORC and OBR, and result values in OBX. Compare the message with a known good example. Look for missing required fields, invalid codes, date formatting problems, duplicate IDs, extra separators, or unexpected custom segments.
Never paste real patient messages into public tools, public forums, or unsecured AI systems. De-identify data first and follow your organization’s privacy and security policies.
Useful Official Resources
Final Checklist
To read HL7 messages, identify the message type in MSH, scan the segment names, understand the delimiters, count fields carefully, read patient data in PID, visit data in PV1, order data in ORC and OBR, and result data in OBX. Use official standards and local interface guides, protect patient information, and test with safe sample data whenever possible.
