The short answer
FHIR R4 (4.0.1, October 2019) was the first release with normative content, and it remains the base for most regulation and implementation guides in use today. R4B (4.3.0, May 2022) and R5 (5.0.0, March 2023) are trial-use releases. R6 is still in ballot: its second full ballot was published on 17 July 2026, alongside a snapshot described as “R6 Stable (Sept 2026)”.1 HL7’s own R6 ballot page still names 5.0.0 as the current version.1 If you’re building a system that must work with payers, national programmes or EHR vendors in 2026, build on R4, keep your code version-aware, and watch R6.
Deedglass
The server said “saved”. Deedglass looked.
Deedglass reads it back
The timeline
| Release | Version | Date | Status |
|---|---|---|---|
| R4 | 4.0.1 | 30 Oct 2019 | First normative content; normative + trial use |
| R4B | 4.3.0 | 28 May 2022 | Trial use |
| R5 | 5.0.0 | 26 Mar 2023 | Trial use |
| R6 ballot 1 | 6.0.0-ballot1 | 19 Dec 2023 | Draft |
| R6 ballot 2 | 6.0.0-ballot2 | 13 Aug 2024 | Draft |
| R6 ballot 3 | 6.0.0-ballot3 | 3 Apr 2025 | Draft |
| R6 1st full ballot | 6.0.0-ballot4 | 18 Dec 2025 | Draft |
| R6 2nd full ballot | 6.0.0-ballot5 | 17 Jul 2026 | Draft |
| R6 snapshot | 6.0.0-snapshot1 | 17 Jul 2026 | Draft (“R6 Stable, Sept 2026”) |
Source: HL7’s FHIR version list.1
Status: normative vs trial use
The status labels matter more than the release numbers. R4’s pages describe it as mixed normative and STU: some parts are normative, meaning future releases are expected to stay compatible with them; others are trial use and can change. R5’s pages describe it as STU, standard for trial use.1
In practice that’s why the ecosystem stayed on R4. Regulators and national programmes prefer a base where key parts are stable, and moving guides between releases is real work.
There’s a second reason: implementation guides are built on a specific release, and every guide layered on top multiplies the cost of moving. A national guide, a payer guide, and a vendor’s own profiles all have to move together, with testing at each layer and every trading partner upgraded at once. That coordination takes years, which is why a release can be published and widely admired long before most production traffic uses it. Plan around the release your partners actually run, not the one with the newest features.
Which guides and rules use which version
| Guide or rule | FHIR version | Source |
|---|---|---|
| CMS-0057-F (US payer APIs, including prior authorization) | R4 4.0.1 among required standards | 2 |
| HL7 Da Vinci PAS 2.0.1 | R4 | 5 |
| SMART App Launch 2.2.0 | R4 | 7 |
| HL7 AI Transparency on FHIR (ballot) | R4 (usable with R4B) | 6 |
| ABDM FHIR guide (NRCeS v6.5.0, India) | R4 | 3 |
| DHA interoperability standard (Dubai, NABIDH) | Lists FHIR R4 | 4 |
The pattern is consistent across the US, India and the UAE: R4. A system built on R5 would need to translate to R4 to talk to most of these, which defeats the point.
How to choose
| Your situation | Build on | Why |
|---|---|---|
| Integrating with US payers or CMS APIs | R4 | Required by the rule2 |
| Integrating with ABDM in India | R4 | The national guide is R43 |
| Connecting to Dubai’s exchange | R4 (alongside HL7 v2) | Listed in the DHA standard4 |
| Building an app on EHR APIs via SMART | R4 | SMART App Launch is R4-based7 |
| Internal system with no external FHIR partners | R4, or R5 if a feature you need exists only there | Weigh tooling and future migration |
| Research prototype exploring new resources | R5 or R6 ballot | Expect changes |
Planning for R6 without waiting for it
You don’t need to adopt R6 to prepare for it:
- Keep the FHIR version explicit in your code, configuration and stored data. Every stored resource should be traceable to the version it was written in.
- Isolate version-specific code behind one layer, so a later move touches one module.
- Use the FHIR version of your partners, not the newest. Your partners’ guides decide.
- Read the R6 ballot notes for resources you rely on; ballots are where breaking changes are discussed.
- Don’t mix releases inside one exchange. A Bundle with R4 and R5 resources confuses everyone, including validators.
For systems where AI agents write to FHIR, version discipline also affects safety. A field that exists in one release and not another can be silently dropped by a server that parses leniently; our FHIR write integrity study found servers storing writes with parts removed even within one release. Read back what you wrote, and know which release the server is on.
Questions people ask
What is the latest version of FHIR?
R5 (5.0.0, March 2023) is the latest published release; R6 is in ballot, with its second full ballot published in July 2026.1
Should I use FHIR R4 or R5?
For anything that exchanges data with payers, national programmes or EHR vendors, R4: that’s what CMS-0057-F, ABDM, SMART App Launch and the Da Vinci guides use.237
When will FHIR R6 be published?
HL7’s version list describes a snapshot as “R6 Stable (Sept 2026)”, still marked draft.1 Check HL7’s directory for the final publication.
Health systems can see how agent writes to FHIR are checked on our healthcare page, with record formats in the provenance spec. To try approvals and read-backs on a real database in your browser, open the playground; to grade what an agent can reach on your own machine, run npx deedglass scan (the grade, explained).
Written with AI assistance and checked against our claims register.