FHIR (Fast Healthcare Interoperability Resources) is an HL7 standard for exchanging healthcare information electronically using RESTful APIs and modular resources. It is the dominant modern standard for healthcare data interoperability.
HL7 FHIR
FHIR (Fast Healthcare Interoperability Resources) is an HL7 standard for exchanging healthcare data over ordinary web APIs. It breaks clinical and administrative information into modular “resources” — Patient, Observation, Encounter, MedicationRequest, and dozens more — and moves them with RESTful HTTP, JSON, and OAuth. By meeting developers where they already are, FHIR made healthcare data interoperability approachable, and it is now the dominant modern standard for moving health information between systems.
- Modular resources - A library of granular, composable data types that model real clinical and administrative concepts.
- RESTful web APIs - Standard HTTP verbs, JSON payloads, and search parameters, so any web developer can integrate without healthcare-specific tooling.
- SMART on FHIR - An OAuth-based app-authorization layer that lets third-party apps launch securely inside EHRs with scoped access.
- Bulk and async access - Bulk Data and asynchronous query patterns for moving population-scale datasets, not just one record at a time.
- Profiles and implementation guides - Constrainable base resources that let regions and specialties tighten the spec to their exact use case.
In real API operations, FHIR is the backbone I see across the healthcare providers I profile — EHRs, aggregators, and developer backends all expose FHIR endpoints, and the interesting work is stitching individual resource calls into real clinical journeys with Arazzo workflows. Its RESTful, resource-oriented shape also makes it unusually agent-friendly: an AI agent can read a Patient, follow references to Observations, and reason over structured data because the contract is predictable. For any organization governing healthcare APIs, FHIR conformance plus SMART on FHIR authorization is the baseline that makes health data both interoperable and safe to expose.
Referenced in API Evangelist papers
This standard shows up in my published research. These reports read the machine-readable evidence provider by provider — and put this standard in the context of a real sector.
The State of Canadian Insurance APIs
The one FHIR surface in Canadian insurance belongs to a US subsidiary and exists because a US rule compelled it — and its platform's agent flags are switched off.
Referenced on the API Evangelist blog
Where this standard shows up across sixteen years of my writing at apievangelist.com — how it fits into API design, governance, and the agentic turn.
Medplum and FHIR as a Developer Backend
2026-07-04
