FHIR R4 vs R5: what changes for data trust scoring
FHIR R4 contains 157 resources and remains the normative baseline for US healthcare interoperability. FHIR R5, published in 2023, introduces 31 new resources and structural changes to subscriptions, evidence handling, and requirements tracking that directly affect how data trust architectures validate provenance, consent, and recency. The version gap is not just a technical migration question; it is a trust architecture question.
FHIR R4 has been the regulatory anchor for US healthcare interoperability since 2019. CMS mandates it. ONC certifies against it. Every major EHR vendor supports it. But FHIR R5, published by HL7 in March 2023, introduced structural changes that go far beyond incremental resource additions. For organizations building data trust architectures, the version change creates specific gaps in how provenance is tracked, how consent is modeled, and how subscription-based data flows are validated.
This is not a post about whether you should upgrade. The ranking content already covers that. This is about what the structural differences between R4 and R5 mean for the trust properties of the data flowing through your systems.
What is FHIR R4?
FHIR R4 (Fast Healthcare Interoperability Resources, Release 4) is the fourth major release of HL7's interoperability standard, published in January 2019. It was the first FHIR release to achieve "normative" status for a core set of resources, meaning those resources are considered stable and will not break between versions.
FHIR R4 contains 157 resources covering clinical, financial, administrative, and infrastructure domains. It is the version mandated by the US Core Data for Interoperability (USCDI) and required for CMS Patient Access and Provider Directory APIs. Nearly every certified EHR in the United States exposes FHIR R4 endpoints.
The normative designation matters for trust architecture because it provides a stability guarantee. When you build validation logic against a normative Patient or Observation resource, you know the structure will not change in a breaking way. That predictability is the foundation of automated data quality scoring.
How many versions of FHIR are there?
HL7 has published five major FHIR releases: DSTU1 (2014), DSTU2 (2015), STU3 (2017), R4 (2019), and R5 (2023). A sixth release, R6, is currently in ballot with an expected publication date of 2025 or 2026.
The naming convention shifted after STU3. "DSTU" stood for Draft Standard for Trial Use. Starting with R4, HL7 dropped the "Draft" label because portions of the specification had reached normative maturity. Each release expanded the resource count, refined the maturity model, and addressed implementation feedback from the prior version.
For data trust purposes, the relevant fact is that most production healthcare systems in the US still run R4. R5 adoption remains limited to specific use cases, research implementations, and forward-looking platform builds. R6 ballot content suggests further changes to evidence-based medicine resources and workflow automation, but production deployment is years away.
What is the FHIR versioning strategy?
HL7 uses a maturity model within each FHIR release. Every resource carries a Maturity Level (FMM) from 0 to 5, plus a "Normative" designation for resources that have achieved full stability. The versioning strategy allows HL7 to publish new resources at low maturity levels while guaranteeing backward compatibility for normative resources.
This means a FHIR release is not a monolithic upgrade. Within R4, some resources are normative (Patient, Observation, Bundle) while others remain at FMM 1 or 2. The same is true in R5. The practical consequence: you cannot treat a FHIR version as a single trust signal. You need to evaluate the maturity level of each resource your system consumes.
FHIR also supports version-specific MIME types and capability statements, allowing servers to advertise which version they support. In theory, this enables graceful version negotiation. In practice, most implementations hard-code a single version and break when they encounter a mismatch.
How many resources are in FHIR R4?
FHIR R4 defines 157 resources. Of those, 12 achieved normative status in the initial R4 publication. The rest carry trial-use maturity levels ranging from FMM 0 (draft) to FMM 5 (production-tested but not yet normative).
FHIR R5 expanded the total to approximately 188 resources, adding 31 new resources and restructuring several existing ones. Some of the additions are entirely new clinical concepts. Others are decompositions of resources that were overloaded in R4.
The resource count difference matters for data trust scoring because each new resource type introduces a new surface area for validation. If your trust architecture validates incoming data against a fixed R4 schema and a system sends R5 resources, those records will either fail validation or pass without appropriate scrutiny. Neither outcome is acceptable.
Key statistics
The five R5 changes that matter for data trust
Not every R5 change affects trust architecture. Many are clinical refinements or convenience additions. But five structural changes have direct implications for how you score, validate, and govern health data.
1. SubscriptionTopic replaces Subscription
R4's Subscription resource was a simple mechanism: subscribe to a query, get notified when results change. R5 replaces this with a two-resource model: SubscriptionTopic (what you can subscribe to) and Subscription (who is subscribing and how they want notifications).
This is not a minor refactor. SubscriptionTopic changes how event-driven data flows are defined, which directly affects provenance tracking. In R4, a subscription-triggered data push carried minimal metadata about why the data was sent. In R5, the SubscriptionTopic resource contains explicit trigger criteria, filters, and notification shapes. That metadata is provenance gold.
For trust scoring, the R5 model lets you answer: "This record arrived because a specific clinical event matched a specific subscription filter at a specific time." R4 subscriptions cannot provide that level of provenance detail.
2. Evidence and EvidenceVariable restructuring
R5 restructured the evidence-based medicine resources significantly. The Citation, Evidence, EvidenceVariable, and EvidenceReport resources were reorganized to better support systematic reviews and clinical decision support.
If your data trust architecture ingests evidence resources to score the clinical validity of decision support outputs, the R5 restructuring changes your validation logic. Evidence resources in R5 carry more granular statistical metadata, which improves concordance scoring but requires new parsing logic.
3. Requirements resource (new)
R5 introduced a Requirements resource that formally captures functional and non-functional requirements for FHIR implementations. This is a governance resource, not a clinical one.
For data trust architecture, the Requirements resource provides a machine-readable way to express what a system expects from its data inputs. You can use it to encode trust floor requirements: "This endpoint requires records with DTI scores above 70" or "This system only accepts data with verified provenance chains." R4 had no equivalent.
4. Provenance resource refinements
The Provenance resource exists in both R4 and R5, but R5 made refinements to agent role coding, entity role definitions, and the relationship between Provenance and AuditEvent. These changes improve the precision with which you can describe who did what to which data and when.
R5's Provenance resource also better supports chains of provenance, where a record has been transformed multiple times across multiple systems. For trust architectures that score provenance depth (as the DTI does, weighting provenance at 25% of the total score), these refinements translate directly into more accurate scoring.
5. NutritionIntake, InventoryItem, and FormularyItem
R5 added resources for domains that were previously modeled as extensions or crammed into generic resources. NutritionIntake, InventoryItem, FormularyItem, and others represent data that was previously unstructured or semi-structured.
The trust implication: data that previously arrived as free-text extensions now has a formal structure. Structured data is scorable data. You can validate completeness, check coding accuracy, and assess recency on a FormularyItem. You cannot do any of that on a free-text extension hanging off a MedicationRequest.
The version gap problem for trust architectures
The core challenge is not choosing R4 or R5. It is handling both simultaneously.
Production healthcare data flows involve dozens of systems, each potentially running different FHIR versions. A hospital EHR might expose R4. A connected lab system might send R5 resources. A research platform might use pre-release R6 structures. Your trust architecture needs to validate, score, and govern all of them.
This creates three specific problems.
First, schema validation must be version-aware. A Subscription resource in R4 and a Subscription resource in R5 are structurally different. If your validation engine applies R4 rules to R5 data, it will flag valid records as malformed.
Second, provenance scoring must account for version-dependent metadata availability. R5 SubscriptionTopic provides richer provenance metadata than R4 Subscription. If you score both the same way, you are either under-scoring R5 data or over-scoring R4 data.
Third, consent models differ between versions. R5's Consent resource was refined to better support granular consent directives. If your consent governance layer (like ConsentOS) ingests both R4 and R5 Consent resources, it needs to normalize them into a common model before scoring.
Why R4 is not going away
US regulatory requirements anchor to R4. The 21st Century Cures Act, CMS Interoperability and Patient Access final rule, and ONC Health IT Certification Program all reference R4. TEFCA's implementation guidance assumes R4 endpoints. US Core profiles are built on R4.
Until CMS or ONC publishes a regulatory mandate requiring R5 support, the US healthcare industry will run on R4. That means your trust architecture must treat R4 as the primary validation target for at least the next 2 to 3 years.
But ignoring R5 is also a mistake. International implementations, research networks, and specialty clinical systems are adopting R5 features now. If your data trust architecture is version-locked to R4, you cannot score data from those sources accurately.
What this means for DTI scoring
The Data Trust Index scores health data records across 8 dimensions: Provenance (25%), Consent (20%), Recency (15%), Quality (10%), Concordance (10%), Validation (10%), Breadth (5%), and Stability (5%). FHIR version differences affect at least four of those dimensions directly.
Provenance scoring benefits from R5's richer metadata. The SubscriptionTopic and refined Provenance resource give you more data points to assess chain of custody. An R5-sourced record with full SubscriptionTopic metadata will score higher on provenance than an equivalent R4 record, all else being equal.
Consent scoring requires version-aware parsing. R5's Consent resource supports more granular directives, which means ConsentOS can extract finer-grained consent signals from R5 data. But it also means the consent dimension needs normalization logic to score R4 and R5 Consent resources on the same scale.
Validation scoring depends on schema version. A record that passes R5 validation but arrives at an R4-only endpoint will fail validation, dropping its DTI score. The trust architecture must detect the incoming version and apply the correct validation rules.
Quality scoring is affected by the new resource types in R5. Data that was previously unstructured (and therefore unscorable for completeness) becomes structured and scorable when it arrives as a proper R5 resource. This raises the quality ceiling for R5 data.
A practical approach to version-aware trust
The DTI Engine handles this through version detection at the point of ingestion. When a record arrives, the engine identifies its FHIR version from the resource metadata, applies version-appropriate validation rules, and normalizes the record into a version-independent trust-scored representation.
This is the same approach that processed 105,000 diagnostic records for imaware across mixed formats. The data arrived in varying structures. The DTI Engine standardized it, scored it, and stored the trust metadata alongside the clinical content. The result: 3 weeks of manual work compressed to 2 hours, with every record carrying a provenance chain and trust score.
The version-aware approach has three requirements. First, maintain validation schemas for every FHIR version you expect to encounter. Second, build normalization logic that maps version-specific structures to a common trust model. Third, preserve the original version metadata as part of the provenance record so downstream consumers know what they are working with.
Looking ahead to R6
FHIR R6 is in ballot. Early content suggests further changes to workflow resources, evidence-based medicine resources, and possibly new resources for AI model governance. The pattern is clear: each version adds more metadata surface area, which makes trust scoring both more powerful and more complex.
The organizations that build version-aware trust architectures now will be able to absorb R6 changes when they arrive. The organizations that hard-code to R4 will face the same version gap problem again in 2 to 3 years, but with three versions to support instead of two.
The DTI Engine scores every health data record 0 to 100 across 8 trust dimensions before your AI model sees it. If your team is building on FHIR and needs version-aware trust scoring for training data, compliance, or clinical use, schedule a conversation with the SuperTruth commercial team or (215) 918-4140.
Further reading:
Jason Alan Snyder
Co-founder of SuperTruth and Artists & Robots, and an inventor on the Data Trust Index patents. Twenty-plus years building technology inside Interpublic Group. He writes here nearly every day on data trust, provenance, and what AI should be allowed to act on, and publishes essays on his Substack.
About SuperTruth · LinkedIn · Substack · jasonalansnyder.com
See it in practice
DTI scores the record, not the patient.
8 dimensions. 0 to 100. Travels with every record permanently.