Customer Portal Help Desk: 1-800-834-8618
LIMS IQ Integration guide DOC FHIR-FOR-CLINICAL-LABS
REV 2026-08

FHIR for Clinical Labs — HL7 FHIR R4 Resources, Patterns, and Where LIMS IQ Fits

HL7 FHIR R4 for clinical labs: the ServiceRequest, Specimen, Observation, and DiagnosticReport resources lab interfaces use, and how FHIR meets HL7 v2.x.

Request a demo Read the guide

Quick answer: FHIR (Fast Healthcare Interoperability Resources) is the modern REST and JSON healthcare interoperability standard from HL7. In clinical labs, FHIR R4 carries lab orders (ServiceRequest), specimen detail (Specimen), discrete results (Observation), rolled-up reports (DiagnosticReport), and patient demographics (Patient) — the same flows HL7 v2.x covers, in a modern REST representation. Most production interfaces still run HL7 v2; FHIR is growing alongside.

Clinical labs increasingly hear about FHIR from EMR vendors, regulatory mandates (21st Century Cures Act, ONC rules), and modern EMR APIs. The questions lab IT directors and LIS analysts ask: what is FHIR exactly, what resources are involved, how does it differ from HL7 v2, and what does a real FHIR-based lab interface look like? This guide answers those.

What FHIR is

FHIR is the fourth major version of HL7’s interoperability work, published as a free, open standard. Where HL7 v2.x is pipe-delimited segments over MLLP, FHIR is:

  • REST + JSON — discrete resources (Patient, Observation, ServiceRequest) accessed by HTTP verbs (GET, POST, PUT, DELETE) over HTTPS.
  • Resource-based — each data type is a separate resource with a defined schema, identifiers, and references between resources.
  • Easier for modern stacks — web apps, mobile apps, AI agents, and payer systems consume FHIR more easily than HL7 v2.x because JSON parses with standard tooling.
  • Bound to required code sets — LOINC for lab observations, SNOMED CT for organisms and findings, UCUM for units of measure.

FHIR R4 is the current widely-deployed normative release (published 2019). FHIR R5 is the latest release (2023) but production adoption is still primarily R4.

Why FHIR adoption is growing

Three forces are pushing FHIR adoption in healthcare and clinical labs:

  1. 21st Century Cures Act + ONC interoperability rules — U.S. federal regulation that requires certified health IT to expose FHIR APIs, eliminating information blocking. EMR vendors must offer FHIR endpoints to customer-authorized third-party apps.
  2. Modern EMR APIs — Epic (Epic on FHIR), Cerner/Oracle Health, Athenahealth, eClinicalWorks, and others now publish FHIR R4 APIs for ambulatory order placement, result retrieval, and patient-facing apps.
  3. Direct-to-consumer + mobile flows — patient-facing apps, employer-driven testing programs, telehealth integrations, and payer apps prefer FHIR over HL7 v2 because mobile/web stacks consume REST+JSON natively.

For clinical labs, FHIR matters wherever the interface partner runs modern infrastructure or where federal regulation requires it. Established hospital-EMR-to-LIS interfaces still typically run HL7 v2 because the infrastructure has been there for decades.

Core FHIR resources for lab interfaces

The clinical-lab side of FHIR centers on a small set of resources. Each maps roughly to an HL7 v2 message or segment.

ServiceRequest

The lab order. Equivalent to HL7 v2 ORM.

  • What it contains — the test or panel being ordered, the subject (Patient reference), the requester (Practitioner or PractitionerRole), priority (routine, urgent, stat), occurrence (when to perform), reasonCode (clinical indication).
  • Direction — flows from the EMR/ordering system to the LIS.
  • Identifiers — placer order number (the EMR’s order ID), filler order number (the LIS accession), encounter context.

Specimen

The sample being tested.

  • What it contains — type (blood, urine, swab), collection method, collection time, collector (Practitioner reference), container, processing notes, current status.
  • Direction — typically created at accessioning in the LIS, referenced by the ServiceRequest and Observation.
  • Identifiers — the specimen’s accession ID, container ID, parent specimen if aliquoted.

Observation

A single discrete result value. Equivalent to HL7 v2 OBX.

  • What it contains — the analyte (LOINC code), the value (Quantity with UCUM units, or string, or coded), reference range, interpretation (high, low, abnormal, critical), specimen reference, status (preliminary, final, corrected, amended).
  • Direction — created in the LIS when a result is finalized, referenced by DiagnosticReport.
  • One per analyte — a CBC produces ~20 Observations; a comprehensive metabolic panel ~14; a single chemistry test = 1 Observation.

DiagnosticReport

The rolled-up lab report. Equivalent to HL7 v2 ORU.

  • What it contains — the test or panel reported, references to the constituent Observations, the subject (Patient), the issuer (lab), the issued time, the conclusion text (interpretive narrative for anatomic pathology or microbiology).
  • Direction — flows from the LIS to the EMR or downstream consumer.
  • One per panel — a CBC = 1 DiagnosticReport referencing ~20 Observations; a chemistry panel = 1 DiagnosticReport with ~14 Observations.

Patient

Demographics. Equivalent to HL7 v2 PID.

  • What it contains — identifiers (MRN, insurance ID), name, birthDate, gender, address, contact, insurance (Coverage reference), language.
  • Direction — typically created in the EMR and referenced by all other lab resources.

Practitioner / PractitionerRole

The ordering or signing clinician.

  • What it contains — identifier (NPI), name, qualifications, role at the organization.
  • Direction — typically referenced by ServiceRequest (requester) and DiagnosticReport (performer / interpreter).

Supporting resources

  • Coverage — patient insurance for billing flows.
  • Encounter — the visit context (inpatient, outpatient, ambulatory).
  • Provenance — audit trail (who did what when).
  • MessageHeader — for FHIR Messaging (used when FHIR carries entire workflow messages, less common than REST resource access).

FHIR vs HL7 v2.x — practical differences

Dimension HL7 v2.x FHIR R4
Format Pipe-delimited segments JSON (or XML)
Transport MLLP, SFTP, HTTPS HTTPS REST
Granularity Whole-message exchanges Resource-by-resource access
Tooling Specialized HL7 parsers Standard JSON + REST tooling
Versioning Strict per-version implementations Profiles + version negotiation
Maturity 1990s — deeply embedded 2019 R4 normative — growing
EMR adoption Universal Modern EMRs, ambulatory rollouts
Lab adoption Universal Selective — modern partners, DTC, mobile
ELR Standard (v2.5.1 per APHL) Pilot in some states

Most production lab interfaces today are HL7 v2 because the entrenched ecosystem (EMRs, reference labs, instrument vendors, state agencies) already speaks v2. FHIR is added alongside for specific use cases: ambulatory EMRs with modern APIs, direct-to-consumer apps, payer integrations, and new public-health programs.

A practical FHIR-based lab interface

A simplified flow for an ambulatory clinic ordering a lab test through a FHIR-enabled EMR to a FHIR-capable LIS:

  1. Provider orders the test in the EMR. The EMR creates a ServiceRequest resource with subject (Patient reference), code (LOINC test code), requester (Practitioner reference), priority, and occurrence.
  2. EMR pushes the ServiceRequest to the lab’s FHIR endpoint. HTTPS POST /ServiceRequest, authenticated via SMART on FHIR (OAuth 2.0) or mutual TLS.
  3. LIS receives the order. A new accession is created internally; the LIS optionally responds with a 201 Created and a ServiceRequest resource echoing back the lab’s filler order number.
  4. Specimen is collected and accessioned. The LIS creates a Specimen resource referencing the ServiceRequest, with collection time, type, container.
  5. Testing runs. Instrument interfaces remain mostly HL7 v2 or ASTM at this layer — the FHIR vs v2 question is the upstream EMR side, not the bench side.
  6. Result finalized. The LIS creates Observation resources (one per discrete value) and a DiagnosticReport that references them, with status = “final”.
  7. LIS pushes the DiagnosticReport back to the EMR’s FHIR endpoint. Or the EMR queries the LIS’s FHIR API for new results.
  8. Result lands in the patient chart. The EMR displays the Observations and DiagnosticReport to the ordering clinician.

The same workflow runs over HL7 v2 today using ORM, ORU, OBX, OBR, MSH segments. The difference is the wire format and tooling, not the workflow logic.

Where LIMS IQ fits

LIMS IQ’s documented production interface scope includes a built-in HL7 engine for ORM orders and ORU results, plus configurable API and web-service connections for custom applications and partners. For a FHIR-based project, confirm the required resources, data direction, authentication, and implementation profile during discovery rather than assuming universal R4 coverage.

  • Documented core — built-in HL7 ORM/ORU connectivity for electronic orders and results, with API and web-service patterns for custom integrations.
  • Partner-specific — connections to major EMRs are configured to each partner’s message definitions and code translations.
  • Configuration-driven — message definitions, code translations, permissions, and routing criteria are managed per interface connection.

See the HL7 LIS integration feature page for the v2 message types, the EMR/EHR integrations feature page for the vendor coverage, and the integrations hub for the full integration scope.

Request a demo to review your partner’s interface requirements, or contact the team with FHIR-specific resource, profile, and authentication questions.

Frequently asked

What is FHIR and how is it used in clinical labs?
FHIR (Fast Healthcare Interoperability Resources) is the modern REST and JSON healthcare interoperability standard published by HL7. In clinical labs, FHIR R4 carries the same data flows that HL7 v2.x carries — orders, results, demographics, specimen detail — but as discrete REST resources (ServiceRequest, Observation, DiagnosticReport, Patient, Specimen) over HTTPS rather than pipe-delimited messages over MLLP. FHIR is increasingly required by modern EMR APIs, direct-to-consumer apps, payer integrations, and CMS programs. Most production LIS-EMR interfaces still run HL7 v2 today, with FHIR adoption growing alongside.
What's the difference between FHIR and HL7 v2.x for lab interfaces?
HL7 v2.x is the dominant production protocol — pipe-delimited messages (ORM, ORU, ADT, DFT, MDM) over MLLP/SFTP/HTTPS, mature, widely deployed since the 1990s. FHIR R4 is the modern equivalent — REST + JSON, easier to consume from web apps and modern stacks, better-suited to selective queries and resource-by-resource access. The lab workflows are the same — orders, results, demographics — but the on-the-wire representation differs. Most labs run HL7 v2 for established EMR partners and FHIR for newer or specialty integrations.
Which FHIR resources matter for a clinical lab interface?
The core lab-side resources are: ServiceRequest (the lab order, equivalent to HL7 v2 ORM), Specimen (the sample being tested, with collection detail), Observation (each discrete result value, equivalent to HL7 v2 OBX), DiagnosticReport (the rolled-up lab report referencing observations, equivalent to HL7 v2 ORU), Patient (demographics, equivalent to HL7 v2 PID), and Practitioner (ordering provider). Supporting resources include Coverage (insurance), Encounter (the visit), and Provenance (audit trail). The lab’s FHIR interface reads ServiceRequest from the EMR and writes Observation + DiagnosticReport back.
How should a lab scope FHIR with LIMS IQ?
LIMS IQ’s documented integration scope includes a built-in HL7 engine for ORM orders and ORU results, plus configurable API and web-service connection patterns. For a FHIR project, confirm the partner’s required resources, data direction, authentication, and implementation profile with the LIMS IQ team during discovery rather than assuming one generic R4 endpoint covers every workflow. The documented connection model lives on the HL7 LIS integration and EMR/EHR integrations feature pages.
Will FHIR replace HL7 v2.x for lab interfaces?
Not in the near term. HL7 v2.x is deeply embedded in production EMR-LIS interfaces, lab instrument vendors, reference-lab partners, and state public-health ELR systems. The 21st Century Cures Act and ONC interoperability rules have pushed FHIR adoption, but the migration from HL7 v2 happens on the order of decades, not years. Modern clinical-lab platforms support both: HL7 v2 for existing deployments and FHIR R4 for new integrations, modern EMR APIs, and direct-to-consumer use cases.
How does FHIR ELR work?
FHIR-based electronic laboratory reporting is an emerging alternative to HL7 v2.5.1 ELR. The FHIR-based pattern uses MessageHeader, DiagnosticReport, Observation, Specimen, and Patient resources sent as a Bundle to a public-health agency’s FHIR endpoint. Some state public-health systems are piloting FHIR ELR; most still require HL7 v2.5.1 per APHL implementation guides. See the ELR guide for the current production pattern and the agency-by-agency variability.