What is FHIR, and what it changes for laboratories
FHIR — Fast Healthcare Interoperability Resources — is the current healthcare data exchange standard. Where HL7 v2 sends messages, FHIR exposes resources over an API. For laboratories, the practical difference is that data becomes addressable rather than only transmittable.
Resources instead of messages
FHIR models healthcare information as discrete resources — a Patient, a Practitioner, a ServiceRequest, a Specimen, an Observation, a DiagnosticReport — each with a defined structure and a stable identity, retrievable over a normal REST API in JSON.
That difference sounds architectural and is actually operational. With v2, you receive what was sent when it was sent. With FHIR, you can ask: give me this patient's observations from the last year. The querying direction is new.
The resources that map to laboratory work
- Patient — the person the specimen belongs to
- Practitioner and Organization — the ordering provider and their facility
- ServiceRequest — the order itself
- Specimen — what was collected, when, and in what container
- Observation — an individual result value with its reference range and interpretation
- DiagnosticReport — the report grouping observations, with the narrative and the signing detail
- Coverage — insurance information, relevant to the eligibility side
What FHIR genuinely improves
- Query-based access rather than only push-based delivery
- Ordinary web technology — REST, JSON, OAuth — instead of bespoke tooling
- Explicit, versioned resource definitions that are easier to validate against
- A path to patient-facing access, which regulation increasingly expects
- Far lower barrier for building applications against clinical data
What it does not solve
FHIR standardizes structure. It does not standardize meaning. Two systems can both be correct FHIR and still disagree about which code set identifies a test, how a panel is decomposed into observations, or which identifier is authoritative for a patient.
Terminology mapping — LOINC for observations, SNOMED for clinical concepts — remains real work. FHIR makes the container consistent; it does not make the contents interchangeable.
The honest summary: FHIR removes the transport and parsing problems. The semantic problems are still yours.
What 'FHIR-ready' should mean
The term is used loosely enough to be nearly meaningless, so it is worth defining. A platform that is genuinely FHIR-ready has a data model whose entities map cleanly onto FHIR resources — a distinct specimen concept, observations that carry their own reference ranges and interpretations, a report that groups them, a service request that is not conflated with the result.
That structural alignment is what makes adding FHIR endpoints an interface project rather than a data model rewrite. A vendor claiming FHIR-readiness while storing results as free text on an order record is claiming something they cannot deliver.
It is equally worth being clear about the difference between FHIR-ready and FHIR-certified. Certification is a formal process. Readiness is an architectural property. Conflating the two is the most common overclaim in this area.