NHS organisations and digital health vendors are moving rapidly towards modern, standards-based interoperability. HL7 and FHIR remain central to this shift, yet many teams still face challenges translating standards into workable integration architecture. This guide breaks down the practical steps: how APIs should be designed, what workflows matter most, and the best practices that help providers, vendors, and integrators deliver safe, secure, and scalable interoperability.

Why HL7/FHIR Integration Matters Now in the UK

The NHS is deep into its digital modernisation cycle. Trusts and Integrated Care Systems (ICSs) are investing in shared care records, virtual wards, clinical decision support tools, and patient-facing applications. Without robust interoperability, many of these initiatives stall.

Several forces make HL7 and FHIR more important than ever:

• ICS-wide data sharing now requires structured, standardised formats (NHS England 2024).

• Point solutions: virtual wards, ePMA, theatre systems, diagnostics platforms—must plug into EPRs rather than operate in isolation.

• FHIR UK Core has matured, giving implementers a consistent baseline for exchanging clinical information.

• GDPR and UK data governance expectations continue to strengthen, raising the bar for secure API design.

Yet the reality on the ground is familiar: some systems still rely heavily on HL7 v2 messages, while others are moving to FHIR-first APIs. Most environments end up hybrid.

This makes practical guidance essential.

Understanding the Standards: HL7, HL7 v2, and FHIR

HL7 v2 (Legacy but Critical)

HL7 v2 remains the backbone of many hospital systems—PAS, lab, radiology, and theatre systems. It is fast, compact, and proven, but not designed for modern app ecosystems.

Strengths:

• Lightweight and event-driven

• Widely supported

• Reliable for high-volume operational messaging

Limitations:

• Non-standardised implementations vary across vendors

• Harder to scale for API-based apps

• Limited in handling complex structures or richer clinical semantics

FHIR (Fast Healthcare Interoperability Resources)

FHIR introduces web-friendly, modular resources delivered via RESTful APIs.

Advantages:

• JSON/XML support

• Easy to use for app developers

• Resource-based structure mirrors real clinical concepts

• Clear UK Core profiles for allergy, medication, observation, etc.

• Strong adoption in NHS programmes (e.g., GP Connect, Shared Care Record)

Most modern health systems should adopt FHIR for new interfaces, while supporting HL7 v2 where necessary.

Architecture Patterns for HL7/FHIR Integration

No single architecture fits all. However, most NHS organisations land on one of these models:

1. Interface Engine (HL7 v2 Hub) + FHIR Gateway

Common in trusts with older PAS/EPR deployments.

How it works

• HL7 v2 messages feed into an integration engine.

• Engine transforms selected messages into FHIR resources.

• FHIR APIs expose structured data to partner applications.

Best for:

• Blending legacy systems with modern APIs.

• Minimising change to core clinical systems.

2. FHIR-First Architecture with Event-Driven Messaging

Preferred by modern EHRs and digital health vendors.

How it works

• Clinical systems publish FHIR events (e.g., Encounter, Observation).

• Event broker routes messages to subscribers.

• APIs remain clean, versioned, and modular.

Best for:

• High scalability

• Microservices environments

• Mobile and frontline apps needing real-time data

3. ICS-Level Shared Data Platform (FHIR Repository + APIs)

A rising approach across the UK.

How it works

• Multiple trusts push data (HL7 or FHIR) into an ICS repository.

• Repository stores FHIR-normalised data.

• Providers and vendors access data through governed APIs.

Best for:

• Population health

• Shared care records

• Cross-organisation workflows

Key Workflows That Make-or-Break Integration

1. Patient Demographics & Identity

• Syncing patient identifiers across PAS, EPRs, and third-party tools

• Managing NHS Number, local IDs, and MPI lookups

Common FHIR resources:

• Patient, RelatedPerson

2. Appointments & Scheduling

Critical for virtual wards, outpatient apps, and remote monitoring.

FHIR resources:

• Appointment, Schedule, Slot

3. Observations & Results

The highest-value integration for clinical insights.

FHIR resources:

• Observation, DiagnosticReport

HL7 v2 messages often mapped:

• ORU^R01, OBR, OBX

4. Medications & ePMA Interoperability

A sensitive area requiring safe mapping.

FHIR resources:

• Medication, MedicationRequest, MedicationAdministration

5. Documents, Referrals, and Care Plans

FHIR supports structured and unstructured formats.

Resources:

• DocumentReference, CarePlan, ServiceRequest

Best Practices for HL7 & FHIR API Integration

1. Align to FHIR UK Core

Avoid custom resource definitions unless absolutely necessary. Deviations create long-term maintenance overhead.

2. Version APIs Early

FHIR evolves quickly. Version your API endpoints:

/fhir/v1/Observation
/fhir/v2/Observation

3. Consider Performance from Day One

FHIR resources can be verbose. Plan for:

• Result pagination

• Smart search parameters

• Caching where appropriate

• Rate limiting

• Async operations for heavy queries

4. Implement Strong API Governance

Governance must include:

• Standard data models

• API naming conventions

• Error handling patterns

• Data retention rules

• Security testing and audit

• NHS DSP Toolkit alignment

• GDPR-compliant logging and consent management

5. Prioritise Clinical Safety

Document clinical safety cases using DCB0129/DCB0160 standards.

6. Minimise Point-to-Point Integrations

Use an integration engine or FHIR gateway layer rather than direct vendor-to-vendor connections.

7. Test with Real NHS Edge Cases

Examples include:

• merged patients

• temporary numbers

• ODS code variance

• cancelled vs DNAs

• multiple encounters in a single day

• data without timestamps

This avoids production surprises.

Common Challenges (and How to Avoid Them)

1. Vendor Interpretation Differences

Not all EPRs implement FHIR the same way.
Solution: insist on conformance statements.

2. Unclear Ownership Between IT & Clinical Teams

Integration failures affect clinical workflow.
Solution: establish joint governance.

3. Data Quality Gaps

Typographical errors, missing codes, or inconsistent timestamps.
Solution: introduce validation at integration level.

4. Over-Engineering the First Release

Trying to support every workflow at once creates risk.
Solution: start with one high-value workflow.

A Realistic Roadmap for NHS Trusts & Vendors

Phase 1: Discovery & Readiness

• Assess current interfaces

• Identify HL7 v2 messages in use

• Review vendor FHIR capabilities

• Map data quality issues

Phase 2: Define Integration Scope

Choose 1–2 workflows with clear clinical value.

Phase 3: Build the Integration Layer

• Implement HL7 → FHIR transformation

• Configure FHIR endpoints

• Apply authentication (OAuth 2.0, SMART on FHIR where relevant)

Phase 4: Testing & Safety Assurance

• Run clinical scenario testing

• Validate resource profiles against UK Core

• Complete DCB0129/DCB0160 processes

Phase 5: Deployment & Monitoring

• Implement API monitoring dashboards

• Set up audit logs

• Document support runbooks

Phase 6: Continuous Optimisation

• Add new workflows

• Improve performance metrics

• Expand partner integrations

Conclusion: Practical, Safe, Standards-Driven Integration is now Essential

HL7 and FHIR are no longer optional in the UK healthcare ecosystem. Providers, vendors, and integrators who embrace structured integration and safe, standards-aligned APIs will accelerate digital transformation and improve patient experience. A phased, clinically grounded approach is the most sustainable path forward.

‍