When a digital health team gets told "we need to integrate with Epic," the immediate response is often either a vague budget estimate or a technical deep-dive into API documentation. Both miss the most important step: understanding what EHR integration actually involves at a business level before any code is written.
EHR integration connects your product to the system where patient data lives — so your application can read the patient's history, medications, diagnoses, and lab results without a clinician copying them manually, and write your outputs (a clinical note, a monitoring result, an order recommendation) back into the patient's chart. Without that integration, your product sits outside clinical workflows. With it, your product becomes part of how care is delivered. That distinction is the difference between a pilot and a deployed product at scale.
What EHR integration actually means — and what it is not
An Electronic Health Record system is the primary data repository for a clinical organisation — where patient demographics, medical history, diagnoses, medications, lab results, imaging orders, clinical notes, and billing information are stored and managed. Epic, Oracle Health (Cerner), and athenahealth are software platforms that run these records. When a clinician opens a patient chart, they are looking at that EHR. When a nurse documents vital signs or a physician places a medication order, those actions are recorded in the EHR.
EHR integration means creating a technical connection between your product and the EHR so that data flows between them. That connection can be read-only — your product reads the patient's data from the EHR to inform its function — or bidirectional, where your product also writes data back into the patient's chart. The distinction matters enormously for cost and complexity: reading data from an EHR is significantly simpler than writing data back, which requires validation logic, error handling, conflict resolution, and careful attention to the EHR's business rules. Write-back roughly doubles the development effort and integration cost.
What EHR integration is not: it is not a simple API call you make once and forget. It is an ongoing relationship with a vendor, a certification process, a per-hospital-site activation, and an annual maintenance commitment. The $3K–$15K annual maintenance cost per interface — for monitoring, error resolution, and API version updates when the EHR vendor releases new versions — is the number that most integration budgets omit and most finance teams later dispute.
The three platforms — market position, strengths, and integration character
- Largest install base — integrating with Epic reaches the widest hospital audience of any single EHR
- Mature, well-documented FHIR R4 implementation with broad resource coverage
- Care Everywhere network — Care Everywhere exchanges data across non-Epic systems including Oracle Health and athenahealth via Carequality
- MyChart patient portal with 200M+ patient accounts — strong patient-facing integration path
- Largest third-party developer community in health IT
- Showroom listing process adds 2–4 months and $500–$2,000/yr cost before most hospital IT teams will engage
- Per-site configuration variability: each hospital customises Epic locally; your integration must account for site-specific code mappings
- No self-serve path to production — each hospital site must activate your integration independently
- Each additional hospital site adds $5K–$20K in configuration, testing, and IT governance
- Second-largest market — reaching Oracle Health sites covers the VA system, DoD, and many large regional health systems
- Ignite APIs provide solid FHIR R4 + SMART on FHIR access designed for third-party developers on Millennium
- CommonWell Health Alliance co-founder — strong interoperability network alongside Epic's Carequality
- Multi-tenant sandbox with synthetic data available faster (4–8 week review vs Epic's 2–4 months)
- Oracle cloud infrastructure integration offers analytics and population health capabilities
- Post-Oracle-acquisition satisfaction scores declined — hospital IT teams more cautious about new integrations during transition period
- Oracle's new EHR (built from scratch on Oracle cloud) is in early rollout — API ecosystem still forming
- OPN fees: Membership $500/yr, partner service $3,000/yr, Millennium Platform Environment $5,000/yr
- Network reach smaller than Epic's — Care Everywhere gives Epic a structural interoperability advantage that is difficult to replicate
growing
- Cheapest major EHR to integrate with ($10K–$48K) — API program built for outside developers from day one
- Cloud-native architecture enables faster integration cycles and standardised developer experience
- Open API ecosystem — more straightforward for basic integrations than Epic due to less certification overhead
- 21st Century Cures Act alignment: interoperability is a design principle, not a retrofit
- Dominant in the ambulatory / multi-specialty / mid-size practice market — the fastest-growing digital health deployment segment
- Smaller acute hospital footprint than Epic or Oracle Health — less critical for products targeting large health systems
- Certification still required for production access — not fully self-serve
- Ambient documentation features are newly embedded (2026) — integration patterns for AI documentation features are still maturing
FHIR, HL7 v2, and why the standard doesn't solve the problem — the data shape is shared; the admission process is not
FHIR (Fast Healthcare Interoperability Resources) is the modern REST/JSON standard for health data exchange. Mandated by the 21st Century Cures Act, FHIR R4 is the required standard for all ONC-certified EHRs in 2026. US Core 6.1.0 and USCDI v3 define the minimum data set all certified EHRs must expose through their FHIR APIs. The previous standard — HL7 v2, a pipe-delimited message format used for 30+ years — is still widely deployed in hospital systems and still required for legacy interface types, but all new integrations should target FHIR R4.
The critical insight about FHIR standardisation: the standard governs the data shape, not the admission process. A Patient resource, an Observation (lab result or vital sign), a MedicationRequest (prescription) look structurally similar whether they come from Epic, Oracle Health, or athenahealth — all profiling against FHIR R4 and USCDI v3. If you write FHIR-reading code for one platform, most of it ports to the others with small changes. But the standard only governs what the data looks like. Each vendor independently decides how you get access to make that FHIR call: how you register, how your app is reviewed, what it costs, and how each individual hospital site activates your credentials. The FHIR call is standardised. The paperwork to be allowed to make it is entirely vendor-specific.
| Protocol | Format | Use in 2026 | Supported by |
|---|---|---|---|
| FHIR R4 | REST API + JSON — modern, developer-friendly | All new integrations — ONC-mandated; target this first for any new development | Epic, Oracle Health, athenahealth — all mandated by 21st Century Cures Act |
| SMART on FHIR | OAuth 2.0 authorisation framework for FHIR apps — defines launch contexts (EHR launch, standalone launch) | Required for EHR-embedded and patient-facing apps; all three platforms support it | Epic (full support), Oracle Health Ignite (full support), athenahealth (full support) |
| HL7 v2 | Pipe-delimited message format — ADT, ORU, ORM message types; 30+ years of deployed base | Legacy: still in use for specific interface types (lab results, ADT feeds); not required for new FHIR-capable integrations | All major EHRs; many hospital integration engines (Mirth, Rhapsody, Ensemble) still operate on HL7 v2 |
| CCDA (CCD) | XML document format — patient summary exchange | Transitional: used for document-level exchange (discharge summaries, referral notes) where FHIR document profiles are not yet fully adopted | All major EHRs; required for Direct message exchange and some Carequality transactions |
Epic Showroom — what replaced App Orchard and what it costs
App Orchard launched around 2017, was renamed App Market in 2021, and was shut down in December 2022. Any article, guide, or vendor that still refers to "App Orchard" as Epic's current marketplace is out of date. The replacement is Epic Showroom, which has three tiers:
Connection Hub is the primary marketplace tier where health systems browse and download third-party applications. Getting a Connection Hub listing is the 2026 equivalent of what getting an App Orchard listing was before 2022. Hospital IT teams frequently ask new vendors for their "Connection Hub listing" as part of the vendor vetting process, meaning its absence creates procurement friction even though it is not technically required to build a FHIR integration.
Toolbox and Workshop are supplementary tiers for workflow tools and configuration tools respectively — most digital health applications target Connection Hub rather than these secondary tiers.
The developer program previously called "App Orchard" is now called Vendor Services, with a reported membership fee of approximately $1,700–$1,900 per year. A Connection Hub listing costs approximately $500 per year. These costs are separate from the integration development costs ($18K–$80K) and the annual maintenance costs ($3K–$15K/yr per interface). The Showroom listing process — from initial submission to production review approval — typically runs 2–4 months. Plan this timeline into your go-to-market roadmap if health system sales depend on a Showroom listing.
The 2026 integration cost breakdown — by platform and scope
Sources: gmware (May 2026); tactionsoft (March 2026); Fora Soft (June 2026). These are agency development cost ranges for a single-site integration by a specialised healthcare technology team. DIY estimates from internal teams without prior EHR integration experience typically run 2–3× higher due to ramp-up time. Multi-site deployments of 5+ hospitals run $100K–$500K+ in total activation costs.
Integration timelines — what actually takes the longest
The development timeline is only part of the story. The variable that extends timelines most — and the one development teams consistently underestimate — is hospital IT governance. Each hospital site has its own security review board, vendor assessment process, procurement workflow, and go-live scheduling calendar. These are controlled entirely by the hospital's IT team, not by the EHR vendor and not by your development partner. A technically complete Epic integration can wait 8–12 weeks for a single hospital site to complete its internal security assessment and schedule a go-live window with their Epic analysts. Plan for this in your commercial timelines, not just your engineering ones.
The architecture decision that determines your second integration cost — normalised translation layer vs vendor-specific code
"Build a FHIR-normalised data layer. Instead of writing Epic-specific code throughout your application, build a translation layer that converts Epic's FHIR resources into your application's internal data model. When you add Cerner or athenahealth integration later, you add a new translation layer — not rewrite the application. This is the single highest-leverage architecture decision for a product that will integrate with multiple EHRs."
The alternative — writing vendor-specific code throughout the application — means Epic's proprietary response formats, SMART on FHIR launch contexts, and local code mappings are embedded across the codebase. When a hospital customer uses Oracle Health instead of Epic, the integration is not a translation module addition — it is an application-wide code change. Most digital health startups that underestimated their second EHR integration budget made this architecture decision incorrectly in the first one.
Find healthcare technology agencies verified on Epic and FHIR
EHR integration is a specialised capability — the combination of FHIR expertise, HIPAA compliance architecture, and experience navigating Epic's Showroom process takes time to build. TechRadiant verifies healthcare technology agencies on documented EHR integration track records, so you can find a partner who has done this before rather than learning alongside you.
HIPAA, the 21st Century Cures Act, and what they require from your integration
EHR integration necessarily involves Protected Health Information (PHI) — patient names, diagnoses, medications, lab results. Any integration that touches PHI triggers HIPAA technical safeguard requirements. Your application must have appropriate encryption (TLS 1.2+ in transit, AES-256 at rest), access controls, audit logging, and a signed HIPAA Business Associate Agreement (BAA) with any vendor that processes PHI on your behalf — including your cloud infrastructure provider, your EHR integration platform, and your healthcare technology development partner.
The 21st Century Cures Act created the regulatory environment that makes EHR integration possible at scale. The Act prohibits information blocking, requires ONC-certified EHRs to provide FHIR API access to third parties, and mandates that vendors cannot charge patients or third-party developers unreasonable fees for standard USCDI data access. This is why all three platforms now provide FHIR R4 APIs — it is legally required, not optional. The read-only USCDI data set is available at no additional cost under the Cures Act; the fees vendors charge are for marketplace listing, developer program membership, and access to data beyond the USCDI minimum.
For a detailed breakdown of offshore vs onshore development compliance risk in healthcare contexts — including state-level restrictions on offshore Medicaid workloads and the OCR enforcement gap — see our healthcare development compliance guide. For the AI security considerations specific to healthcare AI integrations, see our AI security checklist.