Speaking the Same Language: HL7, FHIR, and What Data Interoperability Means for Public Health Labs
If you’ve spent any time in a meeting about laboratory data systems lately, you’ve almost certainly heard the acronyms: HL7. FHIR. ELR. ETOR. They surface in conversations about software upgrades and federal requirements, often with the assumption that everyone in the room already knows what they mean.
Many don’t — and that’s not a gap to be embarrassed about. But understanding these standards
does matter, because the decisions a public health lab makes about data exchange have real
consequences: how quickly results reach providers and health departments, how reliably
disease surveillance is fed, and how prepared the lab is for the next public health emergency.
The Problem They’re Solving
Public health labs don’t operate in isolation. A specimen collected at a clinic gets tested, and the result needs to reach the ordering provider, the state health department, a surveillance system, and possibly the CDC — passing through multiple software platforms along the way. For decades, each of those systems spoke a slightly different language, forcing staff to manually reenter, reformat, or translate data. The consequences were predictable: delays, transcription errors, and gaps in the surveillance data public health officials depend on.
Data interoperability is the goal of having those systems exchange information automatically and accurately. HL7 and FHIR are the shared grammar that makes it possible.
HL7 v2: The Workhorse Standard
HL7 version 2 has been the backbone of electronic lab reporting (ELR) and electronic test order and results (ETOR) in the US for decades. When a clinician orders a test, an ETOR message travels from their computer directly to the laboratory system. Once the test is complete, the ETOR loop closes by sending the final results back to the doctor. When a public health laboratory sends a reportable disease result to a state surveillance system, that transmission is almost certainly formatted as an HL7 v2 message — a structured format that specifies exactly where each piece of data lives: patient demographics, the test performed, the result value, and the reference range.
It works reliably, but it has real limitations. HL7 v2 predates the modern internet. For ETOR, this means different clinics often use different codes for the exact same medical test. Because of this, two systems both claiming to “speak HL7 v2” may still require significant custom mapping work before they can exchange data cleanly — a familiar frustration for anyone who has managed a lab interface project.
FHIR: The Modern Standard
FHIR — pronounced “fire,” short for Fast Healthcare Interoperability Resources — is HL7’s answer to those limitations. Built on modern web technologies (including RESTful APIs, JSON, and standard internet protocols), FHIR is far easier to implement and extend than its predecessors. Its core unit is the “resource” — a modular, self-contained packet of data. A Patient resource carries demographics. An Observation resource carries a test result. A Diagnostic Report bundles a full panel.
FHIR adoption is now a federal policy priority. The 21st Century Cures Act requires certified health IT systems to support FHIR-based exchange, and the CDC’s Data Modernization Initiative is explicitly moving public health data reporting toward FHIR. The HL7 v2 interfaces that have served labs reliably for years will eventually need FHIR-based complements — and in some cases, replacements.
What This Means in Practice
Two supporting standards are worth knowing alongside HL7 and FHIR: LOINC provides standardized codes for laboratory test names, and SNOMED CT provides standardized codes for result values. Together, they ensure that a “detected” Measles PCR result means the same thing to every system that receives it, regardless of which lab produced it. Maintaining accurate LOINC and SNOMED mappings for your test menu is an ongoing task.
For laboratory directors and LIMS administrators, the practical takeaways are simple:
- Interface projects require real investment.
– Building and validating connections to surveillance systems takes time and expertise. Budget for it, and make sure your LIMS vendor brings experience, not just promises. - Middleware partnerships lower the cost of connectivity.
– Not every LIMS speaks HL7 v2 and FHIR out of the box, so ensure they partner with leading middleware providers to deliver seamless ELR and ETOR. - Interoperability reduces manual burden.
– Every result that flows automatically through a validated interface is one your staff didn’t have to report by hand — and one less opportunity for error. - Keep your code mappings current.
– LOINC and SNOMED CT are updated regularly, and outdated mappings are a common source of reporting failures. Assign ownership of this task and build it into your regular maintenance cycle — don’t let it fall through the cracks. - Plan for FHIR now, even if you don’t need it yet.
– The CDC’s Data Modernization Initiative is advancing quickly. Labs that wait until a FHIR mandate arrives will face compressed timelines and implementation pressure. Ask your LIMS vendor today what their FHIR roadmap looks like.
The goal is a public health data ecosystem where information flows quickly, accurately, and completely from specimen collection to the people who need it. Your LIMS sits at a critical point in that flow. Choosing software that takes these standards seriously is foundational to getting there.
The OpenELIS Foundation develops and supports open-source laboratory information management software for public health laboratories across the United States and its territories. To learn more about how OpenELIS supports electronic lab reporting and data interoperability, Contact Us or Book a Demo.
Data Interoperability Newsletter
This article was drafted with the assistance of Claude 3.7 Sonnet (Anthropic, 2025) and edited for style and accuracy by the OpenELIS Foundation staff.