FHIR R5 is the fifth major release of HL7’s Fast Healthcare Interoperability Resources standard, published in March 2023. For US developers, R5 matters less than expected, because US Core and certification stay on R4 and plan to move directly to R6. Yet R5 ideas, especially topic-based subscriptions, still shape good FHIR design today.
Developers keep asking whether they should upgrade to FHIR R5, and the honest answer surprises many of them: in the US, probably not yet, and possibly never directly. Yet ignoring R5 entirely is also a mistake, because several of its design changes are coming through R6 and backported implementation guides. Taction Software builds FHIR integrations across 200+ healthcare projects since 2013, and this guide explains what R5 changed, what US regulations actually require and how to design systems that move smoothly to future versions.
What FHIR R5 Is and Where It Fits
FHIR has evolved through several releases, each adding resources and maturing others. R4, published in 2019, was the first release with normative content, meaning core resources such as Patient and Observation became stable and protected from breaking changes. R5 followed in March 2023 with significant improvements, but adoption has been uneven because regulators and major implementation guides stayed on R4. Understanding this context explains why R5 matters differently depending on your market. The six points below place R5 within the FHIR timeline, and our FHIR glossary entry covers the fundamentals of the standard.
R4 Remains the Production Standard
R4 is the version most EHRs, payers and certified health IT systems support in production. Its normative resources give developers stability, and nearly every regulatory requirement in the US references R4-based implementation guides such as US Core and SMART App Launch.
R4B Was a Targeted Update
R4B, published in 2022, made limited changes aimed mainly at medication definition and evidence-related resources. Most implementers continued using R4, treating R4B as relevant only for specific use cases rather than a general platform upgrade for clinical integrations. Few teams adopted it.
R5 Added Significant Improvements
R5 introduced reworked subscriptions, new data types, new resources and many refinements to existing resources. It reflects years of implementer feedback, and many developers consider its design cleaner than R4, even though production adoption remains limited, particularly in the United States.
R6 Is the Next Major Target
R6 is in development and has progressed through multiple ballot cycles, with a major goal of making many more resources normative. Its final publication timing should be confirmed on HL7’s official publication history page before making firm planning commitments around it.
US Core Plans to Skip R5
The US Realm Steering Committee has indicated that US Core will move from R4 directly to R6, rather than supporting R5. Because US Core underpins federal certification, this decision effectively limits R5 adoption across the US market for regulated integrations.
Maturity Levels Matter
FHIR assigns maturity levels to resources, from early draft to normative. Normative resources rarely change in breaking ways, while lower-maturity resources may change significantly between versions. Checking maturity before relying on a resource reduces future migration effort considerably. Check before building.
Key Changes Introduced in FHIR R5
R5 brought changes that affect how developers model data, receive notifications and design workflows. Some changes are refinements, while others alter how common patterns work. Even teams staying on R4 benefit from understanding them, because R6 builds on R5 and several capabilities are available on R4 through backport implementation guides. The six changes below are the ones developers ask about most often. Always check the official specification for exact element names and cardinalities, because details matter when mapping between versions and documentation summaries can oversimplify specific differences. Context matters. Verify details.
Topic-Based Subscriptions
R5 redesigned subscriptions around a SubscriptionTopic resource, letting servers publish defined event topics that clients subscribe to with filters. This makes event notifications far more predictable than R4’s query-based approach. Our FHIR Subscriptions glossary entry explains the concept further. Clients receive exactly the events they need.
Subscriptions Backported to R4
The Subscriptions R5 Backport implementation guide brings topic-based subscriptions to R4 and R4B servers. US developers can adopt the improved notification model now without upgrading their entire FHIR version, which is one of R5’s most practical influences on production systems.
CodeableReference Data Type
R5 uses the CodeableReference data type widely, allowing an element to hold either a coded concept or a reference to another resource, or both. This simplifies modeling where data sometimes arrives as a code and sometimes as a full linked resource.
Restructured Resources
Several existing resources, including Encounter and some medication and workflow resources, were restructured in R5 with renamed elements, changed cardinalities and revised status values. Mapping between R4 and R5 for these resources requires careful attention rather than simple version substitution.
New Resources
R5 added resources supporting areas such as permissions, genomics and requirements definition, alongside other additions. Many remain at lower maturity levels, so developers should evaluate stability carefully before building production features that depend heavily on newly introduced resources. Watch their maturity.
Cross-Version Extensions
FHIR provides cross-version extensions that let systems represent elements from one version within another. These help R4 systems carry R5 concepts where needed, supporting gradual adoption rather than all-at-once upgrades across connected partners and systems. Use them sparingly and document every use.
What US Regulations Actually Require
For US developers, regulations matter more than the latest FHIR release. Federal certification, payer interoperability rules and information blocking requirements reference specific implementation guides, and those guides are built on R4. Building on R5 for regulated integrations would create compatibility problems rather than advantages. Understanding what regulators require helps teams invest in the right version and features. The six points below summarize the regulatory reality, and our ONC interoperability rules resource explains the broader certification and information blocking framework in more depth. Regulation, not novelty, should drive version decisions here.
Certification Uses R4-Based Guides
ONC health IT certification references US Core and SMART App Launch implementation guides built on FHIR R4. Certified EHRs therefore expose R4 APIs, and applications integrating with them must use R4 to access patient data through standardized interfaces. R4 skills remain essential.
USCDI Defines Required Data
The United States Core Data for Interoperability defines data classes certified systems must support, mapped through US Core profiles. Our USCDI v3 implementation guide explains requirements developers should plan around for current certification cycles. Data scope grows with each USCDI version.
Payer APIs Use R4 Guides
CMS interoperability rules require payers to support patient access, provider access, payer-to-payer and prior authorization APIs based on R4 implementation guides, including Da Vinci and CARIN guides. Payer integrations should therefore be built on R4 today. Conformance testing matters. Deadlines apply.
Bulk Data Uses R4
The Bulk Data Access implementation guide used for population-level exports runs on R4 in US certified systems. Our guide to FHIR bulk data export implementation explains how developers use it for analytics and value-based care programs. Plan exports around R4.
Information Blocking Applies Regardless
Information blocking rules apply to how organizations share electronic health information, regardless of FHIR version. Choosing R5 does not change obligations, but building on unsupported versions could create barriers that partners reasonably view as limiting access to data. Compatibility matters.
Future Rules Will Target R6
When US Core moves to R6, future certification rules will likely reference R6-based guides, followed by a transition period. Developers should watch regulatory announcements and design systems so moving to R6 involves manageable mapping rather than complete rebuilding. Plan ahead.
When R5 Makes Sense for Your Project
Despite the US focus on R4, some projects benefit from R5 or R5 concepts. International markets, internal data platforms and greenfield products without regulatory integration requirements may find R5’s design advantages worthwhile. The key is separating your internal data model from the versions you expose to partners. The six scenarios below help decide whether R5 belongs in your architecture, and our FHIR R4 implementation guide for developers explains the R4 foundation most US projects should build on first. Each scenario points toward a different, defensible version strategy. Decide deliberately. Context decides.
US Certified EHR Integrations
For integrations with US certified EHRs, use R4. EHR APIs expose R4 resources and US Core profiles, so R5 adds translation work without benefit. This applies to SMART on FHIR apps, patient access apps and most clinical integrations. Stay on R4.
Payer Interoperability Projects
For CMS-regulated payer APIs, use R4 with the required Da Vinci, CARIN and related implementation guides. Building on R5 would create compliance and compatibility risks, because regulators and trading partners expect R4-based guide conformance. Partners expect R4 conformance. Stay aligned with regulators.
International Markets
Some countries and programs have adopted R5 or plan to adopt R6 in national implementation guides. Products serving those markets should follow local guide requirements, which may favor R5 or R6 earlier than the US market does. Check local guides.
Internal Data Platforms
Internal data platforms not exposed to regulated partners can use any internal model, including R5-inspired designs. Many teams store data in a version-neutral internal model, then expose R4 externally, keeping flexibility for future versions. Flexibility pays later. Mapping layers help.
Event-Driven Architectures
Projects needing reliable event notifications benefit from topic-based subscriptions now, using the R4 backport guide. This captures R5’s most useful capability without abandoning R4 compatibility with EHRs and partners that remain on the earlier version. Reliability improves. Polling disappears. Costs drop.
Greenfield Products Launching Late
Products not launching for several years may consider designing toward R6 directly, while supporting R4 for integration. Evaluate this carefully, because ballot versions can change, and production tooling for R6 is still maturing across servers and libraries. Weigh risks carefully.
Designing for R4 Today and R6 Tomorrow
The safest strategy for most US developers is building on R4 while designing for an eventual move to R6. Good architecture keeps version-specific logic contained, so future upgrades affect mapping layers rather than entire applications. These practices also improve systems today by making them cleaner and easier to test. The six practices below are the ones our engineers apply across FHIR projects, and our HL7 v2 to FHIR migration guide applies similar principles when organizations move from legacy messaging to modern APIs. Small choices compound. They reduce risk. Apply them consistently.
Separate Internal and External Models
Keep your internal domain model separate from the FHIR version you expose. A mapping layer converts between them, so moving from R4 to R6 means updating mappings rather than rewriting business logic, storage or user interfaces throughout the application. Upgrades stay contained.
Prefer Normative Resources
Build core functionality on normative resources wherever possible, because they are protected from breaking changes. Use lower-maturity resources deliberately, documenting where they are used, so teams know which areas need attention during future version upgrades. Stability saves money. Document exceptions.
Adopt Subscription Backports
Use the Subscriptions R5 Backport guide for event notifications instead of polling or older R4 subscription patterns. This prepares systems for R6 subscription models while delivering better reliability and efficiency in current production environments immediately. It is low risk. Start now.
Use Mature Libraries and Servers
Choose FHIR servers and libraries that support multiple versions and active upgrade paths. Version-aware tooling reduces migration effort significantly. Our Smile CDR implementation and Medplum implementation services cover two common platforms. Tooling choices affect every future upgrade and partner integration.
Automate Conformance Testing
Validate resources against profiles automatically in CI pipelines. Automated conformance testing catches mapping errors immediately, and it makes version upgrades safer because tests reveal exactly which mappings break when profiles or resource structures change between versions. Confidence grows. Quality improves.
Track Standards Roadmaps
Assign someone to monitor HL7, US Core and regulatory announcements. Knowing when R6 timelines and certification requirements firm up lets teams plan upgrades deliberately rather than reacting under deadline pressure when new rules suddenly take effect. Surprises shrink. Planning wins.
FHIR Development Services and Cost
We build FHIR APIs, integrations, servers and applications for providers, payers and health technology companies. Our work is billed at a blended rate of $50 per hour, and the ranges below are planning figures, not quotes. EHR program fees, server licenses and hosting are separate. Projects start with a short scoping call and, for larger work, a discovery phase that confirms versions, profiles and partners. The six options below describe how organizations typically engage us, and our FHIR API development service page explains our capabilities in more detail. Scope is agreed first.
FHIR Version Assessment: $2,000 to $6,000
An assessment of your FHIR architecture, version choices, profiles and upgrade readiness typically takes 40 to 120 hours. It produces a roadmap showing what to build on R4 now and how to prepare for R6 without disrupting current integrations. Risks are ranked.
FHIR API Build: $10,000 to $60,000
Building a FHIR API exposing your data through US Core profiles typically takes 200 to 1,200 hours, depending on resources, authorization, search requirements and conformance testing. Certification-driven projects usually sit toward the upper end of this range. Scope decides cost.
EHR Integration via FHIR: $6,000 to $24,000
A read-focused FHIR integration with one EHR typically takes 120 to 480 hours, depending on resources, authorization and vendor testing. Write access and multiple EHRs add effort, so most projects start with one system and minimal data scope. Approvals take time.
Subscription Implementation: $5,000 to $20,000
Implementing topic-based subscriptions using the R4 backport guide typically takes 100 to 400 hours, including topic design, filtering, delivery channels and error handling, giving systems reliable event notifications without constant polling of partner servers. Monitoring is included. Partners benefit too.
FHIR Server Implementation: $10,000 to $50,000
Implementing and configuring a FHIR server, with profiles, security, bulk export and monitoring, typically takes 200 to 1,000 hours. Platform choice, data volume and integration count drive where projects fall within this planning range. Licenses are separate. Hosting is separate.
Dedicated FHIR Developers
Organizations with ongoing FHIR roadmaps can hire FHIR API developers at about $8,000 per engineer per month, supporting new resources, partners, profile updates and version transitions as standards and regulations evolve. Engineers bring experience with US Core, SMART App Launch and payer guides.
Why Choose Taction for FHIR Development
FHIR projects succeed when developers understand both the standard and the regulatory and vendor realities around it. Our engineers work daily with EHR APIs, payer guides, integration engines and FHIR servers, so we design for the systems your integrations must actually connect to. We bring 200+ healthcare projects since 2013, ISO 27001 certified processes and experience with both modern FHIR and legacy HL7 environments. We sign Business Associate Agreements before accessing PHI. The six points below explain what working with us on FHIR development looks like in practice for providers, payers and technology companies.
Regulation-Aware Architecture
We design FHIR systems around the implementation guides regulators and partners require, not just the latest specification. This prevents costly mismatches where technically elegant systems cannot connect to certified EHRs or meet payer interoperability requirements. Compliance stays built in. Fit comes first.
FHIR and HL7 v2 Together
Most healthcare environments still rely heavily on HL7 v2. Our FHIR and HL7 integration work bridges both, so modern APIs connect cleanly with existing interfaces rather than forcing disruptive replacements of working systems. Existing investments stay protected. Transitions stay smooth.
Real Integration Experience
For Xoomia, we built a unified EHR platform integrating clinical and administrative data. The Xoomia case study shows the integration depth we bring to FHIR architecture and implementation projects. That experience informs every FHIR architecture decision we make. Lessons carry over.
Future-Proof Design
We separate internal models from external FHIR versions, prefer normative resources and automate conformance testing. These practices keep today’s R4 systems ready for R6, reducing future upgrade cost and protecting the investment you make in integrations now. Upgrades stay manageable.
Security Built In
FHIR APIs expose sensitive data, so we implement OAuth 2.0, SMART scopes, audit logging, rate limiting and encryption from the start. Security reviews by partners and customers go faster because controls are documented and designed in, not added later. Trust follows.
You Own the Code
Code, mappings, profiles, tests and documentation belong to you. We hand everything over in documented form, so your team can maintain and extend integrations internally or continue working with us through ongoing support arrangements. No lock-in applies. Handover is complete.
Frequently Asked Questions
These are the questions developers, architects, CTOs and product leaders ask most often about FHIR R5, whether they are planning a new integration, upgrading an existing FHIR server or preparing for future regulatory requirements. The answers are short on purpose. Standards timelines change, so confirm current status on HL7’s official publication pages before making long-term commitments. If your question depends on your partners, markets or systems, a short call with our team will help. For broader standards context, see our healthcare interoperability explained guide. Ask anything. Answers reflect current plans.
Should I Upgrade From FHIR R4 to R5?
For most US projects, no. Certified EHRs, US Core and payer interoperability guides use R4, and US Core plans to move directly to R6. Adopt useful R5 concepts, such as subscriptions, through R4 backport guides instead. R4 remains essential. Wait for R6.
When Was FHIR R5 Published?
FHIR R5 was published in March 2023. It followed R4, published in 2019, and R4B, published in 2022. R6 is the next major release and has been progressing through ballot cycles toward publication. Confirm R6 status on HL7’s official pages.
Will US Regulations Require FHIR R5?
It appears unlikely. US Core plans to skip R5 and move to R6, so future certification requirements will likely reference R6-based guides. Monitor official ONC and HL7 announcements for confirmed timelines before planning major version upgrades. Watch announcements. R4 stays central.
What Is the Most Useful Change in R5?
For many developers, topic-based subscriptions are the most useful change, enabling reliable event notifications. The Subscriptions R5 Backport guide makes this capability available on R4 servers, so teams can benefit today without a full version upgrade. It is low risk.
How Do I Prepare for FHIR R6?
Separate internal models from external FHIR versions, build on normative resources, adopt subscription backports, use version-aware tooling and automate conformance testing. These practices make future upgrades a mapping exercise rather than a rebuild. Start with architecture. Start early. Test continuously.
How Much Does FHIR Development Cost?
At our $50 blended hourly rate, a FHIR version assessment typically costs $2,000 to $6,000, a FHIR API build $10,000 to $60,000 and a single EHR integration $6,000 to $24,000, depending on scope. Every estimate lists assumptions. Scope decides. Ranges vary.
Tell Us About Your FHIR Project
Share your current FHIR version, partners, target markets and integration goals. In a 30-minute call we will recommend the right version strategy and outline what your integration or upgrade would involve. Book a free consultation. No commitment. It is free.