FHIR Versions: DSTU1 to R5 — choosing the right release for 2026

Quick summary

• The main published milestones are DSTU1, DSTU2, STU3, R4, R4B, and R5; R6 is under development on the ballot/CI line.
• R4 contains both Normative and Trial Use material; maturity must be read per Resource or artifact, not inferred for the whole release.
• R5 adds or reworks many artifacts, including SubscriptionTopic, ImagingSelection, and Permission; R5 was published as STU, while content already Normative in R4 retains the corresponding status.
• VN Core currently declares FHIR 4.0.1 to keep a clear technical baseline comparable with the 2024 VN Core repository; a shared base version does not create automatic compatibility.
• Migrate only after checking packages/profiles, CapabilityStatements, terminology, transforms, partners, and regression evidence; R4B is not a mandatory step before R5.

1. FHIR milestones from 2014 to the R6 ballot line

FHIR (Fast Healthcare Interoperability Resources) was initiated by HL7 International in 2011 under the working name RFH (Resources for Health). DSTU1 shipped on 30/09/2014 as version 0.0.82. HL7 subsequently published DSTU2, STU3, R4, R4B, and R5; R6 remains on the ballot/CI line. Every IG must declare its FHIR base version and govern migration as a technical contract change.

The table below summarizes the milestones and status reviewed on 18 July 2026. CI content can change between reviews and is not a stable publication.

A note on dates: DSTU1 (30/09/2014) and DSTU2 (24/10/2015) are the two milestones most often confused. DSTU1 is sometimes mistakenly written as 21/02 — that is the date HL7 opened the draft ballot, not the publication date. When citing in technical documentation or executive briefings, use the official publication dates.

2. Lifecycle: what DSTU, STU, R, and Normative actually mean

To understand why R4 matters, you need to know the four lifecycle labels HL7 attaches to FHIR.

• DSTU (Draft Standard for Trial Use) — the older label applied to DSTU1 and DSTU2. Characteristic: breaking changes were permitted between minor releases.
• STU (Standard for Trial Use) — the newer label, used from STU3 onward. Changes are still allowed, but the ballot process is tighter than for DSTU.
• R (Release) — the major-line label used in published names such as R4 and R5. “R6” is currently a ballot/CI branch label and becomes a publication only when HL7 completes its release process; maturity still needs to be read at artifact level.
• Normative — governed by HL7's strict inter-version change rules; it should not be read as meaning the entire release is immutable.

R4 was the first release to contain Normative material. Many other R4 artifacts remain Trial Use, including Encounter and AllergyIntolerance. A conformance claim should therefore identify the FHIR version, applicable IG/profile, and CapabilityStatement; “FHIR R4 Normative” alone does not describe a complete implementation contract.

The R5 ballot as a whole was published as STU. Material already Normative in R4 retains that status; some artifacts reorganized in R5 may also carry a Normative label because they inherit previously Normative content. The status of every R5 artifact should therefore not be collapsed into one label.

3. Comparing DSTU2, STU3, R4, R4B, R5

This table compares only properties that can be checked from release history and project scope. IGs such as SMART App Launch or Bulk Data have their own lifecycle, package, and base version; support cannot be inferred from a server's FHIR release name alone.

Bulk Data Access is a separate Implementation Guide maintained by HL7 (canonical hl7.org/fhir/uv/bulkdata), not a default capability that follows from R4 or R5. When a vendor claims Bulk Data or SMART support, check the exact IG version, FHIR base, endpoint, and required capabilities.

4. Why R4 is VN Core's base version in 2026

“R4 or R5?” must be answered against a specific interoperability contract. The reasons below explain the current VN Core decision; they are not a universal default for every Vietnamese system.

One: maturity of selected core artifacts. R4 was the first release to contain Normative material. Resources that remain Trial Use still require use-case and profile assessment; a base Resource label does not by itself prove production readiness.

Two: the project pipeline is configured for R4. The VN Core package, SUSHI configuration, and validation process currently target FHIR 4.0.1. This is a verifiable project property, not a claim that every R4 tool or product is compatible.

Three: VN Core continuity. The 2024 hl7vn/vn-core-ig repository was initialized on R4. The trial-use line at hl7.org.vn keeps the same base version so structures can be compared; harmonization still requires governance, package-dependency review, and a concrete diff.

Four: an interoperability contract requires evidence. The base release is only one layer of the contract. Connectivity must be demonstrated through packages/profiles, canonical URLs, terminology, CapabilityStatements, and integration tests with representative payloads.

5. What is new in R5 and what to read first

R5 (5.0.0, released 26/03/2023) adds several Resources and reworks selected areas of the specification. The list below highlights technical changes worth reviewing; it is not evidence that a specific product, partner, or IG supports R5.

Notable new Resources

• SubscriptionTopic — defines topics and triggers for the subscription model reworked in R5.
• ImagingSelection — identifies selected imaging instances, frames, or regions, including DICOM references where applicable.
• Permission — represents a set of rules that permit or deny actions; enforcement still depends on the system's security architecture.
• RegulatedAuthorization — supports drug regulatory affairs and the exchange of marketing authorization data.

Structural changes

• Adds CanonicalResource and MetadataResource interfaces for definitional artifacts.
• Moves extensions into the separately released hl7.fhir.uv.extensions package.
• Adds additional bindings and many REST/Search clarifications; migration still requires per-Resource diff and transform review.

For VN Core, assess R5 only against a concrete use case, IG, or partner requirement. A production decision must identify the target package, data impact, transformation boundary, and test results; the release name alone is not a sufficient criterion.

6. R6 in ballot — what to watch for

At the 18 July 2026 review, the CI build displayed 6.0.0-ballot4 and explicitly warned that CI content may be inconsistent. The official branch history highlights these areas:

• Moving selected definitions to Additional Resources.
• Reworking Dosage for complex dosing regimens.
• Reworking signatures and applying many smaller changes across the specification.
• A proposal to mark most content Normative except explicitly Informative pages; the final result remains subject to ballot.

This project does not assign a publication ETA to R6 without a stable HL7 milestone to cite. Do not use the CI build as a production dependency; any R6 exploration should pin an experimental snapshot and assume that content may change.

7. Assessing migration among R4, R4B, and R5

There is no mandatory R4 → R4B → R5 path. R4B is a separate release that may suit a particular contract; it is not a required intermediate step. Assess each conversion from the target IG/package, stored payloads, and the systems on both sides of the integration boundary.

A CapabilityStatement is necessary evidence but does not prove compatibility by itself. Retrieve /metadata from the actual endpoint and inspect at least fhirVersion, formats, profile/supportedProfile, interactions, search parameters, and operations. Then compare packages, canonical URLs, terminology versions, and representative integration tests. A mixed-version design can be viable when the conversion boundary, data-loss rules, and operational responsibility are explicit; two systems with the same fhirVersion are not automatically compatible.

Distinguish a ConceptMap, which relates codes or concepts, from a StructureMap and the FHIR Mapping Language used for structural conversion. HL7 publishes inter-version transforms for most Resources, but the R4 mapping page describes them as Informative and non-authoritative. Each project must review and extend the rules and test round trips with representative data; a transform is not a lossless-conversion guarantee.

8. Why VN Core chose R4

The current R4 baseline for VN Core is described by the following verifiable project properties:

1. Base-version continuity — the 2024 hl7vn/vn-core-ig repository declares R4 (canonical http://fhir.ehealth.gov.vn/core/); the trial-use line at hl7.org.vn also declares R4 so the structures can be compared. This is not a backward-compatibility claim.
2. Project configuration — the package, SUSHI configuration, and validation pipeline currently target FHIR 4.0.1.
3. Controlled dependencies — when referencing another IG, the project must pin the package/version and check the FHIR base, canonical URLs, and dependency graph.
4. Governed migration — change the base version only after a proposal, impact analysis, transform experiments, conformance/integration testing, and a published decision.

VN Core tracks FHIR releases and reference IGs but does not automatically change its base version with another project. Until a replacement decision is published, the current contract remains R4 4.0.1 under the project package.

9. Frequently asked questions

Starting a new project in 2026, R4 or R5?

If the project applies current VN Core, use R4 and pin the package. For other projects, choose the version from the applicable IG/partner contract and CapabilityStatement; an R5 sandbox can support evaluation before a production decision.

Does FHIR deprecate older releases?

HL7 keeps previous publications in its version directory. Do not label an entire release “retired” unless the official page does so. For a new project, select the release required by the target IG and contract; retain DSTU1, DSTU2, or STU3 only where a specific legacy interface requires it, with an explicitly managed conversion boundary.

My FHIR server is already on R4 — am I required to upgrade to R5?

No. Decide from the target IG and partner contract, package/tool support, data-conversion impact, and regression evidence. A newer base version is not an interoperability benefit by itself.

Does VN Core have a roadmap to R5?

The project intends to monitor newer releases, but no R5 schedule or migration decision has been approved. Any future R5 line requires a proposal, impact analysis, implementation testing, and governance review before publication.

What is the most important difference between R4B and R4?

R4B (4.3.0) brings selected changes from R5 development into specific areas, including the SubscriptionTopic model. R4B may be a staging choice for a particular contract, but it is neither a required bridge nor a guarantee of low effort; compare the exact Resources, profiles, packages, and tooling in scope.

10. References and further reading

Official sources

• FHIR Version History — hl7.org/fhir/directory.html
• R4 release history — hl7.org/fhir/R4/history.html
• R4 Resource list — hl7.org/fhir/R4/resourcelist.html
• R5 release history — hl7.org/fhir/R5/history.html
• Managing multiple FHIR versions — hl7.org/fhir/R5/versions.html
• R4 inter-version maps (Informative) — fhir.hl7.org/fhir/r4maps.html
• R4 CapabilityStatement — hl7.org/fhir/R4/capabilitystatement.html
• Bulk Data Access IG — hl7.org/fhir/uv/bulkdata
• FHIR CI build (R6 ballot) — build.fhir.org

National IG references

• US Core — hl7.org/fhir/us/core
• JP Core — jpfhir.jp/fhir/core
• VN Core IG (Ministry of Health IT Department) — github.com/hl7vn/vn-core-ig
• VN Core trial-use (Omi HealthTech) — github.com/HL7-org-vn

Continue in the knowledge hub

Content snapshot: 18 July 2026. Before an implementation or migration decision, recheck release status and compatibility guidance against HL7's official sources.