What Is the HL7 Data Format (And Why It Matters for Clinical Labs)?

If you work in healthcare, a lot of the software you rely on almost certainly uses the HL7 data format under the hood. It’s the infrastructure behind how health information moves, and it’s a critical component of clinical laboratory data systems (even if they don’t “run on it” internally, since they’ll probably need to exchange data with others that do).

What Is the HL7 Data Format?

HL7 (Health Level Seven) is a set of international standards for exchanging, integrating, sharing, and retrieving electronic health information. When people say “HL7 data format,” they’re usually referring to HL7 v2.x, the messaging standard that has powered healthcare data exchange since the late 1980s. Decades later, it’s still the dominant format in clinical lab interfacing.

An HL7 message is a structured, text-based data string. Each segment represents a category of information. For example:

• MSH — Message Header (routing and metadata)
• PID — Patient Identification
• OBR — Observation Request (the test ordered)
• OBX — Observation/Result (the actual test result)
• NTE — Notes and Comments

HL7 v2 messages are often nicknamed “pipe-delimited” messages because the pipe character ( | ) is incorporated so prominently:

MSH 00 | ^~\& 01 | LAB 02 | HOSPITAL 03 | EHR 04 | CLINIC 05 | 202608121030 06 |   07 | ORU^R01 08 | MSG00001 09 | P 10 | 2.3 11

1. 00 MSH MSH Segment type: message header
2. 01 ^~\& MSH-2 Encoding characters (component, repetition, escape, and subcomponent separators)
3. 02 LAB MSH-3 Sending application
4. 03 HOSPITAL MSH-4 Sending facility
5. 04 EHR MSH-5 Receiving application
6. 05 CLINIC MSH-6 Receiving facility
7. 06 202608121030 MSH-7 Date and time of message (Aug 12, 2026, 10:30)
8. 07 empty MSH-8 Security (left empty)
9. 08 ORU^R01 MSH-9 Message type: unsolicited observation result
10. 09 MSG00001 MSH-10 Message control ID
11. 10 P MSH-11 Processing ID: production
12. 11 2.3 MSH-12 HL7 version

In plain English, that means a lab is sending a hospital a clinical result on August 12, 2026 at 10:30 AM, it’s a production message using HL7 version 2.3, and its unique message ID is MSG00001.

HL7 v2 isn’t pretty to look at, but it’s compact, fast to parse, and battle-tested across decades of real-world clinical workflows.

HL7 v2 vs. HL7 v3 vs. FHIR

“HL7” isn’t just one thing:

• HL7 v2.x — The tried-and-true format. Widely implemented and still the standard most lab interfaces run on today.
• HL7 v3 — Intended to replace v2, but adoption was limited due to complexity.
• FHIR (Fast Healthcare Interoperability Resources) — The newer, modern standard. FHIR is the direction the industry is moving, but v2 messaging still dominates lab-to-EHR and lab-to-LIS interfaces because of its deep roots inside legacy systems.

HL7 v2 was designed in the 1980s for point-to-point messaging between big institutional systems. It’s still extremely efficient at doing that today, so it’s not strictly “worse” than FHIR.

In fact, HL7 v2 is really flexible. But it’s flexible in the way a document with no formatting rules is flexible; anybody can do anything. Sure, it has a defined structure, but that defined structure only covers the basics. If you want to do something that the standard didn’t anticipate, you have to create your own workaround. That’s why two “HL7 v2 compliant” systems can still fail to understand each other.

FHIR keeps the flexibility, but includes an “official way” to add new or custom information. With FHIR, systems can still be extended and customized without breaking down when they talk to each other.

AI and FHIR

As of 2026, HL7 is working on making FHIR more directly usable by AI systems. HL7’s freshman CEO, Rachel Dunscombe, recently said, “We have done some really good work to make our standards more machine-readable and ingestible by AI. But I think the opportunity that AI offers us is multi-fold — everything from supporting us in developing the standards internally and we’re starting to use it for that — to the way it is being used within health systems and by individual patients. I’ve had some really good discussions the last few weeks around how far HL7 goes into the standards for AI.”

But what exactly is the problem HL7 is trying to solve? Most LLMs can already read FHIR, right?

Well, imagine you give an AI a 20,000-resource bundle from an actual health system.

It contains multiple encounters, amended observations, duplicated data, references between resources, local codes, inconsistent terminology, missing fields, and multiple representations of essentially the same event.

Now, you ask, “What was this patient’s most recent confirmed HER2 result before treatment began?”

The AI has to determine which pieces of data mean what and resolve all the relationships between them. LLMs like ChatGPT or Claude could probably figure it out, but “probably figure it out” isn’t a very good or reliable healthcare interoperability standard.

In fact, this whole situation might give new relevance to an idea HL7’s openEHR has pursued for decades. Make clinical data more consistent and semantically meaningful from the start. For AI, that consistency becomes a lot more valuable because you’re asking a model to reason over the data.

Why the HL7 Data Format Matters for Clinical Labs

Clinical labs sit at the center of a very complex data ecosystem. They need to communicate with different payers, providers, software vendors, and patients. Without a standardized format like HL7, every lab-to-system connection would require custom, one-off integration work.

HL7-based interfaces let results move automatically between systems instead of being manually retyped, cutting down on the transcription errors that can put patient safety at risk. They also speed up how quickly critical results reach the people who need them, and they create the kind of consistent, auditable data trail that regulations like CLIA and CAP require.

No matter how good their technology is or how cutting-edge their tests are, labs that can’t send and receive HL7 messages properly will face significant challenges.

Onymos DocKnow and the HL7 Data Format

Onymos DocKnow plays a critical role right at the point where messy, real-world documents need to become clean HL7 data.

DocKnow captures and validates unstructured data in scanned requisitions or faxed medical records the moment it reaches the lab, then converts it into properly structured HL7 messages that can flow directly into a LIS, EHR, or downstream partner system.

In effect, DocKnow acts as the translation layer between the real world (where data arrives messy, inconsistent, and unstructured) and the standardized HL7 format labs need in order to connect with hospitals, reference labs, and billing systems without manual re-entry or costly errors.

→ See how Onymos can turn your documents into clean, structured HL7 data

External sources

Health Data Standards and Terminologies: A Tutorial · Rachel Dunscombe on HL7’s Role in Getting Data Ready for AI