AI Integration
EHR Integration Cost: What Drives It and How to Estimate It
Learn what drives EHR integration cost, from FHIR and HL7 scope to security review and upkeep, plus a checklist to build a reliable estimate.
October 26, 2026Read more
For US EHR integrations, build on FHIR R4. The R4 versus R5 decision is an ecosystem and conversion-boundary choice: which partner endpoints accept which release, and which data survives down-conversion without loss.
Certified APIs, payer contracts, and EHR sandboxes still speak R4. Picking a newer release because the number is higher breaks search, operations, and profile validation even when the JSON looks familiar. The declared version governs more than the payload: it sets the FHIR MIME type, the base URL, and the search behavior partners rely on. Keep version-specific behavior behind a translation layer so R6 stays open.
FHIR R4 vs R5 at a glance
For a US EHR integration you are building now, FHIR R4 is the baseline, FHIR R5 is a deliberate option for specific modeling, and R6 is a planned successor still in ballot. Teams that need help wiring this into clinical systems can start with our FHIR integration services.
| Criterion | FHIR R4 | FHIR R5 | Build implication |
|---|---|---|---|
| Version and publication | 4.0.1 (confirm the publication date on hl7.org) | 5.0.0, published March 26, 2023 | Pin the declared version in the CapabilityStatement and in every partner contract |
| Overall maturity | Mixed normative and Trial Use content | Classified overall as STU, with normative R4 content carried forward | Judge conformance per resource and per implementation guide |
| US regulatory baseline | Referenced by US Core and ONC certification criteria | Published US Core and certification text stay on R4; recheck both before release | Build US endpoints on R4 first |
| Production adoption | Default for major EHR APIs | Limited production adoption | Confirm each partner endpoint before choosing R5 |
| Successor status | Earlier release; later releases add or change content | Current published release; R6 is in ballot | Plan a version boundary rather than a single upgrade |
The declared version governs the whole interaction: media types, RESTful URLs, search parameters, and operations. An R5 Patient is not an R4 payload with extra fields. The rest of this guide applies three tests: maturity, regulatory baseline, and partner reach.
Release history and what normative status means
HL7 published FHIR R4 version 4.0.1 on December 27, 2018, the first release with normative content, and published FHIR R5 version 5.0.0 on March 26, 2023, according to the FHIR release history. The primary R4 text is the FHIR R4 specification. If you need the standards bodies sorted out first, see our note on FHIR and HL7 roles.
R4 (4.0.1). Normative pieces passed formal review and were treated as stable for production. The same release still mixes in Standard for Trial Use content, so you judge conformance per resource and per artifact.
R4B (4.3). Trial Use changes only. It is its own release. The FHIR HTTP guidance does not require an R4 to R4B to R5 path.
R5 (5.0.0). The full ballot followed the STU process, so the publication is STU overall. Normative R4 content kept that status. Newer clinical, care-planning, and financial material stayed open to feedback. HL7 describes R5 as thousands of incremental updates, corrections, and enhancements.
R6. Ballot in January 2026, with final publication expected later. Do not ship against ballot-only elements.
Normative means the material passed formal review and is stable for production use. Trial Use means it was released for implementer feedback and can still change.
Say one release holds a normative Patient and a Trial Use care-plan resource. The same upgrade is low risk for Patient and high risk for the care-plan resource, because each artifact carries its own maturity label.
What changed between R4 and R5
R5 widens the modeling toolbox and adds compatibility work. The R4 version comparison is the place to start a diff, not a feature wishlist.
| Area | FHIR R4 | FHIR R5 | Build impact |
|---|---|---|---|
| Clinical request resource | RequestGroup resource | Renamed to RequestOrchestration | Update resource names, search parameters, and mappings |
| Coded references | No CodeableReference datatype | CodeableReference datatype added | Map fields that may hold either a code or a reference explicitly |
| Medication elements | R4 Medication structure | Several Medication elements changed | Diff every Medication mapping and profile against R5 |
| Interaction scope | Declared version governs MIME type, URLs, search, and operations | Same rule applied to R5 semantics | Compare CapabilityStatements, not only payload schemas |
| Cross-version content | R5 definitions reachable through cross-version packages | R4 required elements and bindings must still be populated | Log semantic loss for every converted payload |
| Change volume | Baseline release | Thousands of incremental updates, corrections, and enhancements | Regression-test every resource the integration touches |
The rename and the interaction boundary
RequestGroup becomes RequestOrchestration. Any mapping, search parameter, or audit query that names the old resource fails until you update it. CodeableReference needs an explicit rule when a field may be a code or a reference. Medication element changes mean you diff every Medication mapping and profile, not a sample payload.
The declared version also sets MIME-type semantics, URLs, search parameters, $ operations, conditional interactions, paging, and reference targets. Compare CapabilityStatements. A field mapper is not a version adapter.
Pin CodeSystem and ValueSet versions, and the binding strength, on each bound element in the diff. A structurally valid conversion can still fail terminology validation.
When ecosystem interoperability is the priority, we keep an R4 canonical model, expose R5 through a versioned adapter, and isolate profiles, bindings, resource names, and search parameters. Upgrade a resource only where R5 modeling removes a custom extension you maintain. Contract-test every exchanged resource. HL7 does not publish an official throughput or latency comparison, so measure CPU, memory, payload size, and validation latency on your own bundles, using the R4 to R5 differential as the change list, not as a performance claim.
Why US regulation still points to R4
US Core is an HL7 implementation guide, a standard, not a statute. Published US Core versions used for US EHR APIs are built on R4 and define the profiles those APIs are expected to satisfy. Confirm the FHIR version statement on the US Core guide before you freeze scope. USCDI data classes are expressed for exchange through those profiles. Recheck the current USCDI-to-US Core mapping in the release you adopt.
The certification criteria for standardized APIs sit in regulation, 45 CFR Part 170. Read the current text, including 45 CFR 170.215, on eCFR before you publish a conformance claim. The adopted FHIR standard in those criteria references R4.
Our reading of that chain: certified endpoints, SMART on FHIR apps, and payer or provider partners expect R4 payloads. An R5 endpoint is an addition unless the rules change. Product owns certification scope. Engineering owns profile conformance tests. Compliance owns the evidence pack and the version record inside it. For device software, tie that record to SaMD engineering. Where models touch PHI, our guide to HIPAA-compliant AI covers the HIPAA Security Rule expectations in 45 CFR Part 164.
Which EHR and platform endpoints expose R5
R5 can be the newer published release without being the safest default. The FHIR version overview classifies R4 as mixed normative and trial-use content, identifies R5 as the current release but not submitted to ANSI for normative consideration in that overview, and notes that adoption of new releases is slowing and that the speed of R5 adoption is uncertain.
Implementation guides can target both R4 and R5. HL7 Austria publishes national core guides for both, which shows dual-version publication exists. It does not show that any given EHR supports R5. We do not treat a vendor's R5 status as known unless that vendor's own FHIR documentation says so, dated as of a specific month and year.
| Check | Owner | Evidence |
|---|---|---|
| fhirVersion in each endpoint's CapabilityStatement | Integration engineering | Captured CapabilityStatement per endpoint |
| Supported resources and search parameters | Integration engineering | Conformance test run against vendor documentation |
| SMART on FHIR scopes and app registration | Product | Vendor registration record |
| Sandbox availability and write access | Product and engineering | Sandbox test results |
| Vendor version roadmap with its date | Product | Dated vendor documentation, as of month and year |
Launch and scope details belong with SMART on FHIR. File each row against the version decision. Dual-version conformance can lower friction with a partner that requires R5, and it adds test suites, profile maintenance, and governance cost. For clinical workflow products, the same endpoint inventory should cover how a tool such as our clinic assistant will read and write.
R6 status and when to plan for it
As of this drafting, R6 is not the release to build on. R6 has gone through normative balloting, including a January 2026 ballot, but as of October 2026 the FHIR specification site still lists R5 as the current published version. Confirm that status on the FHIR publication directory before you go live. Ballot content can still change, so production code should not depend on ballot-only elements or on an implementation guide that is not published.
In 2025, 38 of 57 respondents reported they were not yet using FHIR R6, which points to R4 remaining more established than newer releases, according to the State of FHIR survey summarized by Firely.
Our view, and it should be revisited once hl7.org shows a final publication: keep R6 out of the production contract, record the R4-to-R6 diff when final content exists, and build the version boundary now so an R6 adapter can be added without rewriting the core model.
Recommendation by scenario
The version decision is made at the conversion boundary, not in the feature list. Pick the release your partners' endpoints actually accept, then design so that supporting a second release costs an adapter, not a rewrite of the core model.
| Scenario | Build on | Design requirement |
|---|---|---|
| Live US EHR integration or certified API | FHIR R4 | US Core R4 profiles, CapabilityStatement checks, and contract tests |
| Multinational SaMD platform with R5 partners | FHIR R4 canonical model | Versioned R5 adapter, resource-level loss log, validation against both guides |
| New internal platform with no external FHIR constraint | FHIR R4 core | Profiles, terminology, and search parameters isolated behind the boundary |
| Customer contract that names R4B | FHIR R4B as its own version | Separate conformance tests; no R4 to R4B to R5 chain is required |
| Partner sends R5-only content | FHIR R4 core with cross-version packages | Document each semantic loss and reject data that cannot be mapped |
HL7's implementation guide documentation distinguishes cross-version packages from ordinary compatibility. Required R4 elements and bindings still have to be populated, and an extension can carry extra R5 meaning. Each down-conversion lands in one of three buckets: lossless, approximate, or a reject. Test payloads against both validators and record the semantic loss per resource, per field. For teams scoping multi-partner healthcare integrations, that boundary belongs in the architecture from the first design session, because retrofitting version handling into a live feed means re-testing every partner contract at once.
The working sequence for standing up that boundary:
Inventory endpoints, partners, and implementation guides.
Diff each resource: elements, cardinalities, types, bindings, extensions, search parameters, operations, and reference targets.
Build the conversion layer with version-specific profiles and terminology isolated.
Run round-trip tests and record data loss, semantic drift, and custom-code behavior.
Benchmark CPU time, memory, payload size, and validation latency on representative bundles.
Compare CapabilityStatements with each partner endpoint before the production gate.
A partner that supports R4B does not automatically support R5. An R5-capable library proves nothing about whether a given R5 guide matches your R4 contracts. My read on gating: the only evidence that matters comes out of steps 4 and 6, not a version string in a dependency file. When a newer release becomes worth supporting, it should arrive as another adapter behind the same boundary, never as a fork of the core model.
Conclusion
The version decision is only as good as the endpoint inventory behind it. Before the next sprint, list every partner endpoint, implementation guide, and certification scope, then assign each a governing release and a conversion boundary. That single artifact shows where R4 holds and where R5 earns an adapter. For the wider picture of standards, vendor programs and integration patterns, see our EHR integration and interoperability guide.
Frequently asked questions
What should a CapabilityStatement capture include?
Store the raw response, the exact endpoint URL, and the advertised version plus interactions, search parameters, operations, MIME types, paging behavior, and reference resolution. A diff across captures is what turns a partner claim into testable scope.
How should an R4 product handle an R5-only partner payload?
Terminate it at a versioned adapter, then accept it only when required R4 elements and bindings still carry the meaning. Log every semantic loss and reject payloads that cannot be mapped cleanly.
Should one public API expose both R4 and R5?
I would keep one public version unless named partners require two, because each exposed version needs its own contract tests, CapabilityStatement checks, and support burden.
What belongs in a version-boundary contract?
Name the accepted FHIR version per endpoint, state which elements may be extensions, prohibit ballot-only content in production exchanges, and set a retest trigger for endpoint changes.
How do we keep an R6 path open without buying it early?
Keep canonical data and validation independent of draft-only elements, and confine version-specific code to adapters that can be swapped when final publication changes the boundary.
Book a consultation with Ekipa's HealthTech engineers to review your endpoint inventory and version boundary: schedule a working session.
