HL7 is the standard format labs and hospitals use to send patient and test data between different systems, like from a lab’s LIS to a hospital’s electronic health record.
HL7 v2 is the older, text-based version and is still the most common one used for sending lab orders and results today.
FHIR is a newer, more modern version of HL7 that’s easier for apps and websites to work with, and it’s increasingly used for things like patient portals and data sharing with insurers.
HL7 is working to make FHIR more AI-ready, since large, messy real-world FHIR bundles can trip up even very capable AI systems, and “probably right” isn’t reliable enough for healthcare data.
Using HL7 helps labs cut down on manual data entry mistakes, get results to doctors faster, and stay compliant with healthcare regulations.
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|^~\&|LAB|HOSPITAL|EHR|CLINIC|202608121030||ORU^R01|MSG00001|P|2.3”
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.
Onymos works with clinical laboratories and other healthcare organizations to modernize their most complex document and data workflows with intelligent automation.
Use Onymos for: diagnostic and clinical workflows / billing and claims / compliance
Connect with our team to explore how Onymos solutions can maximize efficiency, minimize costs, and drive real, scalable growth.
AI in the lab. Workflow automation at scale. Digital front doors for hospitals and clinics. Healthcare and life sciences are changing fast. Are you ready? Subscribe to our blog for:
