FHIR R4 vs FHIR R5 for US EHR Projects

• • 4 Min Read

The FHIR R4 vs FHIR R5 decision is one of those questions that looks simple in a meeting and turns into months of work once a US EHR project actually commits to either side. R4 is the regulatory minimum, the version US Core anchors on, and the version every US EHR FHIR API speaks today. R5 has a richer feature set, cleaner resource definitions in places, and a growing community of new builds. The right pick for a US project depends on the project's regulatory horizon, integration partners, and tolerance for living slightly ahead of the broader ecosystem.

For FHIR background reading, the rest of the site has surrounding material. The complete guide to FHIR-based EHR development for US healthcare in 2026 cornerstone is the right background.

What FHIR R4 Gives a US EHR Project

FHIR R4 is the most widely deployed FHIR version in US healthcare in 2026. Every major US EHR FHIR API speaks R4. US Core is on R4. The federal regulatory framework, including USCDI alignment, is anchored on R4. The community knowledge base, the tooling ecosystem, and the conformance testing tools all skew heavily toward R4.

For a US EHR project that has to integrate with existing US EHRs, satisfy USCDI obligations, and stay aligned with federal certification, R4 is the safe default. The work is well-understood, the tooling is mature, and the community can answer almost any question your team will hit.

What FHIR R5 Gives a US EHR Project

FHIR R5 is the normative release that followed R4, with refinements in many resource definitions, new resources that did not exist in R4, and cleaner semantics in places where R4 had accumulated awkwardness. For greenfield builds without a hard integration constraint to existing R4 systems, R5 offers a cleaner foundation.

The trade-off is that the US ecosystem has not caught up to R5 yet. US Core is still R4-anchored in 2026. US EHR FHIR APIs still speak R4. A project that picks R5 has to either bridge R5 to R4 at integration boundaries, or accept that it will be ahead of the partners it integrates with for a while.

Where the Decision Actually Bites for US Projects

Three places.

Integration with US EHR APIs. If the project has to consume Epic, Cerner, athenahealth, or similar US EHR FHIR APIs, those APIs are R4. The project either speaks R4 to them directly, or translates between R5 internally and R4 at the boundary. The top 5 SMART on FHIR frameworks for US EHRs in 2026 explainer covers how the SMART layer fits into either choice.

USCDI alignment. USCDI cycles through versions on a federal cadence, and US Core follows. The US Core profile packs are R4. A project that targets USCDI compliance is anchored on R4 by default.

Long-term direction. R5 will eventually become the dominant FHIR version in the US ecosystem. Projects with long horizons (say five years and up) may benefit from being on R5 today even if they have to bridge R4 at integration boundaries.

Where the Architecture Choice Interacts

The R4 vs R5 decision interacts with the broader architecture choice between monolithic EHRs and modular FHIR-first stacks. The monolithic EHRs vs FHIR-first modular stacks for US projects write-up covers that decision. Monolithic EHRs almost always lock you to R4 today. Modular stacks give you the freedom to pick R5 for the core and bridge at integration points.

That extra freedom is real and not free. Bridging between R4 and R5 adds work on every integration boundary, and the work is ongoing because resources evolve in both versions.

Making the Call

Two questions sort most US projects. First, does the project have to integrate with existing US EHR FHIR APIs or USCDI-anchored partners? If yes, R4 is the safe default unless the project is ready to absorb bridging cost. Second, is the project greenfield with a five-plus-year horizon and no immediate R4 integration partner? If yes, R5 is a defensible pick because the long-term direction is on its side.

A US EHR project today picks R4 unless it has a specific reason to pick R5. The reason has to outweigh the integration friction with the R4-anchored US ecosystem, and for most projects it does not.