FHIR 101
What is FHIR?
A plain-language guide to healthcare’s data standard
FHIR is the closest thing healthcare has to a
shared language
Before FHIR, healthcare data lived in silos. Electronic health records, lab systems, mobile apps and insurance platforms each spoke their own language — proprietary formats that made sharing patient data slow, costly, and error-prone. Healthcare needed a shared language, and FHIR (Fast Healthcare Interoperability Resources) emerged as exactly that: a standard for exchanging healthcare information electronically, defining a common language and format that lets these different systems share patient data in a consistent,
machine-readable way.
FHIR breaks healthcare information down into modular building blocks called “resources,” such as Patient, Observation, Medication, and Condition. Each resource represents a specific piece of clinical or administrative data and can be combined with others to build complete health records. Because FHIR is built on modern web technologies like REST APIs and JSON/XML, it’s easier for developers to implement than older healthcare data standards, which speeds up integration between systems.
The result is real interoperability. The ability for different systems to not just exchange data, but actually make use of it. Patient data can move securely and accurately between hospitals, clinics, insurers, and apps, giving clinicians a fuller picture of a patient’s health and giving patients more access to and control over their own records.
Why healthcare needed a new standard
Older standards weren’t the problem. How they were built was — flexible enough to mean different things to different systems.
Built on the web
REST APIs and JSON — the same patterns modern software already uses, not a healthcare-only format.
Small, precise pieces
Data as “resources”, a patient, a medication, an observation, instead of one big loose document.
Flexible where it counts
The 80/20 rule: a tight, shared core, plus extensions for what varies by country or project.
FHIR versus what came before
HL7v2 and CDA are the older messaging standards most healthcare systems still run on today. Here’s how they compare to FHIR:
HL7v2 / CDA
- 1980s messaging & whole-document exchange
- Still runs most lab & admission/discharge feeds
- Built for sending a message, not answering a question
FHIR
- REST API — ask a precise question, get one back
- Runs alongside, not instead of, HL7v2
- Handles the on-demand, app-facing side of exchange
Most real-world environments run both today. That’s normal, not a red flag. HL7 also tried a more sweeping standard in the 2000s (v3), but its complexity meant it never saw wide adoption. One of the reasons FHIR was designed to be simpler
The building blocks, in plain language
Four concepts cover most of what FHIR is about.
Resource
The basic unit of data — a Patient, a Medication, an Observation.
Profile
The rulebook for how a resource is used in your context.
Implementation Guide
A bundle of profiles solving one real use case, like prior authorization.
FHIR Server
The software that stores resources and answers requests, like a database does.
Need the full vocabulary, including the regulatory terms? Read the FHIR glossary
What does this look like in practice
GP orders a blood test
Lab creates an Observation resource, linked to the patient
ObservationAny connected system requests it directly — GP, hospital, specialist
Behind every resource request is a patient waiting for the right diagnosis and treatment. When interoperability fails, that wait can have real consequences. See what that looks like in practice.
Why this matters right now
This isn’t optional. Regulators on both sides of the Atlantic are mandating FHIR-based exchange, with real deadlines attached.
Unites States
TEFCA
Nationwide exchange framework, increasingly
FHIR-based.
CMS-0057-F
FHIR APIs required for prior auth & payer-to-payer exchange.
European Union
EHDS
FHIR named for cross-border records, compliance from 2029.
None of these regulations invented the problem. They’re a response to it.
Frequently asked questions
Is FHIR a database, a server, or a data model?
None exactly, and all three loosely. FHIR is a specification — the rules.
A FHIR server is the software that implements those rules and stores the data.
What’s the difference between FHIR and HL7?
HL7 is the organization; FHIR is one of the standards it publishes, alongside older ones like HL7v2 and CDA.
Do I need to understand FHIR to comply with EHDS or CMS-0057-F?
Not in full technical depth if you’re business or policy-facing — but the basics here will make every conversation with your technical team easier.
Is FHIR used outside the United States?
Yes — it’s a global standard, referenced in regulation across the US, the EU, and numerous national programs elsewhere.
Who decides what a FHIR resource contains?
HL7 maintains the core spec through an open, international process. Countries adapt it locally through profiles and implementation guides.
Where to go next on your FHIR journey
BLOG
FHIR glossary
Look up any term, from Resource to CMS-0057-F.
ABOUT INTEROPERABILITY
A patient story
One eight-year search for a diagnosis.
BLOG
Choose a FHIR server
Evaluating or building infrastructure? Start here.
BLOG
What the US taught us
Preparing for EHDS? Learn from the US rollout.
TRAINING
FHIR Overview course
Three days, hands-on, practical.
Newsletter
Stay ahead of the FHIR standard
Subscribe to our newsletter for the latest news.