Standards & Interoperability
HL7 FHIR (Fast Healthcare Interoperability Resources)
HL7 FHIR — Fast Healthcare Interoperability Resources — is the modern standard for exchanging healthcare data over the web. Created by Health Level Seven International (HL7), FHIR replaces decades of brittle, document-heavy messaging with a clean, REST-based API model that any engineering team can reason about. Instead of parsing pipe-delimited HL7 v2 messages or wrestling with bespoke vendor formats, developers work with well-defined JSON or XML 'resources' retrieved over ordinary HTTP. For an AI product engineering team building copilots, scheduling agents, or RCM automation, FHIR R4 is usually the single most important interface between your software and the clinical systems of record.
FHIR in plain terms
Think of FHIR as the 'REST API for healthcare.' Every clinically meaningful concept — a patient, an appointment, a lab result, a medication, an allergy — is modelled as a discrete resource with a predictable structure and a stable URL. You fetch a patient with a GET request to /Patient/123, search for their conditions with /Condition?patient=123, and write back observations with a POST. Because the format is JSON over HTTP, the same skills your team already uses to integrate Stripe or Twilio transfer directly to healthcare. That accessibility is exactly why FHIR has become the default integration layer for new digital health products and why regulators in the US and UK now mandate FHIR-based patient data access.
FHIR R4, resources, and profiles
FHIR R4 (Release 4) is the first 'normative' version, meaning its core resources are stable enough to build production systems against without fear of breaking changes. The specification defines roughly 145 resource types, but real implementations rarely need more than a couple of dozen: Patient, Practitioner, Encounter, Observation, Condition, MedicationRequest, AllergyIntolerance, DiagnosticReport, and a handful of others. Profiles and implementation guides — such as US Core in the United States or UK Core for the NHS — constrain those base resources into nationally agreed shapes, specifying which fields are mandatory and which code systems (SNOMED CT, LOINC, ICD-10) are allowed. Building against the right profile is what separates a demo from a system an EHR vendor will actually certify.
SMART on FHIR and authorisation
FHIR defines the data model; SMART on FHIR defines how apps securely launch and obtain access. SMART layers OAuth 2.0 and OpenID Connect on top of FHIR so a clinical app can launch inside an EHR like Epic or Cerner, inherit the logged-in clinician's context, and request scoped permissions (for example, read-only access to a single patient's medications). This is the mechanism that lets a third-party AI copilot appear inside the EHR without the vendor handing over a database dump. Getting SMART scopes, token refresh, and launch context right is typically where integration projects spend their effort — the FHIR queries themselves are the easy part.
Why FHIR matters for AI products
Large language models are only as useful as the clinical context you can feed them. FHIR is how that context arrives: a structured, permissioned, real-time view of the patient that an agent can summarise, reason over, or act on. An ambient documentation tool reads the Encounter and writes back a clinical note; a triage agent reads Conditions and Observations to risk-stratify; an RCM bot reads Coverage and Claim resources to flag denials. Because FHIR is standardised, the same integration architecture you build for one customer's EHR largely carries over to the next — the economic foundation of selling healthcare software at scale rather than rebuilding a custom interface per hospital.
Common pitfalls and considerations
FHIR's flexibility is also its trap. Two systems can both be 'FHIR R4 compliant' yet disagree on which optional fields they populate, how they code a diagnosis, or whether they support the search parameters you need. Bulk export ($export) behaves very differently from per-patient reads and is often rate-limited. Sandbox environments rarely match production data quality. And FHIR carries Protected Health Information, so every request must be designed under HIPAA, UK GDPR, and your data processing agreements from day one. Treat conformance testing against the customer's real (or synthetic) data as a first-class engineering task, not an afterthought.
Frequently asked questions
Is FHIR replacing HL7 v2?
Not entirely. Most hospitals still run HL7 v2 interfaces for internal messaging like admissions and lab results, and those will persist for years. FHIR is the standard for new external APIs, patient-facing apps, and AI integrations. In practice you often bridge the two — consuming HL7 v2 internally while exposing FHIR outward.
What is the difference between FHIR R4 and earlier versions?
R4 is the first release with normative (stable) core content, so its key resources will not break in future versions. Earlier releases (DSTU2, STU3) are still found in older Epic and Cerner deployments, so production integrations must confirm which version a given endpoint speaks.
Do I need FHIR to integrate with Epic or Cerner?
It is the recommended modern path. Both Epic (via App Orchard / Vendor Services) and Oracle Cerner expose FHIR R4 endpoints secured with SMART on FHIR. Legacy integrations may still use HL7 v2 or proprietary APIs, but new app development is steered toward FHIR.
Planning an EHR integration? We build FHIR R4 and SMART on FHIR connections that pass vendor certification. Book a discovery call to scope your integration.