Epic FHIR Integration Cost: Fees, Hours and Per-Site Budgets

The short answer on Epic FHIR integration cost: Epic charges you, the app developer, nothing to register, use the sandbox or have customers download your app, and its only published developer fee is an optional $500 per product per year listing. The real money is engineering and implementation. Plan on 240 to 480 hours for a read-only patient-facing app, 600 to 1,200 hours for a clinician-facing SMART on FHIR app, and 740 to 1,480 hours for a backend integration, which is roughly $24,000 to $148,000 at $100 an hour. Then budget for go-live work at every health system and for upkeep.

Most estimates online give a single wide range, from $15,000 to over $1 million, without saying who pays what. This guide separates the two bills in every Epic project: the one you pay and the one your customer pays Epic. Every fee statement below was checked against Epic's own developer documentation and federal rules in November 2026. You also get hour-by-hour build models for the three common integration patterns, a per-site go-live budget, a three-year example and a 12-question checklist to use before you sign a statement of work.

Key takeaway: For most vendors the most expensive line in an Epic integration is not Epic and not the first build. It is the repeated work at each customer site and the API scope decisions you cannot undo after launch.

Who pays what in an Epic FHIR integration?

Epic bills the healthcare organization for API use, not the app developer. Epic's App Creation & Request Process Overview states that its industry-standard and Public APIs "are licensed directly to healthcare organizations (not to app developers)" and that "fees are based on production usage, not on your client ID scope." The Epic on FHIR site describes itself as "a free resource for developers," and Epic's open.epic site says USCDI v3 support is available to developers for free "alongside over 750 no-cost APIs and interfaces."

Two consequences follow. First, a vendor quote that includes a large "Epic license fee" for a standard FHIR integration deserves a question: which fee, paid to whom? Second, even though Epic does not bill you, your customer's Epic costs still affect your sales cycle. Epic's own example: some Medication FHIR APIs are in the USCDI group "which most healthcare organizations already license," but adding Medication APIs outside USCDI may require your customer to license more, "increasing their costs."

The Showroom listing page is explicit that a listing "is not required for you to connect your software to organizations using Epic." It is available only to products already in production with at least one Epic customer, and by requesting it you agree to "the annual, non-refundable Connection Hub listing fee of $500 per product per year."

What federal rules say about Epic's API fees

Federal certification rules limit what an EHR developer may charge for its certified APIs, and they explain why the developer side is free. Under 45 CFR 170.404, a "Certified API Developer" such as Epic must publish all terms and fees for its certified API technology in plain language, and any fee not expressly permitted is prohibited.

The permitted fees are narrow:

• To the healthcare organization (the "API Information Source"): fees to recover the reasonable costs to develop, deploy and upgrade certified API technology, and fees limited to the incremental cost of hosting it on the organization's behalf.
• To you (the "API User"): only fees for value-added services that are "not necessary to efficiently and effectively develop and deploy production-ready software."

The same section bars conditioning your right to build and market products on a license fee, royalty or revenue share, on exclusivity, or on "Certified API Developer-specific testing or certification requirements." It also sets clocks: for apps that use APIs certified to 170.315(g)(10), (g)(31) or (g)(33), authenticity verification must finish within 10 business days of your request, and the app must be registered for production within 5 business days after that.

These protections cover certified API technology, which is centered on patient and population data access. Epic also offers many other APIs, interfaces and workflows outside that scope, and the healthcare organization's licensing for those is a commercial matter between it and Epic. That is why the right budget question is always "which APIs, exactly?" Confirm how the rules apply to your product with your counsel.

Epic FHIR integration cost by integration pattern

Epic FHIR integration cost depends mostly on which of three patterns you are building, because each one changes how Epic distributes your app and how much work happens at each customer. The hours below are Fleurant AI planning estimates for a senior-led team building one integration with a modern web stack. Use them to sanity-check quotes, not as a price.

What rate should you use?

Hours are the stable unit; rates vary. The median annual wage for software developers was $135,980 in May 2025, according to the BLS Occupational Outlook Handbook. Wages and salaries were 70.0 percent of private-industry employer compensation costs in June 2026 (BLS Employer Costs for Employee Compensation), so that median developer costs an employer about $194,000 a year. Over roughly 1,414 productive hours a year, that is about $137 per productive hour. We use $100 as a midpoint for a US agency or in-house team, the same method used in our SaaS MVP cost guide, and show $137 where a senior-only healthcare team is likely.

Pattern 1: patient-facing, read-only app

A patient-facing app that only reads USCDI data is the cheapest Epic integration, because Epic distributes it for you. Epic's patient-facing apps guide says client IDs download automatically to an organization's Epic instances when the app uses only USCDI v3 FHIR APIs (USCDI v1 on Epic May 2024 and earlier), only reads data, is patient-facing, selects "Enable Auto-download," and is marked Ready for Production. The organization must be marked to use USCDI APIs in its licensing agreement and must not have disabled auto-download.

The catch is scope. The moment you need a non-USCDI API, write access or a clinician workflow, you lose automatic distribution and move into one of the next two patterns.

Pattern 2: clinician-facing SMART on FHIR app

A clinician-facing app launched inside Epic costs more because it must fit clinical workflows and pass each customer's review. It typically uses the EHR launch flow from the HL7 SMART App Launch Implementation Guide (version 2.2.0 is the current published version), where the app inherits the clinician's session and the selected patient.

The user interface line is larger than teams expect. Epic's App Developer Guidelines ask apps to keep the patient's identity visible, to use TALLman lettering for commonly confused drug names when assisting clinicians, to show when data was last updated, and to "manage errors gracefully." These are guidelines, not certification gates, but health system reviewers read them.

Pattern 3: backend system integration

A backend integration with no user interface often costs the most, because it moves the most data and touches the most Epic configuration. Typical examples are nightly or incremental syncs using FHIR Bulk Data, HL7v2 interfaces for orders, results or device readings, and write-back into the chart. Backend apps authenticate as a system rather than a user, and Epic requires a JWK Set URL (JKU) for backend OAuth 2.0 apps on the timelines in its OAuth 2.0 tutorial.

Throttling is not optional. Epic's guidelines ask that an app consume no more than 1 percent of the Epic operational database's resources during peak hours and no more than 5 percent off-peak, with peak "typically 7:00 am to 7:00 pm local time." A sync that works in the sandbox can fail a customer's performance review at scale.

Key takeaway: Choose the pattern before you choose a vendor. A quote for "Epic integration" without a named pattern, API list and per-site plan cannot be compared with another quote.

What does each customer go-live cost?

Every clinician-facing or backend customer is a small implementation project, and you pay for your side of each one. Epic's Implementing Apps at Epic Customers guide lists the tasks: project prioritization and contracting, a kickoff call, the app request process, user and security setup, interface setup, Interconnect (web services) setup, allowing content through the firewall, application build, end-to-end testing, training and cutover to production. Several of those are owned by the health system, but your team attends, answers and tests.

The data dictionary line surprises first-time vendors. Epic notes that "each organization owns the data in its system and configures it differently," so one customer may code a diagnosis differently from another, and you will need a code list from each one.

Calendar time per site is set by the customer. Epic suggests asking at kickoff about "upcoming timelines for Epic upgrades" and "build freezes in different environments," and recommends customers evaluate costs up front, including "new interfaces, and additional license or subscription volume that may be triggered by the application." In our planning we assume a clinician-facing or backend go-live takes a few months per health system, and we schedule around the customer's upgrade calendar rather than our sprint plan.

Hidden costs that blow up Epic integration budgets

The costs that hurt most are the ones that are cheap to avoid early and expensive to fix later. These six come straight from Epic's documented rules.

1. You cannot edit a production app

Epic's process guide is blunt: "Neither you nor Epic can make updates to an app once it has been marked Ready for Production. With the exception of adding redirect URIs and modifying your JWK Set URLs, all technical changes will require you to build a new app." A new app means a new client ID, which every customer must review and download again. Budget a scope review before you mark anything ready.

2. Over-scoping slows sales

Customers review every API on your client ID, and Epic says security and privacy reviewers "may delay or reject apps that request more access than they clearly need." Over-scoping can also "make your app appear more expensive to enable than it actually is." Epic's advice: scope narrowly, map each API to a use case, and create a new client ID later if you grow.

3. Data varies by organization

The same FHIR API returns different codes, notes and edge cases at different health systems. Budget mapping and testing time per customer, and design your data layer to tolerate missing or differently coded fields.

4. Business associate agreements and security reviews

If your product creates, receives, maintains or transmits protected health information for a provider, you will sign a business associate agreement that must meet 45 CFR 164.504(e). Expect the customer's security team to send questionnaires, and expect legal review of the agreement. Our HIPAA-compliant AI development checklist lists the technical safeguards reviewers ask about.

5. Performance and reliability obligations

Beyond the 1 and 5 percent load guidelines, Epic's developer guidelines ask that users experience "less than 1% downtime" and that apps include "health checks, heartbeat monitoring, and robust logging." That means production-grade hosting and on-call support from day one, which is a running cost, not a one-time task.

6. Ongoing upkeep

Epic customers upgrade on their own schedules, FHIR versions and implementation guides move, and backend apps must keep credentials current. We plan yearly upkeep at 15 to 20 percent of the original build as a budgeting assumption, before new features. Track it as its own line so it does not hide inside "support."

A three-year budget example

Here is what the numbers look like together for a clinician-facing SMART on FHIR app rolled out to five health systems at $100 an hour. Every input is an assumption stated in this article, so swap in your own.

The build is only about half of the three-year total. That is the number to bring to a board or an investor, and it explains why per-site efficiency (templated security answers, a repeatable kickoff, automated configuration) pays back faster than squeezing the first build. It excludes your hosting and each health system's own Epic fees and staff time.

How long does an Epic FHIR integration take?

Build time follows the hours above; go-live time follows the distribution path. A patient-facing USCDI app goes live wherever auto-download is enabled as soon as you mark it Ready for Production, and changes to a draft app sync to Epic's sandbox within about an hour, per Epic's process guide. For certified (g)(10), (g)(31) and (g)(33) APIs, federal rules cap verification at 10 business days and production registration at 5 business days after that.

For clinician-facing and backend apps, a customer must request your app through Epic's App Request Process, and someone at that organization with the "Purchase Apps" security point downloads your client record. After that, the health system's own project plan governs. With a two-person team, a 600 to 1,200 hour build is roughly three to six months; add the first customer's go-live on top, then run later sites in parallel.

Health plans have a different clock. The CMS Interoperability and Prior Authorization Final Rule requires Medicare Advantage organizations, Medicaid and CHIP programs and plans, and Qualified Health Plan issuers on the federal exchanges to stand up Provider Access, Payer-to-Payer and Prior Authorization APIs, generally beginning January 1, 2027, using HL7 FHIR R4 and the SMART App Launch framework. Vendors serving payers should expect demand, and tight deadlines, through 2027.

Should you build direct or use an integration platform?

Build direct when Epic is most of your market and your use case is deep; consider an integration platform or health information network when you need many EHRs at once and shallow data. Direct integration gives you control over scope, performance and workflow, which matters for clinician-facing apps. Platforms and networks spread one connection across many EHRs but add per-transaction or subscription fees and usually limit what you can write back.

Whichever route you take, the per-site work does not disappear; it moves. Ask any platform vendor which tasks in Epic's implementation list they take on and which still fall to you and the health system.

Epic integration budget checklist: 12 questions before you sign

Use this checklist to compare quotes from development firms or to scope an internal project. Each question maps to a cost line above.

1. Which pattern is this? Patient-facing read-only, clinician-facing SMART on FHIR, or backend?
2. What is the exact API list, and which APIs fall outside USCDI?
3. Does the app qualify for auto-download, and if not, who handles each customer's request?
4. Is write-back required, and through which API or interface?
5. How many customer sites in year one, and what is the per-site hour estimate?
6. Who writes the API usage scope, query parameter and data dictionary documents customers ask for?
7. How will the app stay under Epic's 1 percent peak and 5 percent off-peak load guidelines?
8. How is patient matching handled for backend or search workflows?
9. Who signs the business associate agreement, and who answers security questionnaires?
10. What is the plan if scope changes after Ready for Production, given that a new client ID is needed?
11. Is the Connection Hub listing in the budget, and when will you apply?
12. What does upkeep cost per year, and is it quoted separately from new features?

A quote that answers all twelve in writing is one you can compare. If you want a second opinion on a quote or a plan, our web app and software development team builds healthcare integrations and can review scope with you. The hiring guide for web app developers covers how to evaluate the firm itself.

The bottom line on Epic FHIR integration cost

Epic FHIR integration cost is mostly your own engineering and implementation time, not fees paid to Epic. Developer access, sandbox and client ID downloads are free; the Connection Hub listing is an optional $500 per product per year; Epic bills the health system for API use based on production usage. Budget 240 to 1,480 build hours depending on the pattern, add 60 to 250 hours for each clinician-facing or backend customer, and plan yearly upkeep.

The cheapest decisions are the early ones: pick the pattern, scope the APIs narrowly, and prepare the documents every health system will ask for. For related reading, see our guide to HIPAA-compliant AI chatbot development cost and the customer portal development cost breakdown, or visit the Fleurant AI home page. If you are planning an Epic integration and want a scoped estimate, talk to a specialist.