EHR Integration Guide: HL7, FHIR and SMART on FHIR Costs
EHR integration guide covering HL7, FHIR, SMART on FHIR, Epic and Cerner costs and how to choose the right approach.
7 min read
499 views
Key takeaways: EHR integration in 2026 5
How HL7, FHIR and SMART on FHIR differ, what each costs and how to choose.
- Three standards HL7 v2 for legacy feeds, FHIR for modern API access, SMART on FHIR for apps inside the EHR.
- Pick by use case Match the standard to the job. FHIR and SMART cost more upfront but are cheaper to maintain.
- Cost by scope From $15K for read-only FHIR to $150K or more for bidirectional, plus Epic and Cerner fees.
- SMART is fastest A SMART on FHIR app deploys in weeks, custom HL7 suites take 6 to 18 months.
- Engine only if needed An interface engine earns its place for HL7 v2 feeds, less so for pure FHIR.
EHR integration is the part of a healthcare build that quietly sets the timeline and the budget. Connecting your product to Epic, Cerner and other electronic health records means navigating three different standards, vendor certification and clinical data reconciliation. This EHR integration guide explains HL7, FHIR and SMART on FHIR, what each path costs in 2026, and how to choose, so you can scope a healthcare IT project before you start.
In short: EHR integration connects your application to an electronic health record to read and write clinical data, using one of three standards. HL7 v2 carries legacy message feeds, FHIR is the modern REST API, and SMART on FHIR lets an app launch inside the EHR over OAuth 2.0. Cost ranges from about $15,000 for a single read-only FHIR connection to $150,000 or more for bidirectional, multi-system integration, with Epic and Cerner adding certification and licensing fees. Where you can, FHIR and SMART on FHIR are cheaper to maintain than custom HL7 interfaces.
What EHR integration is and why it is the hard part
EHR integration is the work of connecting your software to an electronic health record system so it can exchange patient and clinical data: demographics, encounters, orders, results, medications and documents. The EHR is the system of record, so your product has to speak its language, pass its security model and reconcile its data without ever corrupting a patient record.
That is why integration, not the app, is usually the largest single line item in a healthcare build. You are dealing with vendor-specific APIs, certification programs, strict authorization and the reality that healthcare data is messy. Getting it right is the core of software integration services in healthcare.
The standards you will meet: HL7, FHIR and SMART on FHIR
Three standards from HL7 International cover almost every integration you will build. Most real systems use more than one.
HL7 v2 - the legacy workhorse
HL7 v2 is the decades-old messaging standard still running most hospital data feeds. It moves ADT (admit, discharge, transfer), ORM (orders) and ORU (results) messages over an interface engine. It is everywhere, but it is pipe-delimited, loosely implemented and usually needs transformation logic for each site.
FHIR R4 - the modern REST API
FHIR (Fast Healthcare Interoperability Resources) is the modern standard: a REST API with structured resources, the US Core profiles and bulk data export. It is far cleaner to work with than HL7 v2 and is now mandated across US-certified EHRs, which is why most new integrations target FHIR first.
SMART on FHIR - apps inside the EHR
SMART on FHIR builds on FHIR and adds a secure launch and authorization layer using OAuth 2.0 and OpenID Connect. It lets an app launch inside the EHR with scoped permissions, written once and run across Epic, Oracle Health, Athenahealth and virtually every certified EHR. It is the lowest-maintenance path for apps that live inside the clinician workflow.
HL7 vs FHIR vs SMART on FHIR: which to use
The short rule: HL7 v2 for legacy message feeds, FHIR for modern API access, and SMART on FHIR for apps that launch inside the EHR. The table compares them.
| Standard | Best for | Transport and auth | Build effort | Maintenance |
|---|---|---|---|---|
| HL7 v2 | Legacy message feeds (ADT, ORM, ORU) | MLLP, no modern auth | Lower upfront | Higher, per-site transforms |
| FHIR R4 | Modern API access to clinical data | REST + OAuth 2.0 | Higher upfront | Lower |
| SMART on FHIR | Apps that launch inside the EHR | OAuth 2.0 + OpenID Connect | Moderate, reusable | Lowest, write once run anywhere |
How much EHR integration costs in 2026
EHR integration cost scales with direction, breadth and the EHR vendor. The ranges below reflect 2026 healthcare integration pricing.
| Integration scope | Typical 2026 cost |
|---|---|
| Single read-only FHIR connection | from ~$15,000 |
| Bidirectional multi-resource FHIR | $50,000 - $150,000+ |
| Full custom HL7 interface suite | $50,000 - $250,000+ |
| Epic (App Orchard / Showroom certification) | $18,000 - $80,000 |
| Cerner / Oracle Health API licensing | ~$15,000/yr standard, ~$25,000/yr advanced |
Read-only is far cheaper than bidirectional, because writing back to a patient record raises the bar on validation, certification and testing. Scope this line tightly with your integration team before committing.
Ongoing cost: interfaces are not one-time
Every EHR integration you ship is a thing you maintain. Budget roughly $3,000 to $15,000 per interface per year for monitoring, error resolution and keeping up with vendor API version changes. This is where the standard you chose pays off: HL7 v2 interfaces carry more transformation logic and upkeep, while FHIR and SMART on FHIR are cheaper to maintain over their life.
How long EHR integration takes
EHR integration timelines vary as much as cost, and the standard you pick is the biggest factor.
| Approach | Typical timeline |
|---|---|
| SMART on FHIR app | Weeks |
| Read-only FHIR connection | 2 - 3 months |
| Bidirectional or custom HL7 suite | 6 - 18 months |
SMART on FHIR can deploy in weeks because the launch and authorization are standardized. Traditional custom interfaces have historically taken 12 to 18 months, which is exactly why the industry shifted toward FHIR.
How to integrate with Epic and Cerner specifically
The two biggest EHRs both prefer FHIR and SMART over custom HL7 where possible. Epic integration runs through its App Orchard and Showroom programs, which require certification and carry the highest fees, but give you FHIR and SMART on FHIR access once approved. Cerner, now Oracle Health, exposes official FHIR APIs with annual licensing, which is more economical than building custom HL7 or middleware. For both, targeting FHIR and SMART on FHIR first keeps build and maintenance cost down.
Do you still need an interface engine?
An interface engine such as Mirth Connect or Rhapsody routes, transforms and monitors HL7 v2 messages between systems. If your integration is HL7 v2 heavy, with many feeds and per-site quirks, an interface engine still earns its place. For a pure FHIR or SMART on FHIR integration you often do not need one, since the REST API and standard auth do that work. Many real deployments run a hybrid: an engine for legacy HL7 feeds and FHIR for everything new.
Security and compliance in EHR integration
EHR integration is PHI in motion, so security is not optional. SMART on FHIR uses OAuth 2.0 scopes for least-privilege access, so an app only ever sees the data it was granted. On top of that you need audit logging, encrypted transport and a Business Associate Agreement with every party that touches the data. Integration is where most of the HIPAA surface lives, so plan it together with the controls in our HIPAA software development cost guide, and bring cybersecurity in early.
How to control EHR integration cost
- To control EHR integration cost, prefer FHIR and SMART on FHIR. They cost more upfront than a quick HL7 feed but are cheaper to run and reusable across EHRs.
- Scope read versus write tightly. Read-only is far cheaper. Only build write-back where the workflow truly needs it.
- Reuse certified connectors. Vendor-approved SMART apps and connectors beat rebuilding the same integration per site.
- Budget maintenance from day one. Treat each interface as a yearly cost, not a one-time delivery.
- Start with one EHR. Prove the integration on a single platform, then expand using the same FHIR and SMART foundation built by a software development team with healthcare experience.
How Pharos Production delivers EHR integration
We integrate healthcare products with Epic, Cerner and other EHRs over HL7, FHIR and SMART on FHIR, with the security and audit trails an integration must carry. If you are scoping an EHR integration and need a realistic cost, timeline and approach, our healthcare IT solutions and software integration teams can map it with you.
Sources: 2026 cost, timeline and standards detail synthesized from published EHR integration guides (TactionSoft, Thinkitive, Invene, OSP Labs) and HL7 FHIR and SMART App Launch specifications. Figures are 2026 industry ranges, not quotes; your cost depends on scope, vendor and the number of interfaces.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 7
No matches
Try a different keyword, change the topic or clear filters
-
In 2026, EHR integration ranges from around $15,000 for a single read-only FHIR connection to $150,000 or more for bidirectional, multi-system integration. Epic adds certification fees of roughly $18,000 to $80,000, and Cerner/Oracle Health charges annual API licensing. Budget $3,000 to $15,000 per interface per year for maintenance.
-
HL7 v2 is the older messaging standard that moves pipe-delimited feeds like ADT, orders and results over an interface engine. FHIR is the modern REST API with structured resources and OAuth 2.0 security. HL7 v2 is cheaper to build but needs more transformation logic and upkeep, while FHIR is cleaner and cheaper to maintain.
-
SMART on FHIR is an authorization and launch layer built on top of FHIR, using OAuth 2.0 and OpenID Connect to let an application open securely inside the EHR with scoped permissions. Because it is written once and works across Epic, Oracle Health, Athenahealth and other certified systems, it is the lowest-maintenance option for apps that live in the clinician's daily workflow.
-
A SMART on FHIR app can deploy in weeks. A read-only FHIR connection takes about 2 to 3 months. Bidirectional or custom HL7 interface suites have historically taken 6 to 18 months, because certification and write-back validation dominate the timeline.
-
Epic integration runs through its App Orchard and Showroom programs, which require certification and carry the highest fees. Once approved you get FHIR and SMART on FHIR access. Targeting FHIR and SMART first keeps both build and maintenance cost lower than custom HL7 interfaces.
-
FHIR is now the default for new integrations and is mandated across US-certified EHRs, but HL7 v2 still runs most existing hospital data feeds. In practice many systems are hybrid: an interface engine for legacy HL7 v2 and FHIR or SMART on FHIR for everything new.
-
For HL7 v2 heavy integrations with many feeds and per-site quirks, an interface engine like Mirth Connect or Rhapsody still earns its place for routing and transformation. For a pure FHIR or SMART on FHIR integration you often do not need one, since the REST API and standard auth handle that work.
EHR integration glossary 5
- EHR (Electronic Health Record)
- The digital system that stores the medical history of a patient, used by hospitals and clinics.
- HL7
- A long-standing messaging standard for exchanging clinical and administrative healthcare data between systems.
- FHIR
- A modern HL7 standard that exchanges healthcare data over web APIs using discrete resources.
- SMART on FHIR
- A specification that lets third-party apps securely connect to EHR data using FHIR and OAuth 2.0.
- Interoperability
- The ability of different healthcare systems to exchange and use data without custom one-off work.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
