What Epic integration really costs and how long it takes in 2026. The fees that matter, why time is the real cost, and a breakdown for each connection pattern.

By now you’ve seen the different ways to connect to Epic. The next question to answer is what it costs and how long it takes. There’s no single answer, because the bill depends almost entirely on which pattern you’re using.

First, the myth

Most people assume Epic charges a fortune just to let you connect. But the most common way in is free, and that’s through FHIR APIs. These FHIR APIs are what every patient-facing app and most clinical ones use. Epic publishes over 700 of them at no charge, and they’re called billions of times a year.

So where does Epic charge you? There’s a yearly membership fee for Epic’s vendor program, which is around $1,900, and a $500 per-app fee to get an app reviewed and distributed. After that, you start paying usage fees when you want to use Epic’s private APIs, data warehouse, or connection engine. These are metered, you pay per call, per query or per connection. Which of them you use comes back to the pattern you pick.

Keep one thing in mind though. Even when those fees add up, they’re usually small next to the real cost, which is time. The months it takes to get live at each hospital, one at a time. That’s what usually hurts companies.

Let’s take the patterns one by one, cheapest first, which means the patient pattern.

Patient apps: nearly free, and nobody to wait on

A patient app runs on Epic’s standard FHIR APIs, and those sit under open.epic at no charge. You don’t need the paid membership to build one, there’s no per-call meter, and nothing is billing you in the background. The only fee that might apply is the $500 a year to list your app in Epic’s directory so hospitals can find it, and even that’s optional.

The timeline is where the patient pattern pulls ahead, and the reason goes back to the Cures Act. You’re not waiting on each hospital to set you up. The patient logs in and authorizes your app themselves, and since US law requires Epic to support patient access, that path already exists at every Epic site. So you build once against the free sandbox, pass Epic’s verification, and reach patients across many hospitals without negotiating with each one. That’s how there are already around 800 patient-facing apps live and pulling data this way.

With a patient app, the hard part is building something people actually want to use. Epic itself is the easy bit. Your time and money go into the product, not into fees or approvals.

Provider and backend: the API is cheap, the hospital is slow

Next is the provider side, which covers both the clinician patterns and the backend ones. They behave almost the same on cost and timeline. What drives both is the same thing: getting a hospital to switch you on. The API is the cheap part.

If you’re using standard FHIR, the calls are free, same as the patient side. What you’ll usually add here is the vendor membership at $1,900 a year, and the $500 per app if it gets listed and reviewed. So far, not much. The cost that matters is hiding somewhere else.

Getting an app live at a hospital is roughly a six-step path. A few steps are quick and you do them yourself on Epic’s developer site: you create the app, and later you flip it to production. The last step is wiring it up on your own platform. Those are the easy ones.

Then the slow part. Before a hospital can run your app, there are contracts and approvals that don’t happen in a web form. You sign a vendor services agreement with Epic. The hospital signs their own API agreement, and you sign a Business Associate Agreement (BAA) with them so the patient data is allowed to flow. Then someone on the hospital’s side, their Epic technical coordinator, loads your app onto their specific Epic system and hands back the credentials it needs. All of that happens over email, phone calls, and meetings, on the hospital’s schedule, not yours.

That’s the real price of this pattern, and it’s measured in time. Weeks at best, often months, before a single hospital is live. And because every hospital runs its own Epic, you repeat most of it for the next one.

Two things can push the money up from here. If standard FHIR doesn’t have what you need and you call Epic’s private APIs instead, those are metered per call, from a fraction of a cent up to a bit over a dollar each, depending on the type. And the build itself isn’t free in engineering terms. A serious provider-facing integration, the real cost of building a custom SMART on FHIR app for Epic, is commonly $25,000 to $100,000 of effort once you count building it, testing it, and getting it through each hospital’s review.

The data warehouse: Clarity, Caboodle, and the Kit Model

This pattern works differently from the ones discussed so far, because it’s about the two reporting databases we discussed in the last lesson, Clarity and Caboodle. How you get in and how you pay change here.

You don’t reach this data through a public API. It sits on the hospital’s side, and you get access to it by working with their data team, who either run extracts for you or give you access inside their own environment. So the timeline here isn’t dependent on Epic. It comes down to how fast a given hospital’s analysts can set things up and hand over what you need, and that swings a lot from one hospital to the next.

Cost splits between the two databases. Clarity is the hospital’s own database, so getting data out of it is usually just an arrangement you make with them, with no separate Epic meter running. Caboodle is where Epic’s pricing comes in, through what it calls the Kit Model. Instead of paying per API call, you pay per query against the warehouse tables.

These tables come in two kinds. Dimension tables hold the context, things like patients, departments, and dates, and they’re small. Fact tables hold the actual events you’re counting, like every encounter or charge, and those are huge. So a query against a fact table costs about double, because that’s where the volume is. Across the classes, it ranges from free at the low end to about $4 for a single query against a high-class fact table. There’s also a floor: a minimum of $500 per app, per customer, per quarter, so even light use carries a baseline cost at each hospital.

Our advice: unless you truly need near-live reporting, it’s usually cheaper to pull a periodic extract into your own warehouse and run analytics there than to pay Epic per query on Caboodle. If you don’t need a 24-hour refresh, don’t ask for one. Extract on the schedule you’ll actually use.

So with the warehouse, your bill rides on how heavily you query and how many hospitals you pull from, while your timeline rides on each hospital’s data team far more than on Epic.

The network: pay to get in, then reach everyone

The network pattern lets you connect to a national network once and reach every hospital on it, rather than integrating with each one separately. And you rarely connect to each network on its own. Most people go through a single QHIN. A QHIN, a Qualified Health Information Network, is one of a handful of organizations the government has approved to carry data between all the different networks under TEFCA. Think of it as a hub the other networks plug into. There are 11 of them today, and each one is an on-ramp to everything connected to TEFCA.

So you connect to one QHIN, or to an intermediary that’s already wired into all of them, and you’re reaching the whole ecosystem. Connect to a broker like Health Gorilla, for example, and through its API you reach Carequality, CommonWell, eHealth Exchange, and TEFCA at once. Epic runs its own QHIN in this world too, called Epic Nexus.

The cost works differently here. There’s usually a one-time fee to get certified and onboarded, plus an annual membership. To put a real number on it, CommonWell charges a one-time onboarding fee of $10,000, then an annual fee scaled to your size, with nothing charged per record you pull. Other networks and brokers price it their own way, but the shape is the same: you pay to get in and to stay in. There’s no per-record charge.

This pattern gives you much better reach than the others. TEFCA alone now connects more than 71,000 sites through those 11 QHINs. So a single onboarding puts you in front of records across tens of thousands of organizations, instead of negotiating with each hospital one at a time.

One honest caveat. What comes back over the network today is mostly C-CDA documents, it isn’t real-time, and the data quality is lower than what you’d pull straight from the EHR’s FHIR APIs. You’ll also spend effort de-duplicating records that arrive from several sources. You’re buying reach here, not fidelity.

The timeline trade is the same story. You still have to qualify, a certification and onboarding process that runs weeks to months. But you do it once, not once per hospital. So if your app needs records from lots of places it’ll never integrate with directly, this is usually the cheaper and faster path in the end, even though the upfront fee looks bigger.

That’s the full picture of integrating with Epic: what it is, how it’s built, the ways to connect, and what each pattern costs. When it comes to Epic integration costs, the pattern you pick decides everything.

From here, the course goes deep on each pattern, one at a time. We start with the patient layer, where you’ll actually build and ship a working patient app against Epic. See you in the next module.