How to integrate with EHRs using FHIR, and what it costs

FHIR is no longer the future of healthcare integration. It is the floor you build on. About 70% of US hospitals already support FHIR-based patient app access, TEFCA crossed one billion records exchanged in June 2026, and the EU has written a FHIR-based exchange format into law through the European Health Data Space. If you build healthcare software, the question is not whether to use FHIR. It is how to use it without burning a quarter on avoidable mistakes.

This is the practical version of that answer. It covers which FHIR version to build on, how SMART on FHIR and OAuth actually work, what an Epic integration really costs, what the US and EU rules require, and where these integrations tend to break in production.

Key takeaways

• Build on FHIR R4 (4.0.1). It is the dominant deployed version and the one US certification targets. R6 is still in normative ballot as of mid-2026, with publication realistically in 2027, so track it but do not build production on it yet.

• SMART on FHIR (currently App Launch 2.2.0) is the standard way to authorize apps against FHIR APIs, and it runs on OAuth 2.0.

• Epic on FHIR is free to start: sandbox, app registration, OAuth, and documentation. The real cost of an Epic integration is engineering and the health system's own go-live process, not a license fee. Public dollar figures are third-party estimates, not Epic quotes.

• In the US, TEFCA now has 11 designated QHINs and has passed one billion records exchanged, USCDI v3 has been the required data floor since January 2026, and information-blocking enforcement turned real in February 2026.

• In the EU, the EEHRxF (EHDS Article 15) sets a FHIR-based exchange format, expressed with FHIR, IHE profiles, and SNOMED CT.

What is FHIR, and why did it win?

FHIR won because it used the same building blocks as the rest of the web. Where older healthcare standards leaned on custom document and messaging formats, FHIR (Fast Healthcare Interoperability Resources, an HL7 standard) uses REST, JSON or XML, discrete "resources" like Patient and Observation, and OAuth-based authorization. That made it something a normal web developer could pick up, and adoption followed.

The numbers back the claim. In Firely's 2025 State of FHIR Survey, 71% of respondents reported FHIR in active use in their country, up from 66% the year before, and 73% of countries with health-data-exchange regulations now mandate or advise FHIR (Firely, 2025 State of FHIR Survey, May 2025). In the US, about 70% of hospitals supported FHIR-based patient app access as of 2024, according to ASTP/ONC (Data Brief 79, August 2025). Read that number carefully, because it is often quoted higher. The commonly cited "nine in ten hospitals" figure counts any API-based patient access, not FHIR specifically; in the 2024 data, any-app API access was about 81% and FHIR-based access about 70%. It runs higher for the market-leading EHR than for the rest of the field.

R4 vs R5 vs R6: which FHIR version should you build on?

Build on R4. Specifically 4.0.1, which is the version US certification targets and the one the installed base actually runs (HL7). R5 has been published since March 2023, but production deployment of it is limited, and R6 is not published yet. Here is the current picture.

The version question trips up teams who read that "R6 is coming" and try to build ahead of it. As of mid-2026, R6 is still balloting, and no major EHR supports it. R6 matters because it is positioned as FHIR's first fully normative release, which means fewer breaking changes afterward, so it is worth watching. But the practical move today is to build on R4, keep your resource models clean, and plan the R4-to-R6 migration as a future project rather than a current dependency. R4 is expected to remain a valid target well into the next decade.

What is SMART on FHIR, and how does OAuth fit?

SMART on FHIR is how an app proves it is allowed to touch data in an EHR's FHIR API, and it is built directly on OAuth 2.0. The standard, SMART App Launch (currently version 2.2.0, on FHIR 4.0.1), defines how your app launches, gets an access token, and requests only the data it needs (HL7).

In plain terms, the flow works like this. Your app registers with the EHR and gets a client identifier. When a user launches it, the app is redirected to the EHR's authorization server, the user authenticates, and the app receives an access token scoped to specific resources. Those scopes are the important part. A SMART scope like patient/Observation.read says your app can read observations for one patient and nothing more. Get the scopes wrong and your app either asks for too much and gets rejected, or asks for too little and breaks at runtime. Most first-integration pain lives here, in registration and scopes, not in reading the data itself.

How do you integrate with Epic, and what does it really cost?

Starting an Epic integration is free. Epic on FHIR gives you a testing sandbox, app registration with OAuth client management, and documentation at no charge, and Epic states plainly that it is a free resource for developers (Epic on FHIR). So the honest answer to "what does Epic integration cost" is that the connection itself is not where the money goes.

The cost is the work around it. There is your own engineering effort to build and test the integration, the mapping and normalization of data between your model and Epic's, and, most of all, the health system's own process to connect your app to their production Epic environment and take it live. That last part depends on the hospital's schedule and staffing, not Epic's pricing, and it is usually the long pole.

You will find dollar figures online, often quoted as ranges from tens of thousands to low six figures per site, with multi-month timelines. Treat those as unofficial third-party estimates, not Epic quotes, because Epic publishes no such numbers. They are also close to meaningless without scope: a read-only single-resource integration and a bidirectional clinical workflow are different projects by an order of magnitude. If you need a real number, scope the specific integration and the specific go-live, then estimate from that. Anchoring to a blog's range will mislead you in both directions.

What do the US rules require: TEFCA, USCDI, and information blocking?

Three US frameworks decide what you have to support, and all three moved recently. Start with the data floor. Since 1 January 2026, USCDI v3 has been the required baseline data set for certified health IT under the HTI-1 Final Rule (ASTP/ONC). Later versions exist, but they are voluntary; v3 is the mandated floor.

TEFCA is the national exchange network, and it has scaled fast. As of mid-2026 there are 11 designated QHINs (Qualified Health Information Networks), and the network passed one billion records exchanged in June 2026, up from roughly 500 million just four months earlier (HHS/ONC, June 2026). FHIR-based exchange is a required capability on TEFCA's published three-year FHIR roadmap, where QHIN support for FHIR API exchange becomes mandatory in the later stages, though the historical backbone has been document-based. Treat FHIR as the direction TEFCA is phasing in rather than the only transport in use today.

Enforcement is the part that changed most. On 11 February 2026, ASTP/ONC announced it had begun issuing notices of potential non-conformity to certified health-IT developers over the information-blocking and API requirements, the first active enforcement posture since the rules took effect, announced in the same ASTP/ONC update that reported the 500-million-record milestone (ASTP/ONC, February 2026). These are compliance notices under the certification program rather than automatic fines, but the shift from a complaint portal to active notices is the signal that "we will get to it later" is no longer a safe posture.

What does the EU require: the EEHRxF?

In the EU, the exchange format is set by law. The European Electronic Health Record Exchange Format (EEHRxF), codified in Article 15 of the EHDS Regulation (EU) 2025/327, defines the harmonised format EHR systems must import and export (EEHRxF). It is built on standards from recognised bodies, including ISO/TC 215, CEN/TC 251, HL7 and HL7 Europe, IHE, and SNOMED International (EEHRxF), and in practice it is expressed with HL7 FHIR resources, IHE profiles, and SNOMED CT terminology.

For a team that already builds on FHIR, this is reassuring: the EU is standardizing on the substrate you know. The catch is in the profiles and value sets, which are specific to the EEHRxF and firm up through a Commission implementing act expected around 2027. If you sell into the EU, the EEHRxF is one of the two regulatory pillars that sit on top of your integration work. We cover the full obligation in our guide to EHDS compliance for health-tech vendors, and the AI-specific layer in our guide to the EU AI Act for medical devices.

Where do FHIR integrations actually fail?

They rarely fail on the happy path. They fail on the six things below, all of which are documented in HL7 implementer materials, published implementation guides, and peer-reviewed work rather than being folklore.

• Terminology mapping. Mapping between code systems like LOINC, SNOMED CT, and RxNorm is the single most persistent source of integration pain, and a 2024 JMIR systematic review found semantic mapping to be a recurring gap requiring manual work (JMIR, 2024). Budget for it explicitly.

• Cross-EHR variation. Two EHRs can both be "FHIR R4 compliant" and still represent the same data differently, with different optional elements or units. Community profiles like US Core exist to constrain this, but you will still write adapter code per system.

• OAuth scopes and registration. As above, most first-integration failures are authorization problems: a scope your app requests but is not granted, or a registration step specific to one EHR.

• Version mismatch. Mixing R4, R4B, and R5 across connected systems creates subtle bugs. Pin your version and validate against the exact one your partner runs.

• Sandbox versus production. A sandbox proves your code compiles against the spec. It does not prove your integration survives real production data, which is messier, sparser, and less consistent than the example data. Plan a real-data test phase.

• Rate limits and bulk data. Pulling large populations through per-patient calls will hit rate limits. The FHIR Bulk Data (Flat FHIR) export exists for this, and it needs async job handling and batching designed in, not bolted on.

How do you plan a FHIR integration that ships?

Sequence the work so the hard parts surface early, not at go-live. The order below front-loads the things that actually sink projects.

1. Fix your target version and profile up front: R4 (4.0.1), and the specific implementation guide your partner uses (US Core, or the EEHRxF profiles for the EU).

2. Map your data model to the FHIR resources you need, and treat terminology mapping (LOINC, SNOMED CT, RxNorm) as a real work item with its own estimate.

3. Get SMART App Launch and OAuth scopes working against the sandbox before you build features. Confirm you can register, authorize, and read with the exact scopes you need.

4. Test against real production data as early as the partner allows, because the sandbox will not tell you the truth about data quality.

5. Design for bulk export and rate limits from the start if you touch more than a handful of patients.

6. Track the policy layer that applies to you: USCDI v3 and TEFCA in the US, the EEHRxF in the EU. Build to the data floor, not below it.

7. Plan the R6 migration as a future project, and keep your resource handling clean so it is not a rewrite when the time comes.

This is the work KDL does day to day. We build FHIR and SMART on FHIR integrations, map data models and terminology to the profiles a given EHR or the EEHRxF requires, and design around the failure modes above so they surface in week two, not at go-live. We scope compliance up front so USCDI, TEFCA, or EHDS requirements shape the build instead of blocking the release. If you have an integration to ship, tell us about the project, or see what we build.

Frequently asked questions

Which FHIR version should I use in 2026?

Use R4, specifically 4.0.1. It is the version US certification targets and the one deployed across the installed base. R5 is published but has limited production use, and R6 is still in normative ballot as of mid-2026, with realistic publication in 2027. Build on R4 and plan the R6 migration as future work.

Is SMART on FHIR the same as OAuth?

No, but they are closely related. SMART on FHIR (the SMART App Launch standard, currently 2.2.0) is built on top of OAuth 2.0. OAuth provides the authorization mechanism, and SMART adds the healthcare-specific launch flow and the scope model that controls which FHIR resources an app can read or write.

How much does Epic FHIR integration cost?

Starting is free. Epic on FHIR provides the sandbox, app registration, OAuth, and documentation at no cost, and Epic publishes no integration pricing. The real cost is your engineering effort and the health system's own process to connect and take your app live, which varies widely by scope. Any specific dollar range you see online is a third-party estimate, not an Epic figure.

What is the difference between FHIR and the EEHRxF?

FHIR is the underlying standard. The EEHRxF is the EU's specific exchange format, defined in Article 15 of the EHDS, and it is expressed using FHIR along with IHE profiles and SNOMED CT terminology. In short, the EEHRxF is a constrained, EU-specific application of FHIR, with its exact profiles finalized by a Commission act expected around 2027.

Do I have to support TEFCA?

TEFCA participation is voluntary, but it is becoming the practical route to nationwide exchange in the US, with 11 designated QHINs and over a billion records exchanged as of mid-2026. Separately, USCDI v3 is a required data floor for certified health IT, and information-blocking rules apply regardless of whether you join TEFCA.

The short version

FHIR is the substrate, R4 is the version, and SMART on FHIR is how you get in the door. The integration itself is rarely the hard part. The hard parts are terminology mapping, cross-EHR variation, and the health system's own go-live, so plan and budget for those, not for a mythical license fee. On top of the technology sits a policy layer that keeps tightening: USCDI and TEFCA in the US, the EEHRxF and the wider EHDS in the EU.

If you want a team that has shipped this before, KDL builds FHIR-based healthcare software and scopes the compliance work up front. For the regulatory pillars that sit on top of the integration layer, read our companion guides on EHDS compliance and the EU AI Act for medical devices.

This article is for general informational purposes only and reflects standards and regulations that change quickly. Cost and timeline figures are illustrative, not quotes. Confirm FHIR versions, profiles, and policy requirements against the primary sources and your own partners before making build or compliance decisions.

Sources

• Firely. Global FHIR adoption gains momentum (2025 State of FHIR Survey). https://fire.ly/news/fhir-adoption-survey-2025/ (retrieved 2026-07-06)

• ASTP/ONC. Growth of Health IT-Enabled Patient Engagement Capabilities Among U.S. Hospitals: 2021-2024 (Data Brief 79). https://www.healthit.gov/data/data-briefs/growth-health-it-enabled-patient-engagement-capabilities-among-us-hospitals-2021 (retrieved 2026-07-06)

• HL7. FHIR Versions. https://build.fhir.org/versions.html (retrieved 2026-07-06)

• HL7. SMART App Launch (v2.2.0). https://hl7.org/fhir/smart-app-launch/ (retrieved 2026-07-06)

• Epic. Epic on FHIR (official developer site). https://fhir.epic.com/ (retrieved 2026-07-06)

• The Sequoia Project (TEFCA RCE). Designated QHINs. https://rce.sequoiaproject.org/designated-qhins/ (retrieved 2026-07-06)