FHIR vs HL7 v2 for Laboratories: Which One Do You Actually Need?

Every few months a lab manager or hospital IT lead asks the same question: should we be moving to FHIR? The honest answer depends on which part of the lab you are talking about. FHIR and HL7 v2 are not rivals competing for the same job. They sit at different layers of the same workflow, and most labs will run both for a long time.

This guide explains where HL7 v2 came from and why laboratories still depend on it, what FHIR changes, why analyzers themselves are mostly indifferent to the argument, where a bridge layer sits between them, and how to migrate without a rip-and-replace.

Where HL7 v2 Came From and Why Labs Still Run It

HL7 version 2 dates from the late 1980s and became the dominant messaging standard in healthcare. A v2 message is a sequence of pipe-delimited segments: a header, patient details, an order, and one or more observations. Lab results typically travel as ORU messages, and orders as ORM or similar. If you want the segment-level detail, see HL7 ORU and ORM lab messages explained.

Labs still run it for three practical reasons. First, it works: decades of hospital information systems, LIS products and analyzers speak it. Second, it is cheap to implement relative to rewriting everything. Third, replacing it offers no direct benefit to a technologist who just needs results to appear in the right patient record. A stable interface that has run for ten years is an asset, not technical debt.

Its weakness is looseness. HL7 v2 permits many local variations, so two systems that both claim v2 compliance can still fail to interoperate until someone sits down and maps the differences. That is a real cost, but it is a known and manageable one.

What FHIR Changes

FHIR, Fast Healthcare Interoperability Resources, takes a different approach. Instead of a stream of delimited segments, it models data as discrete resources (a Patient, an Observation, a DiagnosticReport) exchanged over web APIs using JSON or XML. Developers familiar with REST find it approachable, and it is well suited to apps, portals, and data sharing between organisations.

Its advantages are real:

• Developer-friendly. Standard web tooling, readable payloads, easier onboarding of new software.
• Better for sharing. Patient-facing apps, health information exchanges and regulatory data requests increasingly expect an API.
• More structured. Resources are more explicit than v2 segments, which can reduce ambiguity.

What it does not do is change what an analyzer sends. FHIR is an exchange model between software systems, not a bench instrument protocol.

Instrument Reality: Analyzers Speak v2 and ASTM, Not FHIR

This is the point most FHIR-versus-v2 discussions skip. The device at the bench does not choose between the two standards. Haematology, chemistry and immunoassay analyzers overwhelmingly talk in HL7 v2, ASTM E1394, or something vendor-specific, over RS-232, TCP/IP or a file server. Some use fixed-width records with no delimiters at all, or XML exchanged through a file transport. See what ASTM E1394 is and HL7 vs ASTM for the main families.

The consequence is simple. Whatever you do with FHIR upstream, someone still has to translate between the analyzer's dialect and the rest of your systems. A FHIR-ready hospital information system does not remove the need to parse an instrument's message.

Where a Bridge Layer Sits

The architecture most labs end up with looks like this:

1. Instrument side: analyzers speak v2, ASTM, or their own format.
2. Bridge layer: middleware connects, parses, validates, standardises and de-duplicates.
3. Systems side: the HIS or LIS receives whatever it supports, which may be v2 today and an API tomorrow.

The bridge layer is what lets you change the upstream interface without touching every analyzer. LISBridge sits at step two: it connects to instruments by RS-232, TCP/IP or file transport, parses ASTM E1394, HL7 and custom protocols in real time, and delivers to your HIS or LIMS. It keeps the raw instrument message alongside every parsed result, so you can always trace what the analyzer actually sent. For how this layer works in general, read how lab middleware works.

Note what this does not claim: this article does not promise that any one product will cover every possible FHIR scenario. If FHIR output is a hard requirement for your project, confirm the exact delivery method you need with any vendor you evaluate, including us, before you commit.

Migration Without a Rip-and-Replace

If your organisation does want to move toward FHIR, a staged approach is almost always safer than a switch-over.

1. Inventory what you have

List every instrument, its protocol, and every system it feeds. Many labs discover interfaces nobody remembered.

2. Decouple instruments from destinations

Put a bridge layer between them so analyzers are configured once, not once per downstream system.

3. Change one destination at a time

Move the first downstream integration while everything else stays on v2. Compare results from both paths during a parallel run.

4. Keep rollback simple

If the new path misbehaves, you should be able to revert one connection, not the whole laboratory.

5. Do not touch working analyzers for the sake of it

An analyzer interface that is stable and validated needs no reason to change just because the data standard upstream has.

So Which Do You Actually Need?

For analyzer connectivity: HL7 v2, ASTM and instrument-specific dialects, handled by middleware. For sharing data with apps, portals and other organisations: FHIR is increasingly relevant, and worth planning for. For most laboratories the realistic answer is both, with a bridge layer in the middle so that neither side forces changes on the other.

If you want to see how the instrument side works in more detail, the HL7 protocol page and the HL7 and ASTM support overview cover what LISBridge parses today.

A Practical Decision Rule

When a vendor pitches FHIR, ask which problem it solves for you this year. If the answer is "your portal needs patient-facing results" or "a regulator wants API access", FHIR belongs on the roadmap. If the answer is "your analyzers will be easier to connect", it will not be, because the instrument end of the chain is unchanged. Keep the two conversations separate: one about how data leaves the bench, one about where it goes afterwards. Labs that blur them tend to over-spend on the upstream project and under-invest in the instrument layer where most daily failures actually occur.

It also helps to remember who bears the risk. A failed FHIR integration is usually visible and recoverable. A subtly wrong analyzer parse, such as a unit mix-up or a QC result in a patient record, is far harder to detect. Spend your validation effort accordingly.

Frequently Asked Questions

Is HL7 v2 obsolete?

No. It remains the working standard for most lab-to-system messaging and analyzer communication, and is not going away soon.

Do analyzers support FHIR?

Instruments at the bench generally speak HL7 v2, ASTM E1394 or vendor-specific formats. FHIR is typically an exchange layer between software systems rather than something the analyzer itself sends.

Do I have to choose between FHIR and HL7 v2?

Usually not. Different layers of the workflow use different standards, and a bridge layer lets them coexist.

Will moving to FHIR fix inconsistent analyzer data?

No. Inconsistency begins at the instrument, with local dialects and variations. Those still need parsing and validation before any downstream standard is applied.

What should I ask a vendor about FHIR?

Ask exactly which interfaces they deliver to today, which are on a documented roadmap, and which instruments they parse natively. Get it in writing.

Start With the Instrument Side

Whatever standard you choose upstream, reliable instrument connectivity comes first. LISBridge supports 37 lab instruments, 17 of them bidirectional, and a hospital with five analyzers eliminated about two hours a day of manual transcription.

Start your free trial — no credit card required. lisbridge.com/pricing