Epic EHR: A Complete Guide to Architecture, FHIR APIs, and Integration

Epic is the default EHR in American healthcare. It runs a larger share of hospital beds than its next two competitors combined, and if you build software for US health systems, you will run into it.

Almost nothing about it works the way a developer would expect. The database is not relational. There is no central endpoint to connect to. The API is free, but getting into production depends on a hospital, not on Epic.

This guide covers how Epic works: the database underneath it, what its FHIR API can and cannot do, the integration paths available to you, what implementation involves, and how it compares to Oracle Health. It is written for people who have to make technical decisions about Epic.

TL;DR

• Epic holds 43.7% of US acute care hospitals and 56.9% of beds as of end-2025 contract data, up from 42.3% and 54.9% the year before (KLAS, 2026).
• More than 325 million patients have a current electronic record in Epic, according to Epic.
• The core suite is EpicCare (the clinical EHR), MyChart (the patient portal, used by over 190 million patients), Cogito (analytics), and Healthy Planet (population health).
• Epic’s production database is Chronicles, a MUMPS-based hierarchical store, not a relational one. That is why integration goes through APIs rather than SQL.
• Epic supports FHIR R4, SMART on FHIR, CDS Hooks, and FHIRcast. The developer sandbox at open.epic.com is free and self-service.
• There is no central Epic endpoint. Every customer runs their own instance and decides which apps connect to it, which is the single biggest thing developers underestimate.
• If you are building a SMART on FHIR app for Epic, our Epic Integration Course covers the path from registration to production.

What is Epic EHR?

Epic EHR is the electronic health record platform built by Epic Systems Corporation, and it is the most widely used EHR in US hospitals. When a clinician at a large academic medical center opens a chart, places an order, or writes a note, they are most likely doing it inside Hyperspace, Epic’s clinical interface.

There is no avoiding it. If you work in health IT in the US, you will interact with Epic.

Epic Systems: Company background

Epic was founded in 1979 by Judith Faulkner, working out of a basement in Madison, Wisconsin with three half-time employees and about $70,000 in capital. It moved to its Verona, Wisconsin campus in 2005 and now employs more than 13,000 people, around 12,500 of them in Verona.

The company is privately held and has never taken outside investment, so it publishes no earnings and answers to no shareholders. Faulkner founded it in that Madison basement and is still CEO nearly 50 years later. She has used that continuity to take a long view on product development, favoring deep clinical integration over fast feature releases. Private ownership also means pricing is opaque and Epic can afford to say no to things, both of which matter later in this guide.

Epic has offices in Bristol, the Netherlands, Dubai, Saudi Arabia, Helsinki, Melbourne, Singapore, Norway and Denmark. In January 2025, North Somerset Council approved its plans for a 90-acre European headquarters campus at Long Ashton near Bristol, with capacity for about 2,150 staff. The decision passed 9-4 against significant local opposition, since the site sits on green belt land.

Epic’s market share

As of end-2025 purchasing data, Epic held 43.7% of US acute care hospitals and 56.9% of beds. Oracle Health was second at 21.9% of hospitals and 20.4% of beds, followed by Meditech at 14.7% and 12.5%.

Two details:

First, Epic wins at the top end. Only two health systems with more than ten hospitals made an enterprise-wide EHR decision in 2025, and both chose Epic. No other vendor won a decision involving more than three multispecialty hospitals. Over five years, Epic has a net gain of 568 hospitals while Oracle Health has lost 173.

Second, the market slowed sharply. The number of hospitals making an EHR purchase decision in 2025 dropped 40% from 2024 and nearly 50% from 2023, which KLAS attributes to policy uncertainty and a shift in attention toward AI investment. Epic’s 2025 share gain was its smallest in percentage-point terms since 2021. Growth is continuing, but from a market where fewer systems are left to switch.

Internationally, Epic has sold into single-payer systems in the UK, Denmark, Finland and Norway since the late 2010s.

Epic’s core product suite

Epic is not one application. It is a set of modules sharing a single patient record.

EpicCare is the clinical EHR: inpatient and ambulatory workflows, documentation, order entry, scheduling, nursing flowsheets, medication administration. Clinicians use it through Hyperspace, Epic’s Windows client.

MyChart is the patient portal, used by more than 190 million patients. Patients view results, message their care team, book appointments, pay bills and share records through it. Patients expect MyChart, and one login reaches every Epic organization they have been seen at.

Cogito is the analytics layer. It includes Reporting Workbench for operational reports and SlicerDicer for ad hoc exploration.

Healthy Planet is the population health module, covering care management, risk stratification, outreach and quality measure reporting for value-based contracts.

Cosmos is Epic’s deidentified research dataset, built from participating customers’ data and now holding 1.7 trillion medical events. This is where most of Epic’s AI work is anchored.

Clinicians use Haiku and Canto on mobile and Rover at the bedside. Chronicles, Clarity and Caboodle are databases rather than clinical products, and are covered in the architecture section below.

Epic EHR architecture: How it works under the hood

If you are expecting a relational database behind a REST API, Epic will surprise you. Its architecture reflects decisions made in the 1970s and 80s, and those decisions explain most of what feels strange about integrating with it.

Epic’s database: MUMPS, Chronicles, and InterSystems IRIS

Epic’s production database is Chronicles, and Chronicles is not relational. It is a hierarchical key-value store built on MUMPS, a language and database created at Massachusetts General Hospital in the 1960s specifically for healthcare.

The commercial implementation Epic runs on comes from InterSystems. For decades that was Caché. Epic began moving to InterSystems IRIS with its August 2020 release, and Caché is now a mature product no longer receiving new development. You will still see Caché referenced in older documentation and in the Enterprise Caché Protocol, which IRIS retains for distributed deployments. If you are reading a guide that says Epic runs on Caché, it was written before 2020 or copied from something that was.

Across all Epic customers, InterSystems reported systems supporting 2.5 million concurrent users and roughly 1.8 billion database accesses per second.

There are no SQL tables in Chronicles. Data lives in multi-dimensional globals, organized into master files, one per record type: patient, encounter, order. This is fast for the thing hospitals actually do, which is read and write one patient’s record thousands of times a day. It is impractical for ad hoc analytical queries, which is why Clarity exists.

For developers, the practical consequence is simple. You will not query Epic’s production database directly. Epic discourages it, and there is no supported path for external systems. Everything goes through an API or a reporting copy.

Chronicles, Clarity, and Caboodle

Three names come up constantly, and people mix them up.

Chronicles, described above, is the live production database. Real-time reads and writes, hierarchical, MUMPS. This is what clinicians are hitting when they use Hyperspace.

Clarity is a relational copy of Chronicles data in SQL Server, populated by a nightly ETL. When an analyst writes SQL against “Epic data”, they are almost always querying Clarity. The nightly refresh means that Clarity is a day behind by design.

Caboodle is Epic’s enterprise data warehouse, also on SQL Server, downstream of Clarity. It carries a dimensional model built for analytics spanning clinical, financial and operational data.

FHIR and Interconnect APIs read from the live transactional database, while Clarity and Caboodle are copies on a nightly cycle. If your application needs current data, you use the APIs. If you need to run population-level analysis across years of history, you use Clarity or Caboodle, or FHIR Bulk Export. Picking the wrong one is a common and expensive early mistake.

Monolithic or modular?

Epic is a monolith, and it is deliberate. Clinical, financial and operational modules share one underlying record.

The upside is that data moves between departments without interfaces. A medication ordered in the ED is visible to the pharmacist immediately. A lab result reaches the ordering physician’s inbox with no integration engine involved. There is no seam between billing and the clinical chart.

The cost is coupling. Customization in one module can change behavior in another, upgrades need validation across everything at once, and adding a third-party component means integration work rather than installing a plugin.

Epic’s investment in SMART on FHIR, CDS Hooks and FHIRcast has changed this. You can embed a third-party application inside the Epic workflow now without Epic building the feature itself. The monolith has openings in it. It is still a monolith.

Epic hosting: On-premise, cloud, and hybrid

Epic runs on-premise, in Epic’s own managed hosting, or on public cloud. Many large health systems still run it in their own data centers or in colocation, but public cloud deployments are now normal.

Both hyperscalers support full production Epic environments. AWS reports that its cloud addresses 90% of Epic customers, supporting both SMP and ECP architectures, and it has been an approved public cloud provider for Epic since 2019. Microsoft offers Azure Large Instances for Epic workloads, which Mount Sinai was the first to run in production.

Cloud is not currently the cheaper option. KLAS found that moving a full Epic production environment to the cloud costs more than hosting it on-premises, even as organizations reduce capital infrastructure spend. The case for cloud Epic rests on reliability, disaster recovery and avoided hardware refresh cycles.

Epic’s own cloud-native work is concentrated in analytics. Cogito Cloud, its SaaS analytics platform, is built on Azure. The core clinical system is not a containerized, cloud-native application, and Epic has not signaled that it will become one.

Epic FHIR API: What’s available and how to access it

Which FHIR resources Epic supports

Epic’s FHIR APIs are free. There are over 700 of them, no per-call charge on the standard ones, and no contract with Epic needed to start using them.

Epic supports DSTU2, STU3 and R4 read, search and write resources, and continues adding support as new FHIR and USCDI versions are published. R4 is where you should be building.

Coverage spans most of the clinical data an application needs: Patient, Encounter, Condition, Observation for labs and vitals, MedicationRequest, AllergyIntolerance, Immunization, Procedure, DiagnosticReport, DocumentReference, Appointment and CarePlan, among others. The full API specifications are public and browsable without an account.

Epic is a member of both the Argonaut Project and the Da Vinci Project, and supports the International Patient Summary for cross-border exchange.

The open.epic sandbox

The sandbox is open. You do not need a customer relationship, a contract, or a sales conversation to start building. You register at open.epic.com, get a client ID, and test against synthetic patients.

Epic is explicit about this: it describes itself as vendor-neutral, says no special relationship is required to develop or deploy an app, and points developers at public documentation and self-service tooling to register apps, connect to customer systems and go live without Epic’s involvement.

Testing options:

• Try It runs no-code API calls directly from the specification pages.
• Sandbox test patients and endpoints let you query from Postman or any HTTP client.
• The SMART on FHIR testing feature simulates an app launch from inside Epic via OAuth2, which is the part most teams get wrong on first attempt.
• The Hyperdrive testing harness covers apps embedded in Epic’s web-based client.

Getting to production: The federated model

There is no central Epic endpoint. Epic runs a federated model. Every customer operates their own independent instance and decides for themselves which apps may connect. Epic supplies the software and the standard APIs. The customer controls who connects and to what.

Epic’s own path from registration to live has five steps:

1. Data sharing design. Start from the playbooks, which cover common product categories, or from the specifications if your use case is unusual.
2. Register a client record. Self-service for most use cases. You select the APIs your product needs and receive production and non-production client IDs. Only include APIs you will use, since each customer assesses the security and privacy implications of every scope you request.
3. Develop and test. Sandbox first, then mark the app ready for production use.
4. Customer implementation and going live. You license your product to a customer, they request your client ID be delivered to their environments, and you approve the keys for their implementation. Then the work starts: deployment, configuration to their workflows, non-production testing, troubleshooting.
5. Request a Showroom listing. Optional, and only available once you are live with at least one customer.

That fifth step is where a lot of published advice gets it backwards. A Connection Hub listing is a directory entry you become eligible for after you are already running somewhere, and Epic says directly that subsequent customers do not need it to connect with you.

Sandbox access takes an afternoon, and production access takes months.

How Epic’s FHIR differs from vanilla R4

A few differences that will cost you time if you discover them late.

Write access is deliberately narrow. Epic’s approach to writes is cautious and oriented around preserving record integrity. Deletion is generally restricted. Read paths are mature, write paths are not uniformly available, and you should confirm which resources support writes in your customer’s version before designing around it.

Epic extends the standard resources. There are Epic-specific extensions on resources like Patient, Encounter and Appointment. Ignore them and you may be dropping clinically meaningful data on the floor.

Search parameter behavior differs. Since the May 2024 version, certain search parameters are applied as post-filters. Epic retrieves everything matching the native parameters first, then filters the result set down. It changes the performance characteristics of queries you might expect to be cheap.

Read the implementation guide at fhir.epic.com before writing code.

Bulk FHIR and population-level export

Epic supports FHIR Bulk Data Access at version 1.0.1 of the spec for R4 resources, with some features pulled from 1.1.0. Only the Group Export operation is supported. There is no _since, and no other bulk operations.

Bulk data runs against the organization’s operational database. You are querying the live system, not a reporting copy, which is why Epic is cautious about it and why response times scale with population size. Requests are not incremental, so nothing returns until everything is ready.

The documented limits:

• One request per patient group, per client, per 24 hours by default. A customer can widen that window for you.
• Fourteen days to complete the search and download the files. After that the data is deleted.
• A maximum of 3,000 resource instances per file, with large result sets split across multiple files.
• Binary resources are excluded unless you request them explicitly with _type, and very large binaries cannot be retrieved through bulk at all.

Epic recommends polling for status every ten minutes for groups of a hundred patients or fewer, every thirty minutes above that, and using _type and _typeFilter on every request to keep response times and storage down. _typeFilter requires _type, and it cannot filter by patient, subject or _id.

Usefully, Epic names the use cases it considers a bad fit. Data warehouse synchronization, periodic loads of large clinical datasets, and incremental loads are all listed as poor use cases. A one-time historical load before switching to another exchange method, a monthly pull of a narrow resource set, or a weekly export of a dynamic cohort are the ones it endorses.

So if your plan is to keep a warehouse in sync with Epic via Bulk FHIR, Epic’s own documentation is telling you not to. Clarity, Caboodle, or Epic’s native EHI tables are the intended path for that, which is the same conclusion the architecture section reaches from the other direction.

Most of this is documented, but the parts that cost teams the most time are not: which version a customer is on, how the client ID actually reaches their environment, what breaks between sandbox and production. Our Epic Integration Course walks through the whole path with a working app.

Epic integration: How to connect external systems to Epic

There is no single right way to integrate with Epic. The path depends on what you are building, what data you need, and how deeply you need to sit inside the clinician’s workflow.

Some scale to set expectations: more than 45 billion messages move between Epic and non-Epic systems each month, across over 60,000 active interfaces with more than 2,000 vendors.

SMART on FHIR is the path for applications that open inside Epic with patient context already loaded. Authentication uses the SMART App Launch Framework over OAuth 2.0. There are two launch contexts: an EHR launch, where the app opens from within Epic and inherits patient and encounter context automatically, and a standalone launch, where the app runs on its own and initiates the authorization flow itself. Clinician-facing apps typically use the first, patient-facing apps the second.

CDS Hooks lets an external service inject decision support at defined points in the workflow. Rather than a clinician remembering to open your app, your service is called when they open a chart or place an order, and returns a card with a recommendation or action. For risk scoring, alerting or prior authorization tooling, this is what makes the thing usable.

FHIRcast synchronizes context across applications. A radiologist with Epic on one screen and your imaging viewer on another would otherwise have to re-select the patient in the viewer every time they move to the next case in Epic. With FHIRcast, the viewer follows.

Interconnect is Epic’s web services layer, and it is not an alternative to FHIR. It hosts the FHIR APIs. Epic’s endpoints look like /interconnect-fhir-oauth/api/FHIR/R4/, which tells you what is underneath. Beyond the standards-based APIs, Epic exposes additional web services and public APIs for workflows FHIR does not reach, plus private APIs available through Vendor Services.

HL7 v2 through Bridges still carries most of the real-time clinical traffic. Bridges is Epic’s interface engine, and every inbound and outbound v2 interface passes through it: ADT for demographics and encounter events, ORM and ORU for orders and results, SIU for scheduling, MDM for documents. Epic’s interfaces carry vendor-specific Z-segments and custom triggers, so what you implement is not generic HL7 v2.

A mature Epic integration usually runs several of these at once. FHIR handles patient-context queries and anything patient-facing. CDS Hooks and FHIRcast put you inside the clinician’s workflow. HL7 v2 through Bridges handles high-volume, event-driven messaging, and Interconnect web services and Clarity handle the operational and analytical data. Network-level exchange through Care Everywhere and TEFCA is a separate route again, covered below.

Epic EHR implementation: What to expect

This section is about what it costs a health system to run Epic. The integration cost question is at the end. Epic publishes no pricing, and almost every dollar figure you will find online, including some below, traces back to consultancy estimates.

What Epic implementations have cost

Large health systems disclose these figures in board approvals and public filings, and Becker’s tracks them. The most expensive Epic projects currently underway:

• Northwell Health, $1.2 billion, consolidating more than 30 legacy EHRs across 28 hospitals onto one Epic platform. Its first wave went live in November 2025 across eight hospitals and roughly 39,000 users, with further waves through 2026.
• Trinity Health, $800 million, a 92-hospital rollout that will make it the largest single-instance Epic user in the country.
• UAB Health System, about $380 million, covering EHR, revenue cycle and clinical research, phased over roughly two and a half years.

For scale on the other side of the market, the VA’s Oracle Health modernization now carries a lifecycle estimate of around $37 billion, up from a $16 billion contract.

These are enterprise numbers for multi-hospital consolidations. But they are real, attributable, and they tell you the shape of the thing: at the top end, an Epic program is a capital project on the scale of a new hospital building.

How Epic prices

Epic does not publish price lists or tiers, and every contract is negotiated with the individual organization. What is consistent is the structure.

There are two broad models. Under a licensed or on-premise arrangement, you pay a large upfront license fee and then recurring maintenance, typically modeled as a percentage of the initial license cost per year. Under a hosted or subscription arrangement, you pay per user per month, and Epic runs the infrastructure.

Beyond the software itself, the budget lines that consistently appear are implementation services, meaning workflow analysis, build, and clinical decision support configuration; data migration from legacy systems; infrastructure, which is substantial if you host on-premise; training; and internal staffing to run the thing afterwards.

Epic-experienced staff are expensive and in demand, and the organization needs them permanently, not just through go-live.

Third-party estimates put annual maintenance at 15 to 20% of initial investment and per-provider licensing in the low thousands to low tens of thousands per year, but treat these as directional. They come from consultancies and vendor blogs, not from Epic, and the ranges published across those sources vary by an order of magnitude for the same category of buyer.

Community Connect: How smaller hospitals get Epic

Most of the figures above are out of reach for a critical access hospital or an independent practice. Community Connect is the route those organizations take, and a growing share of Epic’s market expansion runs through hospitals that never signed a contract with Epic at all.

The model is straightforward: a larger health system, the host, extends its Epic license to a smaller affiliate, the recipient. The recipient does not build its own Epic instance. The host owns the license and runs the infrastructure, security, upgrades and governance, and the affiliate works inside that environment.

Epic accredits hosts rather than leaving the arrangement to the two parties. There are currently 91 accredited hosts, including Northwestern Medicine, Cleveland Clinic, Johns Hopkins Medicine and Providence. A smaller group hold Accredited+ status, among them Ochsner Health, Sanford Health, OSF HealthCare and Atrium Health, which lets them take on larger and more complex recipients.

It is cheaper, not cheap. Recipients pay the host, with cost scaling to size and scope. Veterans Memorial Hospital in Waukon, Iowa, a 25-bed critical access hospital, paid $3.88 million to implement through University of Iowa Health Care. That is one of the few Community Connect figures in the public record, and a good reference point, because it reframes what “affordable Epic access” means for a rural hospital.

The tradeoff is control. KLAS surveys of Community Connect recipients in 2023 found lower satisfaction with the ability to customize and modify the system compared with organizations holding direct Epic contracts. You are living inside someone else’s build, on their upgrade schedule, with their governance. For a hospital that could not otherwise run Epic at all, that is usually an acceptable trade, and Lee Carmen, CIO at University of Iowa Health Care, has made the practical case directly: the technical support needed to run Epic would overwhelm what a small rural hospital can staff on its own.

There is also a strategic dimension for the host. Community Connect gives large systems a repeatable way to onboard affiliates and acquisitions onto a shared record, which is one reason the model keeps growing.

Implementation timeline

Timelines scale with organizational complexity rather than headcount alone. Commonly cited planning ranges are 12 to 18 months for a mid-size practice, 18 to 24 months for a large hospital, and 24 to 36 months for an enterprise multi-facility system. UAB’s roughly two and a half year phased program sits squarely in that last band, which is a useful reality check on the estimates.

A phased rollout is the norm, and for good reason. Taking every module live simultaneously across a whole system concentrates operational risk into a single weekend. Phasing lets staff adapt incrementally and gives the implementation team room to stabilize before expanding. Northwell’s region-by-region wave structure is the pattern most large systems follow.

Training and go-live support

Training is mandatory and role-specific. Physicians, nurses, pharmacists, billers, lab techs and registration staff each have their own curriculum, and nobody touches production without completing theirs.

Alongside formal training, Epic expects health systems to develop Super Users: clinical staff who train more deeply and then provide at-the-elbow support to their colleagues during go-live. This is not optional in practice. Go-live typically runs a surge model with extra IT staff on the floors, extended help desk hours, and Super Users assigned per unit, tapering over two to four weeks.

Budget for a productivity drop. Clinicians are slower in a new system for months, and any business case that assumes otherwise is wrong.

Where implementations go wrong

Replicating legacy workflows instead of adopting Epic’s. This is the most common and most expensive mistake. Epic’s foundation build exists because thousands of organizations have already argued about these workflows. Rebuilding your old EHR’s behavior inside Epic inflates the timeline, increases upgrade risk forever, and usually produces a worse result than the standard model.

Underestimating data migration. Legacy data quality problems do not stay in the legacy system. Mapping old structures onto Epic’s model is difficult, and the discovery work is almost always larger than the initial estimate.

Weak governance. Large implementations need someone empowered to make decisions that some clinicians will dislike. Without clear authority spanning both clinical and IT leadership, decisions stall, scope drifts, and the timeline slips quietly.

Change management as an afterthought. Staff who have used another system for a decade will resist, and the organizations that handle this well treat it as a communications and clinical leadership problem rather than an IT one.

A different question: What does it cost to integrate with Epic?

Everything above is what it costs a hospital to run Epic. If you are a software company rather than a health system, your question is the opposite one, and the answer is far cheaper than most people assume.

As noted earlier, standard FHIR access is free. The private APIs are metered per call, and Caboodle queries are priced per query with a floor per customer per quarter. Other fees that do exist are modest: around $1,900 a year for the vendor program and $500 per app for review and listing.

The real cost of integration is time. Getting live at a single hospital means contracts, a BAA, and a technical coordinator on their schedule, repeated hospital by hospital.

We’ve written up the full breakdown by connection pattern, including where each one gets expensive, in Epic integration cost and timeline.

Epic vs Cerner: The enterprise EHR comparison

Cerner is now Oracle Health. Oracle acquired Cerner in a deal worth around $28 billion, completed in June 2022, and rebranded it. The Cerner name persists in search, in job titles, and in Oracle’s own documentation, so this section uses both.

Market position

In terms of market share, Oracle Health sits second at 21.9% and 20.4%.

Oracle Health lost 56 hospitals and 14,676 beds in 2025, its third consecutive year with the largest net market share loss of any tracked vendor, and all but three of those losses went to Epic. In the 2026 Best in KLAS rankings, Millennium scored lowest among acute care EHRs across large, midsize and small organizations. Around 30% of sampled Oracle Health customers told KLAS the platform is not part of their long-term plans, with a further 35% considered vulnerable.

Oracle’s rebuild, and why 2026 is the test

Rather than iterating on Millennium, Oracle built a new EHR from scratch on Oracle Cloud Infrastructure. It launched for ambulatory providers in August 2025, voice-first, with AI embedded rather than bolted on, and is now certified for US ambulatory customers. Acute care functionality was slated for 2026.

KLAS framed 2026 as the year that determines whether Oracle Health stabilizes its installed base. Ambulatory customers have had months with the new system. Hospitals, where Oracle’s position is weakest and where the defections have concentrated, have not.

If you are evaluating Oracle Health today, that is the central question: you are choosing between a mature platform customers are leaving and a new platform without a hospital track record yet.

The VA contract

The VA signed a $10 billion contract with Cerner in 2018 to modernize the EHR across 170 medical centers. The contract was revised upward to more than $16 billion, and lifecycle estimates given to lawmakers have run as high as about $37 billion.

Deployments were paused for nearly three years over patient safety, technical and usability problems. The VA restarted in April 2026 with four simultaneous go-lives in Michigan, planning around 13 facilities that year and full rollout to all 164 medical centers as soon as 2031.

The VA is the hardest EHR deployment in the world, and Epic has not attempted anything of that scale and complexity. But it is the largest public dataset available on Oracle’s ability to execute, and it has not gone well.

FHIR and developer experience compared

	Epic	Oracle Health (Cerner)
FHIR version	R4 primary	R4 only, DSTU2 retired
API branding	Epic on FHIR	Ignite APIs
Developer portal	open.epic.com	code Console
SMART on FHIR	Supported	Supported, App Launch STU1
Bulk FHIR	Group Export, per-customer limits	Supported where enabled
App directory	Showroom / Connection Hub	Oracle Health Marketplace
Sandbox	Free, self-service	Free, self-service
Production activation	Per-customer client ID sync	Per-customer Ignite APIs service request

Oracle no longer supports DSTU2 FHIR APIs, having ended support in December 2025. If you have a legacy Cerner integration still on DSTU2, it is unsupported and needs migrating to R4.

For developers, the structural similarity is more striking than the differences. Both vendors run a federated model where registration makes you available and the individual customer decides whether to switch you on. Epic calls it syncing a client ID, Oracle calls it an Ignite APIs service request. Either way, the gate is the hospital.

Oracle Health is on SMART App Launch STU1, so scope syntax that assumes a newer version of the framework will not behave as expected.

Interoperability

Epic’s advantage here is structural and hard to close. Oracle Health’s reach is smaller, participating through CommonWell, which Cerner co-founded, and through Carequality connections, and is now a CMS Aligned Network. The interoperability section below covers the frameworks in detail.

Cost

The comparison figures circulating online are estimates. What can be said with confidence is that Epic’s implementations at large systems have run into the hundreds of millions, as the implementation section above documents with named examples, and that Oracle has historically competed on lower upfront cost.

That doesn’t mean lower total cost. The figure that should worry a buyer is the cost of being wrong, since replacing an enterprise EHR is a decade-scale, nine-figure decision that organizations do not get to make often.

Which is right for your organization

For large integrated systems planning over a ten-year horizon, Epic has the stronger track record, the larger exchange network, and a customer base that is not leaving.

Oracle Health remains viable, particularly for mid-size and community hospitals where cost and timeline dominate, for organizations already committed to Oracle infrastructure, and in federal and government settings where Cerner has deep roots. The caveat is that you are betting on the new platform landing well, and that evidence is still being gathered.

Epic interoperability: Care Everywhere, Carequality, and TEFCA

Interoperability is where Epic has invested most consistently over the past decade, and it is the hardest part of its position for a competitor to replicate. The frameworks stack in a way that confuses people, so here is how they fit together.

Care Everywhere

Care Everywhere is Epic’s own exchange network, launched in 2008 to connect Epic sites to each other. It has since grown well past that.

At Epic’s 2026 Users Group Meeting the company reported 9 billion records exchanged, many of them with non-Epic systems, though Epic did not break out a specific non-Epic figure. Historically Epic has said roughly half of Care Everywhere exchange happens with non-Epic organizations.

Epic customers closed 316 million care gaps in a year using interoperable data, meaning duplicate work avoided and outreach focused on patients who needed it.

For a patient, Care Everywhere is why a chart from a hospital in another state appears in the record during an ED visit, without anyone requesting a fax.

Carequality and CommonWell

Carequality is a national framework that supplies the legal agreements and technical rules for exchange between organizations. Epic participates through Care Everywhere, which is how an Epic hospital queries non-Epic organizations.

CommonWell is a separate alliance, co-founded by Cerner, that Epic initially declined to join. The two networks were bridged through Carequality, which is why Epic and Cerner hospitals can exchange despite that history. CommonWell is now itself a designated QHIN under TEFCA.

Carequality and CommonWell are the previous generation of national exchange, and TEFCA is the federal framework now sitting above both.

TEFCA and Epic Nexus

TEFCA is the government-sponsored framework for nationwide exchange, administered by The Sequoia Project. Rather than every organization negotiating bilateral agreements, participants join a Qualified Health Information Network, and QHINs connect to each other. Join any QHIN and you can exchange with anyone connected to any other.

Epic Nexus is Epic’s own QHIN, designated at TEFCA’s launch in December 2023. It is only open to Epic community members, but there are several other QHINs, including eHealth Exchange, Health Gorilla, MedAllies, KONZA and CommonWell.

Adoption has moved quickly. Epic said in mid-2025 that more than 1,000 hospitals and 22,000 clinics were live through Epic Nexus. By its 2026 UGM that had grown to more than 2,000 hospitals and 58,000 clinics, roughly doubling in a year. Across all QHINs, The Sequoia Project reports more than 100,000 healthcare sites exchanging data and over 1.5 billion documents shared since launch.

If you are building something that needs to reach Epic organizations at national scale, this is the on-ramp. Onboard to a QHIN, and Epic sites become reachable without negotiating with each one individually. That is a materially different proposition from the app enablement path described earlier, and the two are easy to confuse.

Share Everywhere

Share Everywhere is the patient-controlled option inside MyChart. A patient generates a temporary access code that lets any provider with a web browser view a summary of their Epic record, without that provider being on any network at all.

It is narrow by design, read-only and time-limited, but it covers the case the big frameworks miss: the specialist, urgent care clinic or overseas provider who participates in nothing.

Ongoing litigation over data access

Epic’s control over record access is being challenged in court. As of September 2026 it is defending three antitrust cases: one from Particle Health, a health data startup, one from CureIS Healthcare, and one from the state of Texas. The common thread is the allegation that Epic uses its position in electronic health records to control who can reach patient data and on what terms. Epic denies all three and points to its exchange volume, over 725 million record exchanges a month with more than half going to non-Epic systems, as evidence of openness.

None of it has changed how integration works. No court has ordered Epic to alter its access model, and none of these cases is near a ruling on the merits. Good to know, but not worth planning around.

What this means if you are building

Three routes reach Epic data, and picking the wrong one costs months.

If you need patient-context data inside a clinical workflow, use the FHIR APIs and go through per-customer enablement.

If you need document-level exchange at national scale as a healthcare organization, join a QHIN.

If you are patient-facing, the Cures Act access rules already apply at every Epic site, so patient-authorized apps avoid the per-hospital negotiation entirely. This is the route most teams underestimate.

What developers and health IT teams get wrong about Epic

Most Epic projects that go badly do so for a small number of repeated reasons. These are the ones to internalize before you start.

Assuming every Epic is the same version

Epic ships versions on a rolling schedule, and customers upgrade on their own timeline. Capabilities you tested against are gated to specific releases: _typeFilter on bulk export arrived in the November 2023 version, Provenance entered the default bulk resource set in November 2021, and post-filtered search parameter behavior changed in May 2024.

So an app that works at one customer can fail at another, not because of configuration, but because the second site is two releases behind. Ask what version a customer is on before you scope the work, and design for the oldest version you intend to support rather than the one in your sandbox.

Treating sandbox success as production readiness

Sandbox patients are synthetic and tidy. Production data is not.

Real Epic data brings null fields where your parser expects values, local codes alongside standard ones, duplicate and merged patient records, historical data migrated from a previous EHR with its own quirks, and clinical documentation that reflects how one health system happens to work. An application that handles the sandbox flawlessly commonly falls over in the first week of a pilot.

Budget engineering time after your first customer connection, not just before it.

Building the integration before selling anything

This is an expensive business mistake.

Sandbox access takes an afternoon, and the path to production runs through a hospital deciding to buy your product, signing a BAA, and assigning a technical coordinator who already has a backlog. That is a months-long commercial process, and no amount of engineering shortens it.

Teams routinely spend a year building a polished Epic integration and then discover they have no customer to switch it on. The order that works is the opposite one: find the health system first, and let their timeline drive the build.

Getting patient identity wrong

Epic exposes several identifier types, and they are not interchangeable. Using the wrong one is a class of bug that passes every test in the sandbox and then produces subtly wrong results in production, which is the worst possible failure mode in a clinical system.

Related: patient matching across organizations is hard, and Epic’s exchange networks handle it for you. If you are building matching logic yourself, check first whether you really need to.

Assuming FHIR is the whole story

FHIR gets the attention, and for patient-context reads it is the right tool. HL7 v2 through Bridges still handles the high-volume, event-driven clinical messaging at every Epic site, and a great deal of operational data lives in Clarity rather than behind any API.

If your requirement is a real-time feed of admissions, or years of history across a population, FHIR is probably the wrong instrument. Match the pathway to the shape of the data.

Key takeaways

• Epic holds 43.7% of US acute care hospitals and 56.9% of beds, and has won every enterprise-wide decision by a health system of more than ten hospitals in the most recent full year of data.
• More than 325 million patients have a current record in Epic.
• Epic’s production database is Chronicles, a MUMPS hierarchical store running on InterSystems IRIS since 2020, not a relational database. Clarity is a nightly relational copy, and Caboodle is the warehouse downstream of it. This is why integration goes through APIs rather than SQL.
• Epic publishes over 700 FHIR APIs free of charge and runs a self-service sandbox at open.epic.com. Building against Epic costs almost nothing.
• There is no central Epic endpoint. Every customer runs an independent instance and decides which apps connect, so production access depends on a health system, not on Epic.
• A Connection Hub listing comes after you are live with a customer, not before. It is optional, and later customers do not need it to connect with you.
• Epic customers upgrade on their own schedules, so API behavior varies by version. Design for the oldest release you intend to support.
• Bulk FHIR runs against the live operational database. Epic supports Group Export only, limits requests to one per group per client per day by default, and explicitly names data warehouse synchronization as a poor use case.
• Named Epic implementations currently underway include Northwell Health at $1.2 billion, Trinity Health at $800 million and UAB at about $380 million. Epic publishes no pricing, and most figures circulating online are consultancy estimates rather than disclosures.
• More than 2,000 Epic hospitals and 58,000 clinics exchange data through TEFCA via Epic Nexus, roughly double the previous year.
• Patient-facing apps skip per-hospital enablement, because Cures Act patient access rules already apply at every Epic site.

Conclusion

Epic is complex, and the complexity is mostly deliberate. A single shared record across every department is what makes the clinical experience coherent, and it is also what makes the system hard to change, expensive to implement, and awkward to extend.

For developers, the practical picture is better than its reputation suggests. The APIs are free, well documented and standards-based, and the sandbox is open to anyone. The hard part is not technical. It is that every hospital decides independently whether to switch you on, which makes Epic integration a commercial problem.

For health systems, the pattern across successful implementations is consistent: adopt the foundation build unless you have a reason not to, resource the work permanently rather than through go-live, and give someone the authority to make decisions that clinicians will not all like.

The organizations that get the most out of Epic treat it as a system to understand instead of trying to work around it.

If you are building on Epic, our Epic Integration Course takes you from app registration through to a live production connection.

Frequently asked questions

What is Epic EHR used for?

Epic is used by hospitals, health systems and clinics to manage the whole patient journey in one system: clinical documentation, order entry, nursing flowsheets, medication administration, lab results, scheduling, billing and population health analytics. Clinicians work in Hyperspace, Epic's clinical interface, and patients access their records through MyChart. Epic Systems Corporation, founded in 1979 and privately held, is the largest EHR vendor in the US by market share.

How much does Epic EHR cost?

Epic publishes no pricing, and every contract is negotiated with the individual organization. Publicly disclosed figures from large systems give the clearest picture: Northwell Health has budgeted $1.2 billion, Trinity Health $800 million, and UAB Health System about $380 million. Smaller organizations typically access Epic through Community Connect under a larger system's license, where a 25-bed critical access hospital paid $3.88 million to implement. Cost ranges published elsewhere online are consultancy estimates rather than disclosures.

Does Epic use FHIR?

Yes. Epic supports FHIR R4 and publishes over 700 FHIR APIs free of charge, with full specifications at fhir.epic.com. Epic is a member of both the Argonaut Project and the Da Vinci Project, and supports SMART on FHIR, CDS Hooks, FHIRcast and Bulk Data Access.

How do I integrate with Epic EHR?

Register a developer account at open.epic.com, build and test against the free sandbox, then work with an individual Epic customer to enable your app in their environment. FHIR with SMART on FHIR is the modern path for patient-context applications, while HL7 v2 through Bridges still carries most high-volume clinical messaging. There is no central Epic endpoint, so production access depends on a health system switching you on rather than on Epic itself.

What is Epic App Orchard?

App Orchard is retired. It launched in 2016, was rebranded to App Market in 2021, closed in 2022, and was replaced by Showroom, which contains Connection Hub as its product directory. A Connection Hub listing requires at least one live connection with an Epic customer, so it comes after you are integrated rather than before. Listing is optional, and subsequent customers do not need it to connect with you.

What is the difference between Epic and Cerner?

Cerner is now Oracle Health, following Oracle's acquisition completed in June 2022. Epic holds 43.7% of US acute care hospitals and 56.9% of beds, against 21.9% and 20.4% for Oracle Health. Epic leads on interoperability reach through Care Everywhere and on patient engagement through MyChart, and has won every enterprise-wide decision by a system of more than ten hospitals in the most recent full year of data. Oracle Health has lost the most market share of any vendor for three consecutive years and has rebuilt its EHR from scratch on Oracle Cloud Infrastructure, with acute care functionality following its 2025 ambulatory launch.

Is Epic EHR cloud-based?

Partly. Epic runs on-premise, in Epic's own managed hosting, or on public cloud, and both AWS and Azure support full production Epic environments. The core clinical system is not a cloud-native containerized application. Epic's cloud-native work is concentrated in analytics, where Cogito Cloud is built on Azure. Cloud hosting currently costs the same or more than on-premise, so the case for it rests on reliability and avoided hardware refresh rather than a lower bill.

What is SMART on FHIR in the context of Epic?

SMART on FHIR is the standard that lets third-party applications launch inside Epic and access patient data securely. Authentication uses the SMART App Launch Framework over OAuth 2.0. There are two launch contexts: an EHR launch, where the app opens from within Epic and inherits patient and encounter context automatically, and a standalone launch, where the app runs on its own and initiates the authorization flow itself. To a clinician, a SMART app running in Epic looks like part of the workflow even though it lives outside Epic's codebase.

What is the Epic sandbox and how do I access it?

The Epic sandbox is a free developer environment at open.epic.com with synthetic patient data and access to Epic's FHIR APIs. No customer relationship or contract with Epic is required. You register an account, create an app record, and receive production and non-production client IDs. Testing tools include no-code Try It calls from the specification pages, sandbox endpoints you can query from Postman, SMART on FHIR launch simulation, and a Hyperdrive testing harness for embedded apps.

Does Epic run on a SQL database?

No. Epic's production database is Chronicles, a hierarchical MUMPS key-value store running on InterSystems IRIS, which Epic adopted with its August 2020 release, replacing InterSystems Cache. There are no SQL tables in Chronicles. Clarity is a relational copy in SQL Server, refreshed by a nightly ETL, and Caboodle is the enterprise data warehouse downstream of it. This is why external systems integrate through APIs rather than direct database queries.

How do small hospitals get Epic?

Through Community Connect, where a larger health system acting as host extends its Epic license to a smaller affiliate. The host owns the license and runs the infrastructure, security, upgrades and governance. Epic accredits hosts, and there are currently 91 accredited hosts including Cleveland Clinic, Johns Hopkins Medicine, Northwestern Medicine and Providence. It is cheaper than a direct contract but not cheap: a 25-bed critical access hospital in Iowa paid $3.88 million to implement. The tradeoff is customization, and KLAS has found recipients report lower satisfaction with their ability to modify the system than organizations with direct Epic contracts.

Can I access Epic patient data without a contract with each hospital?

For patient-facing applications, yes. Cures Act patient access rules already apply at every Epic site, so a patient-authorized app avoids per-hospital enablement. Epic also supports automatic client record distribution for patient-authorized apps. Clinician-facing applications are different, and require each customer to enable your client ID in their environment. Organizations needing document-level exchange at national scale can instead onboard to a QHIN under TEFCA.

What is Epic Nexus?

Epic Nexus is Epic's Qualified Health Information Network under TEFCA, designated at the framework's launch in December 2023. Epic customers connect to nationwide exchange through it. More than 2,000 Epic hospitals and 58,000 clinics now exchange data through Epic Nexus, roughly double the previous year. Epic Nexus is only open to Epic community members, but connecting to any other QHIN, such as eHealth Exchange, Health Gorilla, MedAllies, KONZA or CommonWell, allows exchange with organizations on any QHIN.

How long does an Epic implementation take?

Timelines scale with organizational complexity. Commonly cited ranges are 12 to 18 months for a mid-size practice, 18 to 24 months for a large hospital, and 24 to 36 months for an enterprise multi-facility system. UAB's phased program runs roughly two and a half years, which is consistent with that last band. Phased rollouts are the norm, since taking every module live at once across a whole system concentrates operational risk into a single weekend.

Does Epic support Bulk FHIR?

Yes, at version 1.0.1 of the FHIR Bulk Data Access specification for R4 resources, with some features from 1.1.0. Only the Group Export operation is supported, and there is no _since parameter. Bulk data runs against the live operational database, so requests are limited to one per patient group per client per 24 hours by default, files are retained for fourteen days, and each file holds a maximum of 3,000 resource instances. Epic names data warehouse synchronization, periodic loads of large clinical datasets, and incremental loads as poor use cases for bulk export.

Related articles

View all

May 22, 2026

EHR Systems Explained: What They Are, How They Work, and How to Choose the Right One

Learn how EHR systems work, compare EHR vs EMR, explore FHIR interoperability, implementation costs, architecture, and key features in this complete guide.

April 17, 2026

How to Get a Patient's Health Record in 2026

You'd think I'd tell you about APIs or tools. The key is in understanding legal coverage.

January 2, 2026

IHE XDS Explained: Registry, Repository & ITI Transactions

Understand IHE XDS federated architecture: Registry, Repository, ITI-41/42/43 transactions & SOAP. Run a working XDS exchange locally with the NIST toolkit.