This post was written by Gita Vikram, Integration Manager at Redox.
If you work anywhere near healthcare technology, you’ve heard of FHIR (pronounced “fire”). It comes up anytime there’s a discussion related to healthcare data; in sales calls, security reviews, and the Slack thread where someone asks “wait, can’t we just get an HL7 feed instead?” FHIR is a cornerstone of how healthcare runs, but double clicking on the details can feel intimidating. If this is you, know that you’re not alone, and you don’t need an engineering degree to better understand it.
Here’s the plain-English version. (NOTE: this is a cheat sheet summary of the FHIR101 Course by Out-of-Pocket Health and Redox from August 2026. Start here, then watch the on-demand videos for expert coaching and commentary)
First, the alphabet soup
Healthcare data standards have a long, tangled family tree, and most of the confusion starts here. It all traces back to one organization: HL7 (Health Level Seven), the standards body that’s been defining how health data moves between systems since the 1980s.
HL7 has produced a few major standards over the years:
- HL7v2: the original messaging standard. It’s how hospitals have shared data like admissions and discharges (ADT messages) for decades. It’s old, it’s a little clunky, and it’s still running in production at hospitals everywhere.
- HL7v3: the ambitious follow-up that ended up being too rigid to implement except with one critical use case – CDA. CDA is used for clinical documents, think discharge summaries, and became a federal requirement in 2009 to support care transitions between facilities. It’s rigid and verbose, but don’t count it out: CDA documents still make up the majority of exchange volume on major national health information networks today, even ones that also support FHIR.
- FHIR (Fast Healthcare Interoperability Resources): the modern standard, built for the web, and the one most new integration work is built on today.
So HL7 is the organization. HL7v2, HL7v3, and FHIR are three different things it has produced, each with a different job.
What does FHIR really mean?
FHIR is a useful acronym, not only because it lends itself to a seemingly endless number of memes and puns, but also because every letter describes something real about how it works:
- Fast: built on standard REST/web technology (the same patterns developers use for any modern API), so integrations take days, not the months typically needed to build custom HL7v2 interfaces or parse CDA documents.
- Healthcare: designed specifically for messy, real-world clinical data
- Interoperability: the whole point, systems sharing data without friction
- Resources: data comes in small, modular, self-contained packets
That last point is the key architectural idea. A FHIR resource is always self-contained, has a unique ID, follows standard fields, and is defined by the spec. Instead of one giant document, you get small, predictable pieces of data you can request individually.
Push vs. pull: the mental model that matters most
The easiest way to tell these standards apart isn’t the acronym, it’s how the data moves.
- HL7v2 is push. Data finds you. A hospital system fires off a message when something happens (a patient is admitted, a lab result posts), and your system has to be listening
- CDA is a snapshot. It’s a document capturing a moment in time, like a PDF with structure
- FHIR is pull. You ask for exactly what you need, when you need it. Want a patient’s allergy list? Request the AllergyIntolerance resource. That’s it.
FHIR drove the shift from “wait for data to arrive” to “ask for what you need.”
The 10 resources that cover 80% of use cases
FHIR defines a lot of resource types, but you don’t need to memorize all of them. These ten cover the vast majority of real-world use cases:
Know these ten, and you can follow the vast majority of conversations about a FHIR-based integration.
A few more terms worth knowing
- Bundle: a package of multiple resources returned together, like a search result. Also used for batch and transaction requests
- Versioning: FHIR changes over time! R4 is today’s standard. R5 exists but adoption is still early; R6 is still working through HL7’s ballot process
- Implementation Guide (IG): a set of rules built on top of the base FHIR spec for a specific use case. US Core and Da Vinci are the two you’ll hear most. (Worth noting: USCDI is a separate, easy-to-confuse term. It’s not a FHIR product or an IG at all, it’s a U.S. federal government policy, written in plain language, that defines what healthcare data should be shareable. People often assume USCDI and US Core are the same thing since the names look related, but they’re distinct projects that happen to overlap in scope.)
- Profiles: customize a resource for a specific use case, like the US Core Patient profile. FHIR is the city building code . The IG is the HOA that bans plastic flamingos in your yard and requires matching mailboxes – narrower and more specific
- Cardinality: the min-to-max notation on a field, like 0..1 or 1..*. The first number tells you if a field is required; the second tells you how many values are allowed. * means optional, repeatable. Profiles can tighten this further
Why the “same” FHIR feed still looks different everywhere
Here’s the part that trips people up: two organizations can both say “we support FHIR” and still require custom implementations. The flexibility of FHIR is both a feature and a bug. It needs to work for a veterinary office in New Zealand (yes, FHIR covers animals too!) as well as an acupuncturist in Finland, and a Level 1 trauma center in Chicago. But the flexibility can be a headache for the folks doing the implementing.
Variation shows up in three places:
- Between EHRs. Epic, Oracle Health, athenahealth, etc. each expose different resources and authentication methods
- Between versions. Organizations update on their own timelines, so not everyone’s running the same version of the spec.
- Between installs. Even the same EHR, same version, can be configured differently site to site, depending on how that organization built it out
This is the real-world reason healthcare interoperability is still hard, even with a modern standard like FHIR in place. The standard gives everyone a shared language. It doesn’t guarantee everyone speaks it exactly the same way.
Keep this handy
Everything above is the short version. Download the FHIR 101 Cheat Sheet for a one-page reference you can pull up anytime someone drops an acronym mid-meeting: the alphabet soup breakdown, the 10 resources to know, and the quick facts on versioning, profiles, and cardinality, all in one place. When you are ready for the full 101 – watch the on-demand videos!