Epic EHR Integration: The Complete 2026 Guide to APIs, Costs, and Best Practices

Epic sits inside more US hospitals than any other EHR vendor, so if your healthcare product needs clinical data, Epic EHR integration is usually the first item on the technical roadmap. It is also where projects stall, because integrating with Epic is less a single API hookup and more a sequence of technical, security, and governance decisions that each affect cost and timeline.

This guide draws on more than 15 years of exclusive healthcare focus and as an EHR software development company at Arkenea, where we have scoped, architected, and shipped EHR integrations and custom EHR platforms for medical practices, digital health companies, and enterprise clients.

It covers what Epic actually offers developers, the integration pathways and their tradeoffs, realistic budgets and timelines, and the mistakes that quietly add months to a project.

What is Epic EHR Integration?

Epic EHR integration is the process of connecting a third party application to Epic’s electronic health record system so the two can exchange clinical, administrative, or financial data. In practice, that connection happens through one or more of Epic’s supported interfaces: FHIR REST APIs, HL7 v2 messaging, SMART on FHIR app launches, CDS Hooks, or Consolidated CDA document exchange.

The nuance that surprises most first time teams is that there is no single Epic API you integrate with once. Every Epic customer runs its own instance, configures it differently, and approves outside connections individually. A working integration is therefore an agreement between three parties: your application, Epic’s interface layer, and each health system that agrees to turn the connection on.

Why Epic EHR Integration Matters in 2026

Epic’s footprint keeps expanding while the rest of the market contracts. The KLAS 2026 US Acute Care EHR Market Share report found that Epic added 77 hospitals and 18,679 beds in 2025 and was the only vendor selected by health systems with more than ten hospitals. Oracle Health, its closest competitor, recorded a third consecutive year of net hospital losses in the same report.

The developer side of that story is equally consequential. Epic’s developer program at open.epic now publishes more than 750 no cost APIs and interfaces, and Epic reports 273 billion annual web service transactions across its publicly available APIs. For a product team, that means the raw connectivity exists; the work lies in choosing the right interfaces and getting each health system to approve them.

Regulation is pulling in the same direction. Under the HTI-1 final rule, certified EHRs must support USCDI v3 as the standardized data baseline, and information blocking rules penalize providers and vendors that withhold electronic health information without a valid exception. Epic has also connected more than 1,000 hospitals and 22,000 clinics to the TEFCA nationwide exchange framework through its Epic Nexus network. The doors to clinical data are not just open, they are legally required to stay open.

When Epic Integration is the Right Move, and When it is Not

Before any technical planning, answer a business question: does your product complement Epic inside organizations that already run it, or are you trying to make Epic do something it was not designed to do? Epic welcomes applications that extend its workflows and reads of its data. It restricts applications that attempt broad write access or try to replace core Epic modules.

The last row matters more than most guides admit. Epic dominates large health systems, but tens of thousands of independent practices run other systems or need EHR functionality of their own. When an eight location physical therapy group approached Arkenea frustrated with a rigid off the shelf system, the right answer was not an Epic integration at all. We built a custom cloud based EHR for Hamilton Physical Therapy that matched their documentation workflow and connected directly to their existing billing software, which cut documentation time and removed duplicate data entry across all eight locations.

Epic Integration Pathways: Choosing the Right Front Door

Epic supports several integration mechanisms, and choosing among them is the single most consequential architecture decision in the project. Each pathway differs in data direction, latency, approval burden, and long term maintenance cost. Most production integrations combine two or more. Arkenea offers Epic EHR Integration Services, get in touch with us today to discuss your project.

FHIR R4 APIs

FHIR, the HL7 standard for RESTful health data exchange, is Epic’s primary API surface for new development. Epic exposes hundreds of FHIR endpoints across resources such as Patient, Observation, MedicationRequest, Condition, AllergyIntolerance, Immunization, DocumentReference, and Appointment. Your application authenticates through OAuth 2.0, requests scoped access, and receives JSON responses it can consume like any modern web API.

FHIR is the right default for patient level, on demand reads: look up a patient, pull their medication list, fetch recent lab results. It is less suited to high volume event streams, because REST polling at scale runs into rate limiting and adds latency. For event driven needs, pair FHIR with an HL7 v2 feed.

SMART on FHIR Applications

SMART on FHIR layers an app launch and authorization framework on top of FHIR, defined in the HL7 SMART App Launch specification. A SMART app can launch inside Epic’s clinician workspace with the current patient and user context passed in automatically, so a clinician opens your tool without a second login or a manual patient search. Patient facing SMART apps launch standalone and authenticate the patient through their MyChart credentials.

If your product needs to live inside the clinical workflow rather than beside it, SMART on FHIR is the pathway to plan around. It carries additional review because your interface renders inside Epic sessions, and health systems will scrutinize usability and clinical safety along with security.

HL7 v2 Interfaces

HL7 v2 predates FHIR by decades and remains the workhorse for real time event feeds inside hospitals. Epic’s interface engine, Bridges, exchanges v2 messages such as ADT for admissions, discharges, and transfers, ORM and ORU for orders and results, and SIU for scheduling. These interfaces push events to you as they happen, which is exactly what FHIR polling does poorly.

The tradeoff is variability and setup cost. HL7 v2 allows extensive local customization, so field usage differs between health systems, and each interface requires configuration work by the site’s Epic team. Plan for message mapping, a testing cycle with the site’s interface analysts, and an integration engine or message parser on your side.

CDS Hooks

CDS Hooks lets an external service inject decision support into Epic at defined workflow moments, such as when a clinician opens a chart or signs an order. Epic calls your service, your service evaluates the context, and returns cards containing guidance, warnings, or suggested actions. Response time expectations are tight, generally well under two seconds, because your service sits inside a clinician’s ordering workflow.

CDS Hooks is powerful for clinical intelligence products, but treat it as an advanced pathway. Alert fatigue is a documented patient safety issue, and health systems reject integrations that fire low value interruptions. Every card your service returns should change a decision often enough to justify the interruption.

Consolidated CDA Document Exchange

Epic exchanges structured summary documents, such as continuity of care documents, through the Consolidated CDA standard. Document exchange suits transitions of care and referral scenarios where a complete snapshot beats granular API queries. Parsing CDA XML is heavier than consuming FHIR JSON, so most teams use it only where document level exchange is the established workflow.

Bulk FHIR Export

For population level use cases, the FHIR Bulk Data specification allows asynchronous export of large cohorts rather than patient by patient API calls. Analytics, registry, and value based care products should evaluate it before building thousands of individual queries. Expect governance review to focus heavily on your data use agreement, because population extracts raise more privacy questions than single patient reads.

Connection Hub, Vendor Services, and Showroom: How Epic’s Developer Programs Work

Epic retired its App Orchard marketplace, and a surprising number of articles still describe it as current. Today, developers work with Epic through programs organized under open.epic. Understanding which program you need prevents both overpaying and under preparing.

Self service API access is the starting point for everyone. You can register, obtain a client ID, and build against Epic’s public sandbox without payment or a formal Epic relationship. Connection Hub is the free listing directory where vendors document their live Epic connections so health systems can find them. Vendor Services is the paid membership tier that adds Epic technical support, design review, and deeper collaboration, and Showroom is the curated storefront where Epic customers discover vetted applications.

Here is the practical guidance we give clients: start self service, and defer paid programs until a real customer demands them. A signed letter of intent from a health system that runs Epic does more for your integration timeline than any membership tier, because the health system’s sponsorship is what actually moves your connection request through their governance process.

Epic EHR API Integration: The Technical Foundations

USCDI and the Data You Can Access at No Cost

The United States Core Data for Interoperability, maintained by the Assistant Secretary for Technology Policy, defines the standardized data classes every certified EHR must expose through FHIR APIs. USCDI v3 is the current certification baseline under HTI-1, and it covers patient demographics, allergies, medications, immunizations, laboratory results, vital signs, problems, procedures, clinical notes, and care team members, among other classes.

Epic makes USCDI data available to app developers at no charge through its FHIR APIs. That single fact reshapes integration economics: the data most products need for a first release is free to access, and your budget goes to engineering, security, and site enablement rather than data licensing.

Authentication: OAuth 2.0 and the Three Launch Patterns

Every Epic API integration authenticates through OAuth 2.0, but the correct flow depends on who initiates the session. Getting this decision right early prevents an expensive rework later, so it is worth walking through the three patterns.

• EHR launch: a clinician working inside Epic opens your app, and Epic passes the current user and patient context through the SMART launch sequence. Use this for provider facing tools embedded in the clinical workflow.
• Standalone launch: a user opens your app directly and authenticates against the health system’s authorization server, with patients typically signing in through MyChart credentials. Use this for patient facing applications.
• Backend services: your system authenticates as itself using a signed JWT client assertion, with no human in the loop. Use this for scheduled jobs, data synchronization, and population level exports.

Public clients such as mobile apps must implement PKCE, since they cannot hold a client secret safely. Token lifetimes vary by organization and are often short, so build refresh handling and token storage hygiene into the client from the first sprint. Treat refresh tokens as PHI grade secrets: encrypt them at rest and scope them to the minimum APIs your workflow requires.

FHIR Versions and Per Site Variability

Epic supports FHIR R4 for new development, but endpoints for older DSTU2 and STU3 versions remain live at organizations that adopted them earlier. More importantly, two health systems on the same Epic version can expose different resources, extensions, and search parameters depending on local configuration. The sandbox tells you what is possible; only the site tells you what is real.

The reliable defense is to interrogate each site’s capability statement, the machine readable self description every FHIR server publishes at its metadata endpoint. Query it during onboarding, gate optional features on what it reports, and re check it after the site’s Epic upgrades. Teams that skip this step discover missing search parameters in production, usually through a support ticket from their first pilot site.

Rate Limits, Pagination, and Error Handling

Epic does not publish a universal rate limit, because throughput is negotiated per organization and constrained by each site’s infrastructure. Assume you will encounter HTTP 429 responses under load, and implement exponential backoff with jitter rather than immediate retries. Large result sets return as paginated FHIR bundles, so follow the next links rather than assuming a single response holds everything.

Design your polling strategy with restraint, because aggressive polling is a common reason site administrators throttle or suspend integrations. If your use case is event driven, ask for an HL7 v2 feed instead of polling FHIR endpoints on a timer. Log every request with correlation identifiers, because when a health system reports a data discrepancy, the ability to reconstruct exactly what you asked and received is what turns a multi week investigation into an afternoon.

Best Practices for Integrating with Epic EHR

These practices come from integration engagements across our healthcare client base, and each one traces back to a project that would have gone faster if the practice had been in place on day one.

1. Start From the Clinical Workflow, Not the API Catalog

Map who touches the data, at what moment, and what decision it informs, before opening the API documentation. Integrations designed backward from a workflow ship smaller and get approved faster, because health system reviewers can see exactly why each data element is requested. Integrations designed forward from the API catalog tend to over request scopes, which triggers longer security review.

2. Scope Read Access First and Treat Write Back as its Own Project

Epic’s write pathways exist but are limited to defined use cases, such as filing device readings to flowsheets or submitting documents. Broad write access to clinical records is not on offer to third parties, and unsupported assumptions about writing data sink more Epic project plans than any technical obstacle. Ship a read only release, prove value, then scope write workflows against the specific APIs Epic actually offers for them.

3. Verify Every Site’s Capabilities Before You Depend on Them

Query capability statements, confirm the FHIR version, and test the exact search parameters your product uses at each new site. Build an automated conformance check that runs during site onboarding, so variability surfaces in a report instead of a production incident.

4. Build Patient Matching as a First Class Module

Your application will hold patient identities from multiple sources, and Epic identifiers differ across organizations. Decide early how you match records: which identifiers you trust, what your confidence thresholds are, and what happens to ambiguous matches. A false merge of two patients’ records is a clinical safety event, so route uncertain matches to human review rather than guessing.

5. Put Compliance Artifacts on the Critical Path

Business associate agreements, security questionnaires, and risk documentation gate your go live just as surely as code completeness. Draft them in parallel with development, not after it. Health system security teams commonly take 4-8 weeks to review a new vendor, and that clock only starts when your paperwork is complete.

6. Instrument the Integration From the First Sprint

Track API latency, error rates, token refresh failures, and data volumes per site from the beginning. Epic sites upgrade quarterly, and an upgrade that changes behavior at one site will show up in your metrics before it shows up in a customer complaint.

7. Budget Calendar Time for Governance, Not Just Engineering

In a typical Epic integration, engineering consumes less than half the elapsed time. Site approvals, security reviews, interface analyst scheduling, and testing windows consume the rest. Plan the project timeline around the governance sequence, and treat engineering as the parallel track rather than the critical path.

Step by Step: How to Integrate a Healthcare App With Epic

Step 1: Define the Use Case and Data Flows

Write down the specific workflow, the data elements it requires, the direction each element moves, and the latency it tolerates. This document becomes the anchor for every later decision, from pathway selection to the scopes on your OAuth request.

Step 2: Confirm Your Target Organizations Run Epic and Will Sponsor You

An Epic integration without a sponsoring health system is a demo, not a product. Validate that your first customers run Epic, and secure a champion inside at least one organization who will move your request through their IT governance. Their sponsorship determines your real timeline more than any technical factor.

Step 3: Choose Your Integration Pathways

Select the minimum set of pathways that serves the workflow: FHIR for on demand reads, SMART for embedded launch, HL7 v2 for event feeds, CDS Hooks for point of care guidance. Resist the urge to adopt every available mechanism, because each pathway you add multiplies testing and site enablement work.

Step 4: Register on open.epic and Build Against the Sandbox

Create your developer account, register the application, select the APIs you need, and obtain sandbox credentials. Epic’s sandbox includes test patients that cover common scenarios, and it costs nothing to use. Expect gaps between sandbox and production behavior, and keep a running list of assumptions to verify at your first live site.

Step 5: Implement Authentication and Consent

Build the OAuth flow that matches your launch pattern, implement PKCE for public clients, and handle token refresh and revocation cleanly. For patient facing apps, design the consent experience carefully, because patients grant access through the health system’s authorization screens and confusion there becomes abandonment.

Step 6: Complete Security Hardening and HIPAA Documentation

Finish encryption, audit logging, access controls, and your risk analysis before requesting production access, since health systems will ask for evidence of all of it. The next section covers what this means architecturally.

Step 7: Go Live at the First Site

Production enablement is site specific work: the organization approves your connection, configures endpoints or interfaces, and tests with you against their environment. Budget 4-8 weeks for a first site even when everything goes well, and capture every configuration detail in a runbook you can reuse.

Step 8: Scale Site by Site and Maintain

Each additional site repeats a shorter version of enablement, typically 2-6 weeks depending on interface complexity and the site’s queue. Maintenance is permanent: Epic upgrades quarterly, FHIR standards evolve, and USCDI versions advance, so allocate ongoing engineering capacity rather than treating go live as the finish line.

HIPAA Compliance as Architecture, Not a Checkbox

Most integration guides mention HIPAA in a closing paragraph, which inverts the actual relationship. The HIPAA Security Rule requires administrative, physical, and technical safeguards for electronic PHI, and those safeguards are architectural decisions that are expensive to retrofit. In our engagements, compliance designed in from the start adds modest cost, while compliance bolted on before a security review can consume an entire quarter.

Architecturally, that means a few concrete commitments. Encrypt PHI in transit with current TLS and at rest without exception, including caches, queues, backups, and logs. Write audit events for every access to patient data, with who, what, when, and from where, and make those logs immutable. Apply minimum necessary access at the API scope level, so your application literally cannot request data classes the workflow does not use.

Contractually, map the business associate chain before signing anything. Your company signs a BAA with each covered entity, and every subcontractor that touches PHI on your behalf, including your cloud provider, signs one with you. Health system security teams check this chain, and a missing subcontractor agreement is an easy reason to send a vendor to the back of the review queue.

Epic Integration Timeline and Cost: What to Actually Budget

Most published estimates are either vague or padded, so here are the ranges we scope against, with the caveat that complexity, write workflows, and site count move every number. Epic’s APIs themselves carry no licensing cost for USCDI data, so nearly all spend is engineering, security, and enablement labor.

Reading that table end to end: a focused, read only FHIR integration typically reaches its first production site in 4-6 months for $65,000 to $150,000 all in. A provider facing SMART application with write workflows and HL7 v2 feeds runs 9-18 months and $150,000 to $300,000 or more. Teams consistently underestimate the site enablement lines, because those costs recur with every customer rather than amortizing across them.

Build Versus Buy: Direct Integration or an Integration Platform

The alternative to integrating directly is routing through an integration platform that maintains EHR connectivity for you and presents a unified API. The honest answer on which to choose depends on three variables: how many EHR vendors you must support, how much integration expertise you have in house, and how sensitive your unit economics are to per transaction fees.

Direct integration wins when Epic is your dominant target, when you have or can hire FHIR and HL7 capability, and when platform fees would compound painfully as volume grows. It gives you full control over performance and data handling, with no intermediary in your PHI flow. The cost is that you own every site enablement and every maintenance cycle yourself.

A platform wins when you need many EHR vendors quickly, when speed to pilot matters more than marginal cost, or when your team has no health data engineers yet. The tradeoffs are recurring fees that scale with usage, another business associate in your compliance chain, and dependence on the platform’s roadmap. A middle path we often recommend: go direct with Epic where your customers concentrate, and use a platform for the long tail of other EHRs until volume justifies more direct work.

Common Pitfalls in Epic Integration Projects

Certain failure patterns repeat across the Epic projects we have scoped, rescued, or rebuilt. Naming them is the cheapest form of risk management available.

• Assuming write access that does not exist. Teams design products around updating Epic records, then discover third party writes are limited to specific workflows. Validate write pathways against Epic’s actual API list before committing a roadmap to them.
• Treating the sandbox as production truth. Sandbox data is clean and complete; production data is neither. Test against messy demographics, missing fields, and unexpected code systems before your pilot does it for you.
• Ignoring the per site multiplier. A working integration at one health system is one working integration, not a scalable product. Cost every deal with site enablement labor included.
• Under scoping patient matching. Identifier mismatches across systems produce duplicate or wrongly merged records, and both are serious. Design the matching module deliberately, with human review for low confidence cases.
• Deferring compliance until after the build. Security reviews examine architecture, and architecture is hard to change in week 40. Design for the review from week one.
• Polling when you should subscribe. Timer based FHIR polling at scale invites throttling. Event driven needs belong on HL7 v2 feeds or scheduled bulk exports.

One more pitfall deserves its own paragraph: over building the first release. When we developed a telemedicine platform with an integrated custom EHR for United Medical Group, the integration scope was deliberately narrow, with electronic prescribing routed through Surescripts rather than a speculative buildout of every possible connection. That discipline is why the platform shipped and scaled nationally. The same principle applies to Epic work: integrate the workflow your users need this year, and let real usage justify the next interface.

TEFCA and Epic Nexus: The Newer Path Worth Watching

The Trusted Exchange Framework and Common Agreement, or TEFCA, establishes nationwide network to network exchange through designated Qualified Health Information Networks. Epic Nexus is Epic’s QHIN, and adoption has been fast: more than 1,000 hospitals and 22,000 clinics on Epic connected within its first eighteen months. For developers, the interesting piece is Individual Access Services, which lets patient authorized applications retrieve records across participating networks through a single connection.

Be precise about what TEFCA replaces and what it does not. It suits record retrieval use cases, such as a patient app assembling history from multiple health systems, without negotiating access site by site. It does not embed your product in clinician workflows, push events in real time, or write anything back, so treatment focused products still need direct Epic pathways. Watch it, pilot it where retrieval is the core job, and keep it out of the critical path for workflow products for now.

How Arkenea Approaches Epic EHR Integration

Arkenea has spent more than 15 years building exclusively healthcare software, and that specialization shapes how we run integration work. Engagements start with workflow discovery and a pathway architecture document, not with code, because the expensive mistakes in Epic projects are scoping mistakes. Compliance runs as a parallel workstream from the first week, so security review never becomes the surprise gate at the end.

The same discipline extends to knowing when integration is the wrong tool. For MiPHR, a health management platform, the founding physician needed patient collected data to reach treating providers reliably. The pragmatic first release delivered structured reports to any provider through automated eFax, which worked with every practice on day one regardless of their EHR, with API integration positioned as a later phase. Matching the pipe to the workflow, rather than defaulting to the most sophisticated interface, is the judgment call experience buys.

If you are planning an Epic integration, the highest value first step is a scoping exercise that produces the use case definition, pathway selection, and site enablement plan described in this guide. That document typically takes two to four weeks and removes most of the variance from everything that follows. Talk to our team if you want experienced help producing it.

Frequently Asked Questions About Epic EHR Integration

Does Epic have an API?

Yes. Epic publishes more than 750 no cost APIs and interfaces through open.epic, including FHIR R4 REST APIs, HL7 v2 interfaces, and SMART on FHIR launch support. Developers can register and build against Epic’s sandbox without payment or a formal Epic partnership.

How much does Epic EHR integration cost?

A focused read only FHIR integration typically costs $65,000 to $150,000 through its first production site, while complex integrations with write workflows and HL7 v2 feeds run $150,000 to $300,000 or more. Epic charges nothing for USCDI data access itself, so the spend is engineering, security, and per site enablement labor. Ongoing maintenance usually runs 15 to 25 percent of build cost annually.

How long does Epic integration take?

Plan on 4-6 months from kickoff to a first production site for a read only integration, and 9-18 months for complex, multi pathway projects. Governance, security review, and site scheduling consume more calendar time than engineering in most projects. Each additional site adds 2-6 weeks of enablement work.

Is Epic API access free?

Access to Epic’s published APIs and sandbox is free, and USCDI data exchange carries no Epic licensing fee. Costs arise from optional paid programs such as Vendor Services, from your own development and compliance work, and from each health system’s implementation effort.

Can my app write data back to Epic?

Only through specific write enabled pathways, such as filing device observations to flowsheets, submitting documents, or posting questionnaire responses. Broad write access to clinical records is not available to third party applications. Scope your product around reads first and validate each write workflow against Epic’s actual API catalog.

Do I need Epic’s permission to integrate?

You need two things: registration through open.epic for credentials, and approval from each health system whose Epic instance you connect to. The health system’s governance process, not Epic corporate, is usually the pacing item. A sponsoring champion inside the organization shortens it considerably.

Should I use FHIR or HL7 v2 for Epic integration?

Use FHIR R4 for on demand, patient level reads and for anything patient facing. Use HL7 v2 when you need real time event streams such as admissions, results, or scheduling changes pushed to your system. Many production integrations use both, with FHIR for queries and v2 feeds for events.

What replaced Epic App Orchard?

Epic reorganized its developer ecosystem under open.epic, with free self service API access, the Connection Hub directory for documenting live vendor connections, the paid Vendor Services program for deeper Epic support, and the Showroom marketplace where Epic customers discover vetted apps.

Do I need to be HIPAA compliant before integrating with Epic?

Yes, in practice. Health systems will not enable a production connection until you demonstrate Security Rule safeguards, provide a risk analysis, and execute a business associate agreement. Building encryption, audit logging, and minimum necessary access into the architecture from the start is far cheaper than retrofitting them for a failed security review.