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

Quick summary

• Seven FHIR releases have shipped: DSTU1 (30/09/2014), DSTU2 (24/10/2015), STU3 (19/04/2017), R4 (30/10/2019), R4B (28/05/2022), R5 (26/03/2023), with R6 in ballot through 2026.
• R4 = "Mixed Normative + STU" — about 30 core Resources and artifacts carry the Normative label, while the rest of the 146 total Resources remain at Trial Use.
• R5 raises the total to roughly 157 Resources and adds SubscriptionTopic, ImagingSelection, and Permission; R5 itself is STU, not a Normative release.
• VN Core uses R4 to stay aligned with US Core, JP Core, KR Core, CH Core, and the majority of HIS/LIS vendors that have already certified against R4.
• Migration roadmap: R4 to R4B when SubscriptionTopic is needed; R4 to R5 once vendor tooling matures and a binding use case appears.

1. Timeline of seven FHIR releases from 2014 to 2026

FHIR (Fast Healthcare Interoperability Resources) was launched by HL7 International in 2011 under the working name RFH (Resources for Health). The first trial release — DSTU1 — shipped on 30/09/2014 with version code 0.0.82. Twelve years later, the community has gone through seven official releases and is currently balloting the eighth. That cadence is brisk compared to HL7 v2 (which took thirty years to move from V2.0 in 1988 to V2.9 in 2019), and it puts pressure on each country to pick an "anchor" version on which to build its National IG.

The table below summarizes the official release dates (per HL7's history pages) and the status as of May 2026.

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) — shorthand for a major version. R4, R5, and R6 are all Releases; the STU/Normative labels are applied at the Resource or artifact level, not to the entire release.
• Normative — locked in, with no permitted breaking changes. HL7 commits that any artifact marked Normative will retain its semantics across future releases.

R4 was the first release to contain Normative content. In practice, HL7 attached the Normative label to roughly thirty core Resources and artifacts — including Patient, Observation, the Conformance Resources (StructureDefinition, CapabilityStatement, ValueSet), the RESTful API foundation, and the Terminology Service layer. The remainder of R4's 146 Resources stayed at Trial Use, including Encounter, AllergyIntolerance, and MedicationRequest. The implication: when a vendor claims "FHIR R4 Normative compliance," they are talking about the locked subset — not the entire spec.

R5 is not a Normative release. HL7 has been explicit: R5 inherits the Normative labels already established in R4 and promotes a few additional artifacts, but the new content introduced in R5 stays at STU. The accurate phrasing is "R5 = Trial Use, inheriting the Normative artifacts from R4."

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

The comparison table below helps gauge the gap between releases on the axes CIOs typically ask about: Resource count, Normative coverage, supporting ecosystem, and real-world adoption.

One detail often misreported: Bulk Data Access is not a "built-in" feature of R5. Bulk Data is a separate Implementation Guide maintained by HL7 (canonical hl7.org/fhir/uv/bulkdata); the current edition still builds on FHIR R4. When a vendor claims Bulk Data support, ask explicitly which IG version and which FHIR base they support.

4. Why R4 remains the default in 2026

The "R4 or R5?" question comes up whenever a new project hits an architecture decision. The five reasons below explain why R4 remains a sensible choice for most Vietnamese organizations in 2026.

One: the Normative label on core Resources. Patient, Observation, and the Conformance/Terminology cluster are Normative in R4. Investments to build profiles on these Resources will not have to be discarded a few years later. Encounter and AllergyIntolerance remain at Trial Use, but their structures are stable enough for production use.

Two: a mature tooling ecosystem. HAPI FHIR JPA Server, the Firely SDK, Microsoft Azure FHIR Service, Google Cloud Healthcare API, and AWS HealthLake all support R4 at GA. SUSHI, the IG Publisher, and the FSH ecosystem treat R4 as their baseline. Commercial Vietnamese vendors (Ominext, FPT IS, VNPT, Viettel) are likewise rolling out on HAPI R4.

Three: international National IGs all anchor on R4. US Core 6.x and 7.x, JP Core 1.x, KR Core, CH Core, AU Core, IPS (International Patient Summary), and IPA (International Patient Access) all ship on R4. Choosing R4 means VN Core profiles can derive directly from these IGs and harmonize internationally with much less friction.

Four: large-vendor constraints. Epic, Cerner (Oracle Health), and Allscripts have all certified FHIR R4 under the ONC mandate (USCDI, HTI-1). Vietnamese hospitals running Epic or Cerner will naturally connect over R4. Japan's Ministry of Health also chose R4 as the JP Core baseline.

Five: VN Core's maturity. The hl7vn/vn-core-ig repository started by the IT Department of the Ministry of Health (2024) was initialized on R4. The OmiGroup community edition under development at hl7.org.vn stays on R4 to preserve backward compatibility — an intentional choice, not a lazy default.

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

R5 (5.0.0, released 26/03/2023) is the first release shipped after HL7 had four years of operating R4 at scale. R5 raises the total Resource count to about 157, introduces several new Resources, and refactors a handful of older ones.

Notable new Resources

• SubscriptionTopic — standardizes the pub/sub mechanism, letting vendors define a "topic" that clients can subscribe to, instead of subscribing via a query string the way R4 does.
• ImagingSelection — references a specific frame, region, or series within a DICOM object without re-loading the object — important for teleradiology.
• Permission — describes fine-grained access control rules, useful when implementing Consent + ABAC.
• RegulatedAuthorization — supports drug regulatory affairs and the exchange of marketing authorization data.

Structural changes

• Reference tightens its rules around resolved type — clients must validate more carefully.
• Coding is encoded more compactly in JSON; a compact transmission format is now available to save bandwidth.
• Several Resources (MedicationStatement, RelatedPerson, AllergyIntolerance) survive into R5 with small field-level adjustments — read the R5 release notes carefully before mapping legacy data.

R5 adoption sits around 10% and is climbing. Vendor tooling (HAPI, Firely) supports R5 at GA, but the major National IGs (US Core, JP Core) have not yet migrated. The pragmatic answer for 2026: build production on R4, run R5 alongside in staging, and plan the migration once a binding use case appears.

6. R6 in ballot — what to watch for

As of May 2026, HL7 has pushed the CI build to FHIR R6 6.0.0-ballot4 — the first full ballot of R6, consolidating all changes accumulated since R5. Notable items the community is currently debating:

• Resource metadata for AI/ML pipelines — proposals for new Resources describing model cards, training data, and provenance.
• FHIR Workflow toward Normative — Task, ServiceRequest, MessageDefinition, and the execution-pattern cluster may carry Normative labels.
• Better Bundle paging and pagination for Bulk Data and Search.
• SubscriptionTopic extended with security profile and backpressure handling.

Official ETA: ballot 4 during 2026, with Normative publication possible in the 2027 — 2028 window. R6 should not be used in production during this period. Architecture decisions today should rely on R4 (production), R5 (staging), and treat R6 ballot as research-grade tracking.

7. Migration roadmap: R4 to R4B to R5

Migrating between FHIR versions is not "change the config and restart the server." In practice it requires reviewing ConceptMaps, profiles, application code, vendor compatibility, and data migration. The table below sketches a three-step roadmap.

Before pulling the trigger on migration, check the CapabilityStatement.fhirVersion of every vendor in the integration chain. If any component is still on R4, an end-to-end migration to R5 is not feasible — you will need an adapter or have to delay the plan. HL7 publishes official ConceptMaps between releases; for R4 to R4B, the mapping is nearly identity. For R4 to R5, several Resources require manual mapping.

8. Why VN Core chose R4

The decision to anchor VN Core on R4 was not "fear of newer things." It is the result of weighing five factors that HungPM (Phan Mạnh Hùng, CIO/CTO of OmiGroup) and the technical community evaluated together:

1. Backward compatibility with hl7vn/vn-core-ig — the IT Department of the Ministry of Health published the first edition on R4 (canonical http://fhir.ehealth.gov.vn/core/). The community edition under development at hl7.org.vn stays on R4 so it can later be merged or redirected.
2. Alignment with international National IGs — US Core, JP Core, KR Core, CH Core, AU Core, IPS, and IPA are all on R4. The VNCorePatient profile can derive directly from these base profiles.
3. SUSHI and IG Publisher tooling — the entire build, validate, and publish pipeline runs reliably on R4. Investing in GitHub Actions for R4 yields immediate results.
4. Vietnamese vendors are already comfortable with R4 — Ominext, FPT IS, VNPT, and Viettel all ship HIS/LIS or middleware products on HAPI FHIR R4. Choosing R5 would force every vendor to upgrade — a large social cost.
5. R5 has not seen broad Asian adoption yet — neither JP Core nor KR Core has migrated. Running ahead of the regional market does not produce a concrete benefit.

VN Core will track R5 adoption across the major National IGs. When US Core or JP Core publishes a roadmap to R5, VN Core will consider a 2.x version on R5. Until then, R4 stays the baseline.

9. Frequently asked questions

Starting a new project in 2026, R4 or R5?

Choose R4 for production. Stand up an R5 sandbox in parallel to track changes. Migrate only when a binding use case requires native semantics for SubscriptionTopic, ImagingSelection, or Permission.

Does FHIR deprecate older releases?

HL7 does not "deprecate" in the sense of deleting the spec, but the releases prior to R4 (DSTU1, DSTU2, STU3) have been marked obsolete (retired). The specs remain online for historical reference, but they should not be used for new projects.

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

No, it is not required. The decision depends on three factors: whether downstream vendors require R5, whether a new use case can only be satisfied by R5, and whether the operations team has capacity to run a full regression test across every profile after migration.

Does VN Core have a roadmap to R5?

Intent yes, schedule no. OmiGroup and the community have agreed: VN Core 1.x will stay on R4 at least until US Core or JP Core announces its R5 migration. When that signal appears, a community ballot will open for VN Core 2.x.

What is the most important difference between R4B and R4?

R4B (4.3.0) backports a subset of R5 changes for specific Resources — most importantly SubscriptionTopic. R4B was designed as a bridge: a system already on R4 can move to R4B with low effort to gain SubscriptionTopic, without committing to a full migration to R5.

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
• FHIR (current) Resource list — hl7.org/fhir/resourcelist.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 (OmiGroup community edition) — github.com/HL7-org-vn

Continue in the knowledge hub