FHIR for private health insurers

Most private health insurers receive clinical data from providers as unstructured documents: discharge summaries, letters and PDF reports. The move towards FHIR-based structured data exchange is not a distant ambition. It’s happening now, driven by NHS connectivity expectations and the operational pressure to improve claims accuracy, reduce manual processing and detect fraud more effectively.

01 What FHIR is, and why it matters for insurers now

FHIR (Fast Healthcare Interoperability Resources) is the clinical data standard developed by HL7 International and now mandated across the NHS. It defines a common way to represent and exchange healthcare data: patients, conditions, medications, procedures, observations, appointments, claims and dozens of other clinical and administrative concepts.

For private health insurers, FHIR matters for three reasons that are already affecting operations, not theoretical future ones.

NHS connectivity:  Hospitals treating NHS-commissioned patients are deploying FHIR-based APIs to meet national connectivity requirements. Insurers with NHS partnership arrangements are increasingly expected to receive and send data in FHIR format.

Provider integration:  Private hospitals implementing modern EPR systems are building FHIR APIs as standard. Insurers still relying on PDF-based data exchange with these providers are creating manual overhead that their competitors are automating away.

Claims data quality:  Structured FHIR data from providers, coded diagnoses, procedures and medications is materially more useful for claims adjudication, fraud detection and population health analysis than unstructured discharge text.

The standard itself is relatively mature. FHIR R4 is the current baseline in the NHS and in most modern clinical systems. The complexity is not in the standard. It’s in implementation, governance, and clinical data quality that the standard is exposed.

02 How insurer / provider FHIR connectivity actually works

The theoretical picture is straightforward: a provider's EPR exposes a FHIR API; the insurer's platform calls that API to retrieve structured clinical data; automated processing handles pre-authorisation, claims triage and coding. The practical picture is more complicated.

First, the range of FHIR maturity across the provider estate is significant. A major private hospital group that has recently completed an EPR implementation may have a well-structured FHIR API available. A smaller independent clinic on a legacy system may not. An insurer building a FHIR integration strategy needs to accommodate a mixed provider estate, not assume uniformity.

FHIR defines the format of the data, not its quality. The clinical data quality issues that existed in the unstructured world do not disappear when you move to FHIR. They become more visible and more consequential, because automated processes act on them.

Third, the authentication and authorisation model for FHIR APIs in a healthcare context is not trivial. Clinical data has legal protections. Data sharing agreements, consent frameworks and information governance requirements need to be in place before any API connection goes live, regardless of how straightforward the technical integration looks.

The NHS experience

Aire Logic has built FHIR integration infrastructure at the national NHS scale, including GP Connect and NHS Spine integrations. The lessons from that work, particularly around data quality, consent management and API governance, translate directly to the insurer-provider connectivity challenge.

03 The three clinical data standards you need to understand

FHIR is the transport mechanism. The value of FHIR data depends on the clinical terminology standards used to code the content. There are three that are directly relevant to private health insurance operations.

SNOMED CT:  The clinical terminology standard used across the NHS for diagnoses, clinical findings and procedures. A structured FHIR Condition resource coded in SNOMED CT enables automated diagnosis classification, comorbidity identification and risk stratification. Critical for underwriting and claims adjudication.

dm+d:  The NHS dictionary of medicines and devices. Standardised medication coding enables automated drug interaction checking, formulary management and fraud detection. Relevant for insurers providing drug benefits or managing prescription claims.

OPCS-4:  The Office of Population Censuses and Surveys Classification of Surgical Operations and Procedures. Used in the NHS for procedure coding and by private hospitals treating NHS-commissioned patients. Relevant for procedure-level claims validation and surgical outcomes reporting.

In practice, you will encounter providers using different combinations of these standards and different levels of coding completeness. Building a data platform that can handle this variation — mapping between coding systems, identifying and flagging poor-quality coding, enriching incoming data where possible — is a material part of any FHIR integration programme.

An insurer that can receive SNOMED-coded diagnoses and OPCS-coded procedures directly from provider FHIR APIs, and that has built the mapping and validation layer to use that data reliably, can automate a materially larger proportion of claims decisions than an insurer working from PDF discharge summaries. The ROI is in the proportion of claims that require no manual review.

04 The pre-authorisation opportunity

Pre-authorisation is where FHIR connectivity has the most immediate operational impact for health insurers. The current process at most insurers involves a referral letter or form from the referring clinician, a manual review by a clinical assessor, and a decision that may take hours or days. The delays create friction for members, additional cost for the insurer and frustration for providers.

FHIR-based pre-authorisation works differently. The referring clinician's system sends a structured FHIR referral request containing the coded diagnosis, the proposed procedure, the clinical rationale and the member's relevant clinical history. Automated rules handle the straightforward approvals; complex cases are flagged for clinical review. Turnaround time compresses from hours to minutes for the majority of requests.

This is not a future technology. FHIR-based prior authorisation is in active deployment in the US market, and the technical standards are being adapted for the UK context. The insurers building this capability now will have a structural advantage in member experience and administrative cost within three to five years.

Components of a FHIR pre-authorisation capability

1. Structured referral intake:  replace PDF or web-form referral with a FHIR ServiceRequest from the referring clinician's system. Requires provider-side FHIR capability and an information governance framework.
2. Automated clinical rules:  coded diagnosis and procedure data enable rule-based approval for defined clinical pathways. Requires a clinical rules engine and ongoing clinical governance.
3. Real-time member record:  a FHIR-based view of the member's clinical history enables more accurate automated decisions and reduces the need for manual clinical review.
4. Provider feedback loop:  structured approval or denial responses sent back to the provider's system via FHIR, removing phone and fax confirmation.

05 The governance questions most technology suppliers cannot answer

FHIR interoperability between health insurers and providers sits at the intersection of three regulatory and governance frameworks: FCA conduct requirements, clinical data governance under UK GDPR, and NHS information governance requirements for organisations accessing NHS patient data.

Most technology suppliers who sell FHIR integration platforms are strong on the technical side and weak on the regulatory side. They can build the API connection. They struggle with the data-sharing agreement template, the consent framework for accessing clinical records, the audit trail requirements for automated claims decisions, and the clinical governance structure for the rules engine.

Automated claims decisions made on the basis of FHIR clinical data are subject to FCA conduct requirements. If an automated rule denies a claim, the member has the right to understand the basis of that decision. The audit trail, explainability and review process for automated clinical decisions need to be designed into the system from the start, not retrofitted when a complaint arrives.

‍Governance questions to answer before building

1. What data sharing agreement framework will govern each provider FHIR connection, and who is responsible for maintaining it?
2. What consent model applies to accessing a member's clinical record from a provider's FHIR API?
3. How will automated claims decisions based on FHIR data be logged and made explainable to members and the FCA?
4. Who provides clinical governance for the pre-authorisation rules engine, and how are rules reviewed and updated?
5. How does your FHIR integration architecture handle a provider whose data quality is poor enough to affect decision accuracy?

06 A practical approach: phased FHIR adoption

Building a comprehensive FHIR integration capability is a multi-year programme. The insurers who approach it well break it into phases, starting with the high-value, lower-complexity use cases and building capability progressively.

Phase 1:  FHIR-based structured discharge data from two or three major hospital partners. Coded diagnosis and procedure data for claims validation and analytics. Medium (depends on hospital EPR maturity).

Phase 2:  Structured pre-authorisation request intake from high-volume referring clinicians. Faster pre-auth turnaround, reduced manual clinical review. Medium-high ( requires a clinical rules engine).

Phase 3:  Real-time member clinical record access via FHIR APIs. More accurate automated decisions, reduced fraud. High  (complex consent and governance requirements).

Phase 4:  Population health analytics on structured FHIR data. Risk stratification, proactive member health management. High (data platform and analytics investment).

The sequence matters. Phase 1 lays the foundation  for the data engineering and governances that everything else depends on. Starting with Phase 3, a common mistake driven by the appeal of AI-enabled use cases, typically results in a programme that gets stuck on consent and information governance before any data flows.

Starting point

Identify two or three hospital providers who are actively deploying modern EPRs with FHIR APIs. Approach them to co-design a structured data sharing pilot. The pilot delivers immediate value in claims data quality, builds the governance framework that subsequent provider connections can reuse, and creates a proof point for the broader investment case.

Summary

The direction of travel is clear. Structured clinical data exchange between providers and insurers, via FHIR APIs, is coming, driven by NHS connectivity requirements, provider EPR modernisation and the competitive pressure from insurers already building this capability.

The question is not whether to build FHIR connectivity, but when and how. The insurers who start with a focused pilot, build the governance framework properly, and phase the capability progressively will arrive at the destination faster and with less wasted investment than those who wait for a comprehensive solution.

The technical complexity is manageable. The governance complexity is where most programmes stall, and it’s where experience in the NHS clinical data environment is most directly relevant.

About Aire Logic

Aire Logic has spent 15 years building FHIR APIs, national clinical data platforms and interoperability infrastructure within the NHS — including GP Connect and NHS Spine integrations at the national scale. We understand the clinical terminology standards, the information governance requirements and the data quality challenges that FHIR integration in healthcare involves in practice, not just in theory.

We work with private health insurers who want to build FHIR connectivity with their provider networks. Get in touch if you are evaluating your interoperability strategy, preparing a business case or looking for a delivery partner who has done this before.