TL;DR — key facts at a glance
EHR integration is unlike a typical API project in one decisive way: the standards, the authorization model and the compliance surface are the work — the screens are the easy part. Here is what healthtech leaders need upfront:
- The stack is layered: HL7 v2 still moves most data inside hospitals, FHIR R4 is the modern API standard, C-CDA carries clinical documents, and SMART on FHIR handles app launch and authorization.
- FHIR R4 is effectively mandated. Under the 21st Century Cures Act and ONC rules, certified EHRs must expose standardized FHIR APIs — and through 2026, USCDI v3 expands the required data classes.
- National exchange is arriving via TEFCA, coordinated by The Sequoia Project. USCDI defines what is shared; TEFCA defines how.
- Cost: a single-EHR read integration runs $40k–$90k; bidirectional or HL7-bridging work $90k–$200k; a multi-EHR platform with an internal FHIR layer $200k–$400k+.
- HIPAA is non-negotiable: access controls, audit logging, encryption, minimum-necessary scoping and BAAs with everyone who touches PHI.
- Live access is gated by the provider, not just the vendor — sandbox first, then per-organization go-live. Plan onboarding as a timeline risk.
The healthcare interoperability stack
"EHR integration" is an umbrella over several standards that coexist. Knowing which ones your project actually touches is the first step to a realistic plan.
- HL7 v2 — the decades-old pipe-delimited messaging standard that still carries most data inside a hospital: ADT (admit/discharge/transfer), ORM/ORU (orders and results), scheduling and billing, usually over MLLP. It is not going away.
- FHIR (Fast Healthcare Interoperability Resources) — the modern standard: RESTful APIs, JSON or XML, and modular resources like Patient, Observation, Condition, MedicationRequest and Encounter. FHIR R4 is the production baseline.
- C-CDA — Consolidated Clinical Document Architecture, the XML document format for clinical summaries (e.g. the Continuity of Care Document) exchanged at transitions of care.
- SMART on FHIR — the launch-and-authorization framework that layers OAuth 2.0 and OpenID Connect on FHIR so a single app can run across multiple EHRs.
- USCDI — the US Core Data for Interoperability, the federally defined minimum dataset (demographics, problems, medications, labs and more) that certified APIs must expose.
Most products do not implement all of these from scratch. They target FHIR R4 for the modern surface, bridge the HL7 v2 feeds they cannot avoid, and ingest C-CDA where documents are the only source. Our healthtech software development services are built around exactly this layered reality, and the broader integration discipline is covered in our enterprise system integration guide.
Why FHIR R4 is now the baseline
For years, EHR integration meant bespoke HL7 v2 interfaces negotiated one hospital at a time. That has changed because of regulation, not fashion.
Under the 21st Century Cures Act and the ONC interoperability and information-blocking rules, certified EHRs must expose standardized FHIR APIs aligned with the US Core Implementation Guide and USCDI. By 2025, the large majority of EHR vendors and health systems had FHIR-enabled APIs in production. The practical consequence: if you are building today, you target FHIR R4 first and treat HL7 v2 as the legacy you bridge, not the primary you design around.
Two moving parts matter for 2026 planning:
- USCDI v3 expands the required data classes beyond the basics — adding, for example, encounter and care-team information — with the standardized data expected to be exposed via modern FHIR APIs aligned to US Core. Design your internal model to map cleanly to USCDI v3 rather than the minimum you need today.
- TEFCA (Trusted Exchange Framework and Common Agreement), coordinated by The Sequoia Project as the Recognized Coordinating Entity, is standardizing nationwide exchange. USCDI defines what must be shareable; TEFCA defines how networks share it. A product that speaks FHIR R4 and maps to USCDI is positioned to connect to TEFCA-aligned networks; one that does not, is locked out.
If you are weighing a custom build against an off-the-shelf integration engine, the trade-offs mirror any other platform decision — see our analysis of custom software vs off-the-shelf.
Integration patterns: Epic, Cerner and the rest
The two largest US EHR vendors — Epic and Cerner (now Oracle Health) — both expose FHIR R4 APIs and run developer programs. The shape of the integration is similar across them, even though the onboarding differs.
The common SMART on FHIR pattern
Across SMART-enabled EHRs the flow is the same: register your app on the vendor's developer portal, declare the OAuth scopes you need (for example patient/Observation.read), implement the SMART on FHIR launch and OAuth 2.0 authorization, validate everything against the vendor sandbox, then request access to a live provider organization. Because the framework is standardized, one well-built SMART app can target multiple EHRs instead of a bespoke build per system.
Epic
Epic publishes its API surface through its Epic on FHIR / vendor-services program. You register the app, choose supported FHIR resources, test against the Epic sandbox, and then go live per organization — with the provider organization granting production access. App orchestration and marketplace listing can follow once the integration is proven.
Cerner / Oracle Health
Oracle Health (Cerner) follows the same logic through its developer code console and FHIR sandbox: register, scope, validate, request live access per site. Supported resources, rate limits and quirks differ from Epic, so cross-vendor products need a normalization layer rather than vendor-specific assumptions baked into the app.
Architecture and stack for EHR data
There is no single "healthcare stack," but production integrations converge on a recognizable shape built around a clean internal data model and strict auditability.
An internal FHIR-shaped data layer
The durable pattern is to normalize everything — FHIR resources, HL7 v2 messages, C-CDA documents — into one internal model (often FHIR-shaped) that your application owns. This decouples your product from any single vendor's quirks and makes adding the next EHR an integration task, not a rewrite. PostgreSQL is a common system of record; FHIR resources store cleanly as JSONB with indexes on the fields you query.
HL7 v2 interface engine and ingestion
Where legacy HL7 v2 feeds exist, an interface engine (open-source options like Mirth/NextGen Connect, or a custom MLLP listener) receives and transforms messages into your internal model. Event-driven ingestion — a queue or stream such as Kafka — decouples the noisy, bursty hospital feed from your application and makes retries and replay tractable. This is core backend and cloud work; our Cloud & DevOps service covers how we build these pipelines.
Authorization, APIs and the rest of the stack
OAuth 2.0 and OpenID Connect underpin SMART on FHIR; token handling, scope enforcement and short-lived credentials are central, not optional. The backend is typically Node.js, Java, Go or Python; the web app is React; clean, idempotent API integration with correct retries and error handling is where reliability is won. The whole thing runs on a HIPAA-eligible cloud (AWS, GCP or Azure) under a signed BAA — standard custom software development, and at multi-facility scale, enterprise software territory.
AI on clinical data
Once you have a clean FHIR layer, AI features — summarizing records, surfacing risks, drafting documentation — become tractable, but they inherit every PHI obligation. Retrieval over patient data must respect scopes and minimum-necessary access, and model providers that see PHI need a BAA. Our generative AI integration service covers building these features on regulated data without widening your compliance surface.
How much EHR integration costs in 2026
Specifics, with the usual caveat that the number of EHRs, read-vs-write and the legacy surface move the figures significantly. These ranges reflect integration-complete builds by an experienced team — not a sandbox demo that mocks the connection.
| Scope | Typical cost | Timeline |
|---|---|---|
| Single-EHR read (SMART on FHIR, OAuth, a few resources) | $40k–$90k | 1.5–3 months |
| Bidirectional / write-back, or HL7 v2 bridging | $90k–$200k | 3–6 months |
| Multi-EHR product with internal FHIR layer + interface engine | $200k–$400k+ | 6–10 months |
| USCDI v3 mapping + TEFCA-ready exchange (add-on) | +$50k–$120k | +1.5–3 months |
These are blended engagements that include authorization, mapping, compliance controls and QA — not just the visible feature. For how custom build cost works more generally, see our custom software development cost guide for 2026.
Where the money actually goes
- Authorization & onboarding (20–30%): SMART on FHIR, OAuth scopes, vendor registration, sandbox validation and per-organization go-live.
- Data mapping & normalization (25–35%): turning vendor-specific FHIR, HL7 v2 and C-CDA into a clean internal model — the work that scales with the number of sources, not screens.
- Compliance & security (15–25%): audit logging, encryption, access control, minimum-necessary scoping and BAA-aware infrastructure.
- The application itself (20–35%): the dashboards, clinician or patient UI and workflows on top.
HIPAA, PHI and the compliance surface
Any system that touches electronic protected health information (ePHI) is in scope for HIPAA, and EHR integration touches it by definition.
- HIPAA Security Rule: access controls, unique user identification, audit logging of every PHI access, and encryption in transit and at rest. For the full engineering checklist, see our HIPAA software development checklist.
- Minimum necessary & scopes: request only the FHIR scopes the feature needs; over-broad access is both a security and a compliance liability.
- Business Associate Agreements: every party that handles PHI — your cloud provider, any subprocessor, an AI model provider — needs a signed BAA. No BAA, no PHI.
- GDPR for EU patients: health data is special-category personal data under GDPR, adding consent, residency and access obligations. Our GDPR guide for US founders covers the cross-Atlantic case.
None of this is optional, and retrofitting consent, audit logging or data residency into a launched platform is far more expensive than designing for it up front.
How to choose an EHR integration partner
General software competence is necessary but not sufficient for healthcare data. This checklist separates partners who can ship a production EHR integration from those who will learn FHIR on your budget.
1. Real FHIR and HL7 experience
Ask specifically about FHIR R4 resources, SMART on FHIR, and HL7 v2 (ADT, ORU). A partner who has registered apps with Epic or Cerner, mapped vendor data to an internal model and bridged a v2 feed will save you months. One who hasn't will discover the hard parts on your project.
2. HIPAA-aware engineering
Look for audit logging, encryption, least-privilege access and BAA-aware cloud setup as defaults, not afterthoughts. Compliance baked into the architecture is far cheaper than compliance bolted on before an audit.
3. Standards fluency
A partner who knows the difference between USCDI and TEFCA, what a C-CDA is, and why SMART scopes matter will ask better questions and build the right thing. Domain fluency shortens discovery and avoids costly rework.
4. Engagement model fit
Healthcare platforms are long-lived and evolve with each new EHR and regulation. A dedicated development team that owns the integration over time usually beats a one-off handoff for anything beyond a contained pilot.
5. Discovery discipline
Insist on a paid discovery that scopes the EHRs, resources, read-vs-write and compliance surface before any fixed-price commitment. A partner who quotes a fixed price for a multi-EHR integration after one call is mispricing risk — our guide on how to choose a software development company covers the full vetting process.
FAQ
What is the difference between HL7 v2 and FHIR?
HL7 v2 is the older pipe-delimited messaging standard that still moves most clinical data inside hospitals — ADT, ORM/ORU and similar messages over MLLP. FHIR is the modern standard: RESTful APIs, JSON/XML, and modular resources like Patient, Observation and MedicationRequest. FHIR R4 is what new integrations target, but most real projects bridge both, plus C-CDA for documents.
Why is FHIR R4 now the baseline for EHR integration?
Under the 21st Century Cures Act and ONC rules, certified EHRs must expose standardized FHIR APIs aligned with US Core and USCDI. The vast majority of vendors and health systems now have FHIR APIs, and USCDI v3 expands the required data through 2026. Without FHIR R4 a platform cannot join modern exchange, including TEFCA.
What are USCDI and TEFCA, and do they affect my product?
USCDI defines what data must be shareable (demographics, problems, medications, labs, and in v3 more classes such as encounter and care-team data). TEFCA defines how networks exchange it nationally, coordinated by The Sequoia Project. If you read or write US clinical data, map your model to USCDI v3 and plan for FHIR-based exchange.
How do you integrate with Epic and Cerner (Oracle Health)?
Both expose FHIR R4 and a developer program. You register an app, use SMART on FHIR with OAuth 2.0, validate against the vendor sandbox, then request live access per provider organization. The pattern is the same across vendors, but onboarding, supported resources and rate limits differ — and live access depends on the provider granting it.
How much does EHR integration cost in 2026?
A single-EHR read integration typically runs $40k–$90k; bidirectional or HL7-bridging work $90k–$200k; a multi-EHR product with an internal FHIR layer $200k–$400k+. The biggest variables are the number of EHRs, read-only versus write-back, and how much legacy HL7 v2 and C-CDA you must bridge.
Is EHR integration subject to HIPAA?
Yes. Any system handling ePHI is in scope for the HIPAA Security and Privacy Rules — access controls, audit logging, encryption, minimum-necessary scoping and signed BAAs with every party that touches PHI, including cloud and AI providers. For EU patients, GDPR adds a parallel layer for special-category health data.
Last updated 22 June 2026. Cost and timeline ranges reflect integration-complete builds for US and EU healthtech clients and will vary by scope, number of EHRs, read-vs-write and legacy surface. Regulatory references are general guidance, not legal advice — consult qualified counsel and your target EHR vendors for current requirements. Request a scoped proposal for your specific product.
