HL7 FHIR Adoption in UK Healthcare: What Labs Need to Know

For decades, pathology laboratories across the United Kingdom have relied on HL7 version 2 messaging to exchange data with hospital information systems. It has been the backbone of order communications, results reporting, and patient administration feeds. But the landscape is shifting. NHS England's interoperability strategy is increasingly centred on FHIR — Fast Healthcare Interoperability Resources — and laboratories that fail to plan for this transition risk being left behind.

This article examines where UK pathology stands today, what FHIR brings to the table, and what practical steps laboratories and LIMS vendors should be taking now to prepare for a FHIR-enabled future.

The Current State of Laboratory Interoperability

The vast majority of UK pathology laboratories exchange data using HL7 version 2.x messages. The two workhorses of laboratory integration are the ORM message (order entry) and the ORU message (unsolicited observation result). These message types have served the industry well since the 1990s, enabling electronic requesting from ward systems and the return of structured results to the electronic patient record.

In practice, these messages rarely flow directly between systems. Most NHS trusts employ an integration engine — products such as Rhapsody, Mirth Connect (now NextGen Connect), or Microsoft BizTalk — that sits between the LIMS and the various consuming systems. The integration engine handles message routing, transformation, and protocol bridging. It translates between the slightly different HL7v2 dialects that each vendor inevitably produces.

The Limitations of HL7v2

Whilst HL7v2 has been remarkably durable, it carries well-known limitations that become increasingly problematic as healthcare systems modernise:

• Inconsistent implementations. The HL7v2 specification is deliberately loose, allowing optional fields and local extensions. In practice, this means that no two organisations implement HL7v2 in quite the same way. Every new integration requires bespoke mapping work.
• Rigid message structure. HL7v2 uses a pipe-delimited format that is difficult to extend cleanly. Adding new data elements often requires Z-segments (locally defined extensions) that further reduce interoperability.
• Point-to-point architecture. Each interface is typically a dedicated connection between two systems. Scaling this model across a modern trust with dozens of clinical systems becomes an expensive maintenance burden.
• Limited query capability. HL7v2 is fundamentally a messaging standard, not a query standard. Retrieving historical data or searching across records requires separate mechanisms.

These limitations do not mean HL7v2 is broken. It continues to work reliably in thousands of installations. But they do mean that building the next generation of connected healthcare systems on HL7v2 alone would be unnecessarily difficult.

What Is FHIR and Why Does It Matter?

FHIR (Fast Healthcare Interoperability Resources, pronounced "fire") is a standard developed by HL7 International that takes a fundamentally different approach to healthcare data exchange. Rather than defining rigid message structures, FHIR models healthcare data as a set of modular resources — discrete, self-describing units of clinical information that can be combined as needed.

The current normative release is FHIR R4, which achieved full normative status in 2019 and is the version adopted by NHS England for UK-specific profiles.

Key Characteristics of FHIR

• RESTful API design. FHIR resources are accessed over standard HTTP using familiar web patterns: GET to read, POST to create, PUT to update, DELETE to remove. Any developer comfortable with REST APIs can work with FHIR without specialist healthcare integration knowledge.
• JSON and XML support. Resources can be serialised in either JSON or XML, with JSON being the predominant choice in modern implementations. This makes FHIR data immediately accessible to mainstream development tools and frameworks.
• Self-describing resources. Each FHIR resource contains metadata about its structure, making it possible to validate data programmatically without reference to external documentation.
• Modular and extensible. Resources can be profiled (constrained) for specific use cases without breaking the base specification. This is how NHS England defines UK-specific requirements on top of the international standard.
• Built-in search. FHIR defines a rich search mechanism that allows clients to query for resources using a standardised parameter syntax. This addresses one of HL7v2's fundamental weaknesses.

Not a Complete Replacement

It is important to understand that FHIR is not intended to immediately replace all existing healthcare integration standards. HL7v2 messaging will continue to operate alongside FHIR for many years, particularly for well-established interfaces such as ADT (admission, discharge, transfer) feeds. The realistic trajectory is one of gradual migration, where new interfaces are built using FHIR and existing HL7v2 interfaces are migrated as opportunities arise — typically during system replacements or major upgrades.

FHIR Resources Relevant to Pathology

FHIR defines several hundred resource types, but pathology laboratories will primarily interact with a focused subset. Understanding these resources and how they map to the laboratory workflow is essential for planning any FHIR integration.

The Core Pathology Resources

• ServiceRequest. This is the FHIR equivalent of an order. It captures the clinical request for a laboratory investigation, including the requesting clinician, the patient, the tests requested, and any relevant clinical information. In HL7v2 terms, it replaces the ORC/OBR segments of the ORM message.
• Specimen. Represents a physical sample collected from a patient — blood, tissue, urine, or any other specimen type. The Specimen resource links to the patient and can reference the ServiceRequest that prompted its collection. It captures attributes such as specimen type, collection method, and received date/time.
• Observation. The fundamental unit of a laboratory result. Each Observation represents a single measured or observed value — a haemoglobin level, a histological grade, a culture sensitivity result. Observations can be grouped hierarchically, allowing complex panels to be represented as a tree of related results.
• DiagnosticReport. The top-level container that wraps a set of Observations into a coherent report. This is what the requesting clinician ultimately receives. It references the ServiceRequest, the Specimen(s), the performing laboratory, and the individual Observations. In histopathology, the DiagnosticReport might also contain the pathologist's narrative conclusion as an attachment or inline text.
• Patient. The patient demographic record. In UK implementations, this resource is profiled to include NHS Number as the primary national identifier, along with NHS-specific data items such as GP practice code and ethnicity categories.
• Practitioner and PractitionerRole. Represent the clinicians involved in requesting and reporting — the requesting consultant, the reporting pathologist, and any other contributors to the diagnostic process.

The Pathology Workflow in FHIR

Mapped to the pathology workflow, these resources form a clear chain: a ServiceRequest is raised by a Practitioner for a Patient. A Specimen is collected and received by the laboratory. The laboratory processes the specimen and generates Observations, which are assembled into a DiagnosticReport and returned to the requester.

SNOMED-CT Within FHIR

FHIR resources make extensive use of coded terminology, and SNOMED-CT is the preferred clinical terminology standard within the NHS. Observation codes, specimen types, body sites, and diagnostic findings can all be encoded using SNOMED-CT concept identifiers. This brings significant advantages for data quality, clinical decision support, and secondary use of data for research and audit. Laboratories that already code their findings using SNOMED-CT are well positioned for FHIR adoption; those that do not should consider beginning the journey now.

NHS England's Interoperability Strategy

NHS England (formerly NHS Digital) has been progressively building the policy and technical infrastructure for FHIR adoption across the health service. Understanding this strategic context is important for laboratories planning their integration roadmaps.

The FHIR-First Policy

NHS England's Technology Reference Architecture now mandates a "FHIR-first" approach for new integrations. Where a FHIR-based standard exists for a given use case, new implementations should use it in preference to older messaging standards. This does not mean HL7v2 interfaces must be ripped out immediately, but it does mean that the direction of travel is clear and irreversible.

The NHS Spine and Its Evolution

The NHS Spine — the national infrastructure that supports services such as the Personal Demographics Service (PDS), the Summary Care Record (SCR), and the Electronic Prescription Service (EPS) — has been progressively adopting FHIR APIs. The PDS FHIR API, for example, allows systems to look up and verify patient demographics using standard FHIR Patient resources, replacing the older Spine Mini Service Provider (SMSP) approach.

For pathology laboratories, the PDS FHIR API is particularly relevant. Verifying patient identity against the national demographic record using the NHS Number is a fundamental requirement for safe laboratory practice, and the FHIR-based PDS API offers a cleaner, more modern integration path than its predecessors.

GP Connect and Beyond

GP Connect is another notable FHIR-based programme. It provides FHIR APIs for accessing GP practice data, including patient records, appointments, and structured clinical information. Whilst not directly a pathology interface, GP Connect demonstrates the pattern that NHS England intends to replicate across all care settings: standardised FHIR APIs that any conformant system can consume.

UK Core FHIR Profiles

One of the most important developments for UK healthcare IT is the UK Core FHIR profile set. These profiles define NHS-specific constraints and extensions on top of the base FHIR R4 specification. For example, the UK Core Patient profile mandates the inclusion of the NHS Number and defines value sets for ethnicity and religious affiliation that align with NHS Data Dictionary requirements.

For pathology, the UK Core profiles for DiagnosticReport, Observation, Specimen, and ServiceRequest define how these resources should be structured in an NHS context. LIMS vendors implementing FHIR support should conform to these profiles rather than building against the unconstrained base specification.

The UK Core profiles are the authoritative reference for how FHIR should be implemented in NHS settings. Any LIMS vendor building FHIR interfaces for the UK market should treat conformance to these profiles as a baseline requirement.

What This Means for LIMS Vendors and Laboratories

The shift towards FHIR has significant implications for both LIMS vendors developing integration capabilities and for laboratories planning their IT strategies.

FHIR Endpoint Support

LIMS systems will increasingly need to expose and consume FHIR-based APIs. At a minimum, this means being able to accept incoming ServiceRequest resources (electronic orders) and produce DiagnosticReport bundles (results). More mature implementations will also support subscription-based notifications, where consuming systems are automatically alerted when new results are available, rather than polling for updates.

The Migration Path from HL7v2

Realistically, no laboratory will switch from HL7v2 to FHIR overnight. The migration will involve a period of dual-running, where both HL7v2 and FHIR interfaces operate in parallel. Integration engines will play a crucial role during this transition, potentially translating between HL7v2 and FHIR to allow systems at different maturity levels to communicate.

Laboratories should expect this dual-running period to last several years. The pace of transition will vary significantly between trusts, depending on their existing integration landscape, available funding, and the FHIR readiness of their clinical systems.

SNOMED-CT as the Foundation

Regardless of whether data is exchanged via HL7v2 or FHIR, SNOMED-CT is becoming the non-negotiable standard for clinical terminology in the NHS. Laboratories that have not yet adopted SNOMED-CT coding for their results should treat this as a priority. SNOMED-CT coding is a prerequisite for meaningful FHIR interoperability — without it, the clinical content of FHIR resources is significantly diminished.

API-First Architectures

LIMS systems built with an API-first architecture — where core data and functionality are exposed through well-defined APIs rather than being locked inside a monolithic application — are inherently better positioned for FHIR adoption. If a LIMS already exposes case data, specimen information, and results through REST APIs with proper authentication, the step to FHIR-conformant endpoints is an incremental evolution rather than a fundamental rearchitecture.

Similarly, systems that already support standards-based authentication mechanisms (such as X.509 certificates or OAuth 2.0) are better prepared for the security requirements of FHIR-based data exchange, which typically involves SMART on FHIR or similar authorisation frameworks.

Planning Your Migration

For laboratory managers and IT leads, the prospect of migrating to FHIR can feel daunting. The good news is that this is not a cliff-edge change. There is time to plan, but planning should start now.

Audit Your Current Interfaces

Begin by cataloguing every integration your laboratory currently operates. For each interface, document the standard used (HL7v2.3, v2.4, proprietary, etc.), the integration engine involved, the data flows (orders in, results out, ADT feeds), and the consuming system. This inventory will form the basis of your migration roadmap.

Engage with Your Trust Integration Team

Most NHS trusts have a dedicated integration team or a recognised lead for interoperability. Engage with them early. Understand the trust's broader digital strategy and where FHIR adoption fits within it. Your laboratory's FHIR migration should align with the trust-wide approach, not operate in isolation.

Assess Your LIMS Vendor's FHIR Roadmap

Have a frank conversation with your LIMS vendor about their FHIR capabilities and roadmap. Key questions include:

• Does the LIMS currently support any FHIR resources? If so, which ones and to what level of conformance?
• Is UK Core profile conformance on the roadmap? What is the expected timeline?
• Can the LIMS expose a FHIR server endpoint, or does it rely on an external facade or integration engine for FHIR translation?
• How does the LIMS handle SNOMED-CT coding? Is it integrated into the data model or bolted on as an afterthought?

Test with NHS FHIR Reference Servers

NHS England provides FHIR reference servers and sandbox environments that allow vendors and trusts to test their implementations against the UK Core profiles. Take advantage of these resources. Early testing against reference implementations catches conformance issues before they become problems in live environments.

Prioritise High-Value Interfaces

Not all interfaces need to migrate simultaneously. Focus first on the interfaces that deliver the most value when modernised:

1. Order communications. Electronic requesting from the EPR to the LIMS is the most natural starting point. FHIR-based ordering can support richer clinical context than HL7v2 ORM messages, improving the information available to the laboratory at the point of request.
2. Results reporting. Returning structured, coded results as FHIR DiagnosticReport bundles enables downstream innovation — clinical decision support, population health analytics, and automated clinical audit become significantly easier when results are in a standardised, computable format.
3. Patient demographics. Migrating to the PDS FHIR API for demographic verification is a relatively contained project that delivers immediate benefits in data quality and patient safety.

Do Not Rush

Perhaps the most important piece of advice: do not panic. HL7v2 interfaces that are working reliably today will continue to work for years to come. The NHS is not going to mandate an overnight switchover. The goal is to ensure that your laboratory is on a clear trajectory towards FHIR readiness, not to achieve it by next quarter.

That said, laboratories that begin planning now will be in a far stronger position than those that wait until FHIR adoption becomes an urgent procurement requirement. The organisations that will navigate this transition most smoothly are those that treat it as a strategic evolution, not a reactive scramble.

The transition from HL7v2 to FHIR is not a question of if, but when. Laboratories that start planning today — auditing interfaces, engaging with trust teams, and pressing vendors on their FHIR roadmaps — will be best positioned for the connected healthcare systems of the future.