Which FHIR version should you actually build on?
New teams building on FHIR almost always ask the same question first: R4, R5, or R6? The honest answer in 2026 is that R4 remains the version you interoperate on, R5 is where the data model got meaningfully better, and R6 is the future you should design toward but not depend on yet. This guide walks through what actually changed between the versions, why R4 still dominates real-world exchange, and how to build so a version bump later doesn't become a rewrite.
The short answer
- Build your external, interoperable surface on R4 — it is what US regulation, EHRs, and payers speak.
- Use R5's modeling improvements internally where they help, and map to R4 at the boundary.
- Treat R6 as directional: design for change, but don't ship a dependency on a version the ecosystem hasn't adopted.
Why R4 is still the baseline
FHIR R4 (released 2019) was the first version with normative content — parts of the specification the community committed not to break. That stability is exactly why it became the interoperability floor. In the United States, the ONC Cures Act certification and USCDI are anchored to R4 via US Core, so certified EHRs, payer APIs (CMS Interoperability rules), and national networks all exchange R4. If a page of your product talks to an outside system, it almost certainly talks R4.
This is the single most important design fact: your regulatory and partner obligations are R4, regardless of what you prefer internally.
What R5 actually improved
R5 (2023) is not a cosmetic bump. It reworked several resources that were awkward in R4, and it is worth understanding where it helps before you decide to stay on R4 everywhere.
- Subscriptions were redesigned around topic-based subscriptions — a far more workable real-time model than R4's fragile criteria strings.
- Workflow and clinical resources (e.g. the medication and nutrition resources, evidence-based resources) were split and clarified.
- Data types and references were tightened, reducing the ambiguity that made R4 mappings inconsistent between vendors.
The catch: most production endpoints you integrate with do not speak R5. So R5's value is mainly internal — a cleaner model for your own services — with a translation layer back to R4 for anything that leaves your walls.
Where R6 fits
R6 is still moving toward ballot and release. It continues the direction R5 set: more normative content, more mature subscriptions, and refinements informed by real deployments. The practical guidance is unchanged from every prior FHIR transition — nobody should block a 2026 build on R6, but you should keep your resource mappings and serialization behind an abstraction so adopting it later is a configuration change, not a migration project.
How to build so version changes don't hurt
- Isolate the FHIR version at the edge: a mapping/serialization layer converts between your internal model and the wire version, so business logic never hard-codes a version.
- Pin and validate against the specific profiles you support (US Core versions included), not just "FHIR R4" in the abstract.
- Keep a conformance test suite (e.g. Inferno, Touchstone) in CI so a version or profile change surfaces immediately.
- Version your own APIs explicitly so consumers opt into a change rather than being broken by one.
A pragmatic 2026 recommendation
For almost every team: ship R4 externally, adopt R5 internally only where its modeling genuinely simplifies your system, and abstract the version boundary so R6 is a future switch rather than a future rewrite. FHIR versioning rewards teams that treat the wire format as an interface, not an assumption baked through the codebase.
