Integrating with Epic, Oracle Health (Cerner), athenahealth, and the Rest

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

"We integrate with Epic" is one of the most over-promised sentences in health tech, because the people saying it rarely mean the same thing. The electronic health record — the system of record where a clinician's notes, medications, results, and diagnoses live — is not one connector you switch on; it is a different developer program per vendor, each with its own sandbox, review, fees, and go-live. This article is written for the founder, product manager, or hospital IT lead who has been told an EHR integration is "just an API call" and needs to scope it honestly before promising a date to a customer. Get the vendor reality right and you can quote a timeline you will hit; get it wrong and you discover the seven weeks of process hiding behind the two weeks of code after the contract is signed. This is the deep dive behind the single EHR link on the telemedicine integration map.

The shared language, the private doors

Start with the good news, because it is real. Since a 2024 federal rule, every certified electronic health record in the United States is required to expose the same kind of door. The rule is the Office of the National Coordinator's certification criterion known as § 170.315(g)(10), the "Standardized API for patient and population services," and it requires a certified EHR to publish a FHIR R4 API that supports both single-patient access (through SMART on FHIR, the healthcare login layer on top of OAuth 2.0) and multi-patient bulk access [1]. Paired with the information blocking rules from the 21st Century Cures Act — which prohibit a certified actor from unreasonably interfering with access to electronic health information — the effect is that a hospital's certified EHR must offer you a standards-based FHIR door [2]. You are not begging a vendor to build you an API; the API is mandated.

So the data shape is shared. A Patient resource, an Observation (a lab result or vital sign), a MedicationRequest (a prescription) look the same whether they come from Epic or athenahealth, because all of them profile FHIR R4 against US Core 6.1.0 and the USCDI v3 data set, the 2026 certified baseline [3]. If you wrote the FHIR-reading code in the standards article, most of it ports from one vendor to the next with small changes.

Here is the catch, and it is the whole point of this article: the standard governs the data shape, not the admission process. Each vendor decides how you get a key to its door — how you register, how your app is reviewed, what it costs, and how each individual hospital turns you on. The FHIR call is the same; the paperwork to be allowed to make it is not. That paperwork is where telemedicine projects overrun, so the rest of this article is a vendor-by-vendor tour of the doors.

Why every vendor is a separate project

Before the named vendors, learn the shape they all share, because once you see it you can scope any EHR you meet. Every major vendor's onboarding has the same four stages.

Stage one is the sandbox. You build and test against synthetic patient data on the vendor's public test server. No contract, no real patients, often no fee. This is where the FHIR code actually gets written, and because the data is fake, it sits outside your compliance boundary — no Business Associate Agreement needed yet. (Remember, a Business Associate Agreement, or BAA, is the contract that makes it lawful for an outside vendor to handle real patient data; we return to it below.)

Stage two is registration and app review. You register your application in the vendor's developer console, declare the FHIR scopes it needs (the specific permissions, like "read this patient's medications"), and submit to a review that usually includes a security questionnaire. The vendor is deciding whether to let your software near production systems. This stage is mostly waiting, not coding.

Stage three is the marketplace listing, for the vendors that have one. Epic, Oracle Health, and athenahealth all run a catalog where health systems discover apps that work with their EHR. A listing is how a hospital finds you, and it usually carries an annual fee.

Stage four is the per-customer go-live. Even after the vendor approves your app, every individual hospital must turn it on in their environment, with their IT team, on their schedule, and the BAA is signed here, before the first real patient record moves. This stage repeats for every customer, and it is the one founders forget when they imagine "integration" as a one-time event.

The pattern matters more than any single vendor's branding, because vendors rename their programs often. What stays constant is: build in a sandbox, pass a review, get listed, then go live per customer. Hold that template in mind as we walk the big three.

Figure 1. The per-vendor gate. Every major EHR onboarding runs the same four stages. The sandbox uses synthetic data and needs no BAA; real patient data — and the signed BAA — begins only at the per-customer go-live.

Epic: the largest program, and the one you will meet most

Epic is the EHR you are most likely to need, because it runs the largest hospitals. As of KLAS's 2025 acute-care report, Epic holds about 43.7% of U.S. acute-care hospitals and roughly 57% of hospital beds — more than double its nearest competitor — and it kept gaining share through 2025 [9]. If your telemedicine product targets large health systems, Epic integration is not optional.

Epic's developer hub is fhir.epic.com (branded "Epic on FHIR"), a free resource for any developer building patient- or provider-facing apps [4]. The sandbox is real and current: Epic upgraded its public FHIR developer sandbox to a "May 2026" build, so you test against fresh synthetic data [4]. Epic exposes one of the broadest FHIR footprints in the industry — hundreds of API endpoints spanning dozens of R4 resource types, from Patient, Observation, and MedicationRequest through Appointment, DocumentReference, Coverage, and specialty resources for oncology, dental, and genomics [4]. For most telemedicine work you touch a dozen of these; the breadth matters mainly because the resource you need is probably there.

The marketplace is Showroom, Epic's catalog where its health-system customers discover and filter third-party products by category [4]. Showroom replaced the older App Orchard marketplace in 2024, so if you read a 2022-era integration guide that says "list on App Orchard," translate it to Showroom. Production access — the move from sandbox to a live hospital — runs through Epic's vendor program, and for patient-facing record retrieval Epic also offers Individual Access Services (IAS), the path a patient-authorized app uses to pull a record; Epic reports on the order of 800 patient-facing apps live and exchanging data through it [4]. Epic is also an active participant in the Argonaut and Da Vinci FHIR accelerator projects, which is why its FHIR support tends to track the standard closely [4].

The practical scoping lesson with Epic: the code is the easy part because the FHIR surface is mature and well documented. The time goes into the sandbox-to-production journey — registering the app, passing review, getting listed on Showroom, and then the per-customer go-live with each health system's IT team. Budget for the process, not the protocol.

Oracle Health (Cerner): a second giant with a published price list

The second name you will meet is Oracle Health — the platform most people still call Cerner, the company Oracle acquired in 2022. It is the number-two acute-care EHR, at roughly 22% of U.S. hospitals and 20% of beds in the 2025 KLAS data, though it has been losing share to Epic for several years running [9]. Many large and government health systems run it, so it is a common integration target.

Oracle Health's developer console is Code Console (at code-console.cerner.com), the registration point for the Oracle Health Developer Program [5]. Its FHIR R4 APIs cover two platforms — the Millennium Platform (the main Cerner system) and Soarian Clinicals — each with its own public sandbox you can test against before any contract [5]. Oracle, like Epic, makes sandbox testing strongly recommended but not strictly required, and encourages (but does not require) developers to attest to the CARIN Alliance Code of Conduct, a voluntary privacy pledge for consumer health apps [5].

Oracle Health is unusually transparent about cost, which makes it a useful anchor for budgeting. For developers who want the value-added "validated integration" path through the Oracle PartnerNetwork (OPN), Oracle publishes the annual fees directly: OPN Membership at \$500/year, a partner service tier at \$3,000/year (available with OPN membership), and Oracle Health Millennium Platform Environment Access at \$5,000/year [5]. Those fees apply to developers using the certified APIs and seeking validation; Oracle notes that developers who skip the validation process can still connect to and access the certified API resources, but without the value-added services and under stricter marketing rules [5]. The number to carry away is the order of magnitude: a few thousand dollars a year per vendor for the formal partner path, not the six-figure custom-interface fees of the HL7 v2 era.

athenahealth: the cloud-native ambulatory leader

The third major name skews to the other end of the market. athenahealth is a leader in cloud-based ambulatory (outpatient) practices — clinics and physician groups rather than large inpatient hospitals — with roughly 18% of cloud-based ambulatory practices [9]. If your telemedicine product serves outpatient specialties, primary care, or physician groups, athenahealth is a likely target.

athenahealth's developer hub is its Developer Portal (mydata.athenahealth.com), which documents both traditional REST APIs and FHIR R4 APIs, and supports SMART on FHIR scopes for FHIR access [6]. athenahealth advertises a very large API surface — on the order of 800 endpoints across clinical, billing, scheduling, and administrative workflows — reflecting that its platform exposes more than just the clinical record [6].

The distinctive part of athenahealth is its authorization model. Distribution runs through the athenahealth Marketplace, and a practice must explicitly authorize your application before you can touch its data; for Marketplace apps that authorization happens when the practice activates your app [6]. The mental model is per-practice opt-in rather than a hospital-IT go-live ticket, which fits the smaller, more numerous customers in the ambulatory world. The process shape is the same four stages — sandbox, registration, Marketplace listing, per-customer activation — but the per-customer step is lighter weight because the customers are clinics, not hospital systems.

Figure 2. The big three plus the aggregator path, side by side. Every direct vendor needs a signed BAA before real patient data flows; the FHIR R4 data shape is shared, the developer programs and costs are not.

The rest: a long tail and a concentrated market

Beyond the big three sit MEDITECH (about 15% of acute-care hospitals, common in community hospitals), eClinicalWorks and NextGen (together serving well over 150,000 physicians in ambulatory care), and a long tail of smaller and specialty systems [9]. Each has its own developer portal and onboarding, all built on the same FHIR R4 / US Core baseline because the certification rule applies to all of them.

The encouraging fact for scoping is concentration. Industry analysts estimate that fewer than ten vendors account for over 85% of hospital EHR contracts in North America as of late 2025 [9]. That means supporting Epic, Oracle Health, athenahealth, and MEDITECH directly covers the large majority of the inpatient market you are likely to encounter — you do not have to integrate with a hundred systems to reach most patients. The question is whether to integrate even those four directly, or to reach them through one connection, which is the aggregator decision.

The aggregator path: one connection to many records

When your roadmap says "support every EHR our customers use," integrating each one directly is rarely the right first move. The alternative is an aggregator — a company that has already built and maintained the per-vendor connections and exposes a single normalized API to you. You integrate once with the aggregator; the aggregator deals with Epic, Oracle Health, athenahealth, and the rest on your behalf.

Redox is the best-known of these. It runs a hub-and-spoke model: your application makes calls to one Redox API, and Redox manages the connections to each individual EHR, translating the messy reality behind the scenes — HL7 v2, CDA documents, X12 billing files, DICOM imaging, and FHIR — into one consistent JSON interface a non-healthcare engineer can read [7]. The scale is the selling point: Redox reports processing over 20 million transactions per day across roughly 10,000 healthcare organizations and 12,000+ active integrations spanning more than 100 EHR vendors [7]. You trade a per-transaction or subscription fee, plus a layer of indirection, for not maintaining dozens of vendor relationships yourself.

Health Gorilla plays a related but distinct role. Beyond point-to-point integration, it is a Qualified Health Information Network (QHIN) under TEFCA — the Trusted Exchange Framework and Common Agreement, the federal government's framework for nationwide health-data exchange. Health Gorilla was designated a QHIN in late 2023 and went live in early 2024, and it reports reach across 220 million-plus patients, 750,000 clinicians, and 147,000 care sites [8]. The difference matters: a direct integration or a Redox-style aggregator connects you to specific EHR instances your customers run; a QHIN like Health Gorilla lets you query the national network for a patient's records across participating organizations, primarily for read-only retrieval. For a telemedicine product that needs a patient's history regardless of which hospital created it, the national-network path is a genuinely different capability, not just a cheaper pipe.

Figure 3. Three ways to reach the record. Direct integration is N separate onboardings; an aggregator collapses them into one API; a TEFCA QHIN queries the national network for records across organizations. Most products combine them.

The compliance rule that applies to every path

No matter which door you use, one rule is constant, and it is the quiet one teams miss. The EHR vendor, any integration engine, and any aggregator in the path all handle Protected Health Information (PHI) — any health data tied to an identifiable person — so every one of them sits inside your HIPAA compliance boundary and needs a signed Business Associate Agreement (BAA) before a single real field flows. The BAA is the contract that makes it lawful for that vendor to handle patient data on your behalf; without it, the data exchange is a HIPAA violation no matter how well encrypted the connection is. Encryption is necessary, not sufficient — "encrypted" and "compliant" are two different claims, and you need both.

The clean line to remember: a sandbox uses synthetic data and needs no BAA, which is why you can start building today. The moment you point at real patient data in production — at the per-customer go-live — the BAA must already be in place, with the EHR vendor and with any aggregator that sits between you and the record. An aggregator does not remove a BAA; it adds one, because now there are two business associates in the chain instead of one. The contract itself is covered in Business Associate Agreements, and the rule behind it in HIPAA in plain English for product teams.

A worked example: the timeline and cost math

Numbers keep the scope honest, so let us cost a realistic plan: a telemedicine product that needs to read a patient's chart before a visit and write the visit note back after, against the three big vendors.

Start with one vendor. The FHIR read-and-write code itself, once you have sandbox access, is small — call it two engineering-weeks. Now add the parts the standard does not remove. Sandbox setup and learning the vendor's quirks: one week. Mapping your data to US Core profiles and terminology codes: one week. App registration, review, and the security questionnaire: two to four weeks, mostly waiting. The first per-customer go-live with a hospital's IT team: one to three weeks. Taking the midpoints:

2 (code) + 1 (sandbox) + 1 (mapping) + 3 (review) + 2 (go-live) = 9 engineering-weeks

Only two of those nine weeks are FHIR code. The other seven are process. Now multiply for three vendors. The code does not triple — the FHIR calls are similar across Epic, Oracle Health, and athenahealth — but the sandbox, review, and go-live overhead does, because each vendor gates you separately:

3 vendors × ~7 process-weeks each = ~21 process-weeks
+ ~3 code-weeks (shared logic, small per-vendor deltas) = ~24 engineering-weeks

Roughly six months of effort for three direct integrations, most of it process. Against that, weigh the aggregator. A single integration with Redox or Health Gorilla is one onboarding instead of three — call it the same ~9 weeks for the first connection, but then new EHRs arrive as configuration rather than new projects. The trade is a recurring fee (per-transaction or subscription) and a layer of indirection, against the ~15 process-weeks you save by not onboarding vendors two and three yourself. The rule of thumb: one or two vendors, integrate directly; three or more, price the aggregator, because the per-vendor overhead is what compounds, not the code. Fill in your own vendor count and fee; the shape holds. This direct-versus-aggregator-versus-embedded trade is weighed in full in the integration decision guide.

Figure 4. Direct versus aggregator for three vendors. Direct integration repeats the process cost per vendor; an aggregator pays it once and turns new EHRs into configuration, at the price of a recurring fee.

A common mistake to avoid

The most expensive mistake is quoting an EHR integration as "two weeks" because that is how long the FHIR code takes. The code is the smallest part. The sandbox, the version mapping, the app review, the marketplace listing, and the per-customer go-live are the other seven weeks per vendor, and they are mostly out of your control — you wait on the vendor's review queue and the hospital's IT schedule. Quote the process, not the protocol, or you will miss the date.

A close second mistake is treating "we support FHIR" from a vendor or aggregator as the end of due diligence. It tells you the data shape, not whether the specific resources you need are exposed, at the version you target, with write access where you need to write. Epic exposes hundreds of endpoints, but read access to a resource does not imply write access; confirm the exact scopes your workflow needs against the vendor's spec before you commit a date. And confirm the BAA path early — discovering at go-live that an aggregator's standard contract does not cover your use is a launch-day surprise no team wants.

Where Fora Soft fits in

Fora Soft has built real-time video and clinical software since 2005, and in telemedicine the EHR connection is where the schedule risk concentrates, so we scope it as its own project with the vendor process — not just the code — costed in from day one. The requirement comes before the feature: a signed BAA on each EHR vendor and any aggregator before real patient data moves, the version pinned to the 2026 certified baseline (FHIR R4 / US Core 6.1.0) rather than "latest," and the integration path chosen on purpose — direct for one or two vendors, an aggregator or a TEFCA QHIN when the customer list is long or the product needs records from anywhere. Then the capability follows: a video consult that reads the chart before the visit and writes the note back after, against Epic, Oracle Health, or athenahealth, without leaking a field of patient data or surprising the timeline.

What to read next

• HL7 v2, FHIR, and the EHR integration reality
• The integration decision guide: direct, aggregator, or iframe
• The telemedicine integration map: what connects to what

Download the EHR Vendor Integration Cheat Sheet (PDF)

Call to action

• Talk to a telemedicine engineer — book a 30-minute scoping call to talk through your epic ehr integration plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the EHR Vendor Integration Cheat Sheet — One page: the four-stage onboarding every vendor shares, what Epic, Oracle Health (Cerner), and athenahealth each require, when an aggregator (Redox / Health Gorilla / TEFCA) pays for itself, and the BAA rule that applies to every path….

References

1. ONC § 170.315(g)(10) — Standardized API for Patient and Population Services (ONC Health IT Certification Program API Resource Guide) — ASTP/ONC. Requires certified EHRs to expose a FHIR R4 API supporting single-patient (SMART on FHIR) and multi-patient (bulk) access; the certification test kit accepts US Core 3.1.1/4.0.0/6.1.0/7.0.0 on FHIR v4.0.1. Basis for "every certified EHR must offer a FHIR door." Tier 1. https://onc-healthit.github.io/api-resource-guide/g10-criterion/
2. Information Blocking and Application Programming Interfaces (21st Century Cures Act, Cures Act Final Rule) — ASTP/ONC (HealthIT.gov). Prohibits certified actors from unreasonably interfering with access, exchange, or use of electronic health information; the rule that makes a mandated FHIR API enforceable. Tier 1. https://www.healthit.gov/condition-ccg/application-programming-interfaces
3. HL7 FHIR US Core Implementation Guide STU 6.1.0 (against USCDI v3) and the HTI-1 2026 baseline — HL7 / ASTP/ONC. US Core 6.1.0 / USCDI v3 with SMART App Launch is the 2026 certified baseline (compliance date 2026-01-01); the shared data shape across all certified EHRs. Tier 1. https://hl7.org/fhir/us/core/
4. Epic on FHIR developer program (fhir.epic.com), open.epic, Showroom, Vendor Services, and Individual Access Services — Epic Systems. Free FHIR R4 sandbox (upgraded to a May 2026 build), hundreds of API endpoints across dozens of R4 resources, the Showroom marketplace (successor to App Orchard, 2024), IAS with ~800 patient-facing apps, Argonaut/Da Vinci membership. Vendor documentation, used to describe the per-vendor onboarding, not as a regulatory source; re-verify before publish. Tier 4. https://fhir.epic.com/
5. Oracle Health (Cerner) developer program: API access, fees, and Code Console — Oracle. FHIR R4 APIs for the Millennium Platform and Soarian Clinicals; registration in Code Console (code-console.cerner.com); public sandboxes; CARIN Code of Conduct attestation (recommended); published OPN fees — Membership \$500/yr, partner service \$3,000/yr, Millennium Platform Environment Access \$5,000/yr. Vendor documentation; fees subject to change — re-verify before publish. Tier 4. https://www.oracle.com/health/developer/api/
6. athenahealth Developer Portal, FHIR R4 APIs, and Marketplace — athenahealth. REST and FHIR R4 APIs (~800 endpoints), SMART on FHIR scopes, and the Marketplace per-practice authorization/activation model. Vendor documentation; re-verify before publish. Tier 4. https://docs.athenahealth.com/api/docs/fhir-apis
7. Redox healthcare data integration platform — Redox. Hub-and-spoke aggregator translating HL7 v2 / CDA / X12 / DICOM / FHIR into one JSON API; reports 20M+ transactions/day, ~10,000 organizations, 12,000+ integrations, 100+ EHR vendors. Vendor documentation; metrics are vendor-reported — re-verify before publish. Tier 4. https://redoxengine.com/
8. Health Gorilla Qualified Health Information Network (QHIN) under TEFCA — Health Gorilla / ASTP (TEFCA program). Designated a QHIN in late 2023, live early 2024; nationwide reach reported at 220M+ patients, 750K clinicians, 147K care sites; enables national-network record query under the Trusted Exchange Framework and Common Agreement. QHIN designation is an ASTP/TEFCA status; reach metrics are vendor-reported. Tier 4 (vendor) / Tier 1 (TEFCA program). https://www.healthgorilla.com/home/company/qhin
9. U.S. EHR market share, 2025 acute-care and ambulatory (KLAS Research, reported) — KLAS Research via Fierce Healthcare / Healthcare IT News. Epic ≈43.7% of acute-care hospitals / ≈57% of beds; Oracle Health ≈22% / ≈20%; MEDITECH ≈15%; athenahealth ≈18% of cloud ambulatory; fewer than 10 vendors hold 85%+ of hospital EHR contracts. Tier 5 (analyst/secondary); used only for market context, not a compliance claim. https://www.fiercehealthcare.com/health-tech/epic-gaining-more-ground-hospital-ehr-market-share-widens-its-lead-over-oracle-health

Per the source hierarchy, the certified-API mandate, information-blocking rule, and 2026 version baseline are cited to ASTP/ONC and HL7 (refs 1–3, tier 1); the per-vendor onboarding details to each vendor's own developer documentation (refs 4–6, tier 4), used to describe process and cost, not to assert regulation; the aggregator and TEFCA facts to the providers and the TEFCA program (refs 7–8); and market-share context to KLAS via reputable analysts (ref 9, tier 5). Where a vendor's "we support FHIR" marketing is looser than the ONC/HL7 version contract, the article follows the rule and notes that the certified baseline is R4 / US Core 6.1.0. Three of nine sources are tier-1 primary regulatory/standards documents (33% of all sources, and 100% of the sources behind every compliance claim), with all regulatory claims sourced to tier-1 primaries; vendor and market rows are explicitly labelled and used only for non-regulatory process, cost, and context.