{"id":22879,"date":"2026-05-18T10:11:54","date_gmt":"2026-05-18T10:11:54","guid":{"rendered":"https:\/\/engineerbabu.com\/blog\/?p=22879"},"modified":"2026-05-18T10:15:39","modified_gmt":"2026-05-18T10:15:39","slug":"epic-fhir-integration-guide-usa","status":"publish","type":"post","link":"https:\/\/engineerbabu.com\/blog\/epic-fhir-integration-guide-usa\/","title":{"rendered":"How to Integrate Your App with Epic EHR Using FHIR in the USA: The Honest Builder&#8217;s Guide (2026)"},"content":{"rendered":"<p><span style=\"font-weight: 400;\">A healthtech founder told me his Epic integration was &#8220;basically done&#8221; when he got on a call with me. He&#8217;d completed the sandbox testing. The FHIR calls were working. He was ready to go live with his first hospital client.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">What he hadn&#8217;t done: submitted an Interoperability Request to get production API access. Hadn&#8217;t initiated the per-site review with the hospital&#8217;s IT team. Hadn&#8217;t completed Epic&#8217;s security questionnaire. Hadn&#8217;t registered in Epic Showroom. The hospital&#8217;s IT lead had told him they&#8217;d only proceed once he was &#8220;listed in App Orchard&#8221;, which no longer exists as a program.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">He was looking at another 4 months minimum.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">I&#8217;ve seen this pattern enough times that I now consider &#8220;my Epic integration is almost ready&#8221; to be one of the most expensive phrases in health tech. What follows is the guide I wish that founder had read before he scoped his timeline.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">I&#8217;m Mayank Pratap, co-founder of <\/span><a href=\"http:\/\/engineerbabu.com\"><span style=\"font-weight: 400;\">EngineerBabu<\/span><\/a><span style=\"font-weight: 400;\">, a CMMI Level 5 team that has shipped EHR integrations for healthcare clients including Apollo Hospitals, ResMed\/Somnoware, and US-based digital health startups. FHIR integrations, HL7 interfaces, bidirectional Epic write-back, we&#8217;ve built them all in production, not in sandboxes.<\/span><\/p>\n<h2><b>What Is Epic FHIR Integration?<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Epic FHIR integration is the process of connecting a third-party healthcare application to Epic&#8217;s electronic health record system using FHIR R4 APIs and the SMART on FHIR authorization framework.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">It enables apps to securely read patient demographics, clinical data, medications, lab results, and documents from Epic and in some cases write data back.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">As of 2026, Epic is installed across 42.3% of US acute care hospitals, covering 250+ million patient records. Thus, making it the most strategically critical <\/span><a href=\"https:\/\/engineerbabu.com\/blog\/telemedicine-emr-integration-for-smarter-workflows\/\"><span style=\"font-weight: 400;\">EHR integration<\/span><\/a><span style=\"font-weight: 400;\"> for any US healthcare software product.<\/span><\/p>\n<h2><b>Why Epic Integration Is Non-Negotiable for US Healthtech<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Epic&#8217;s market position in US healthcare is not a preference, it&#8217;s infrastructure. Hospitals where Epic is deployed include Mayo Clinic, Johns Hopkins, Kaiser Permanente, Cleveland Clinic, and most major academic medical centers.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">If your product targets hospital systems, specialty practices operating on Epic, or any patient population that receives care in an Epic-powered facility, integration is not a differentiator. It is a prerequisite for the deal.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The 21st Century Cures Act information blocking provisions, now fully in effect, require Epic to provide API access to patient data via FHIR. This was the regulatory forcing function that made Epic&#8217;s previously closed ecosystem far more accessible to developers.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">What was extremely difficult to access before 2020 is now technically available, the FHIR R4 APIs are real, well-documented, and increasingly comprehensive.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The challenge is not technical access. The challenge is the <\/span><b>organizational, bureaucratic, and per-site complexity<\/b><span style=\"font-weight: 400;\"> that sits between &#8220;I have API access in sandbox&#8221; and &#8220;I am live in production at Hospital X.&#8221;<\/span><\/p>\n<p><span style=\"font-weight: 400;\">As Brendan Keeler, a widely cited EHR integration analyst, puts it: &#8220;Integration is 20% development, 80% negotiation.&#8221;<\/span><\/p>\n<h2><b>The Four Integration Pathways And When to Use Each<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Epic supports four distinct integration pathways. Choosing the right one before you integrate with Epic FHIR API in the USA saves months of rework.\u00a0<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>FHIR R4 APIs (the modern standard, use this for new builds)<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">RESTful APIs returning JSON, structured around FHIR R4 resources. This is what you build against for new <\/span><a href=\"https:\/\/engineerbabu.com\/blog\/healthcare-app-development-native-vs-hybrid-vs-web\/\"><span style=\"font-weight: 400;\">healthcare apps<\/span><\/a><span style=\"font-weight: 400;\">. Supports reading patient demographics, conditions, medications, allergies, lab results, vital signs, appointments, clinical notes, immunizations, and procedures. Accessed via SMART on FHIR authorization.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">.Read access is more accessible. Write access, creating clinical notes, updating problem lists, placing orders, modifying appointments, requires additional review, additional scopes, and individual approval at each site.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>HL7 v2 Messaging (for real-time clinical events)<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">HL7 v2 is the 1987-era messaging standard that still powers the real-time clinical event layer in hospitals. If you need to know the moment a patient is admitted (ADT message), a lab result is available, or an order is placed, this is your pathway. FHIR R4 is better for data retrieval; HL7 v2 is still the mechanism for event-driven workflows.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">HL7 v2 integration with Epic requires an integration engine. <\/span><b>Mirth Connect<\/b><span style=\"font-weight: 400;\"> is the most widely used open-source option. The messages use pipe-delimited format, every hospital configures segment content differently, and every new hospital site essentially requires its own integration build.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Bulk FHIR Export (for population health and analytics)<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">For analytics platforms, population health tools, and research applications that need to process data across thousands or millions of patients, FHIR Bulk Data Export allows asynchronous export of large datasets.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">You request the export, Epic processes it asynchronously, and you poll for completion. Essential for data warehouse integrations but not appropriate for real-time clinical workflows.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>CDS Hooks (for decision support embedded in Epic workflow)<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">CDS Hooks is the standard for embedding real-time clinical decision support directly into Epic&#8217;s Hyperspace clinical workflow.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">When a physician opens a patient chart, places an order, or performs a specific action, Epic calls your service and you return information cards that appear directly in the clinician&#8217;s Epic workspace.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Used for AI-assisted diagnosis, drug interaction alerts, prior authorization checks, and risk stratification tools that need to surface at the point of care.<\/span><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-22884\" src=\"https:\/\/engineerbabu.com\/blog\/wp-content\/uploads\/2026\/05\/epic_img1_four_pathways.png\" alt=\"\" width=\"812\" height=\"570\" title=\"\"><\/p>\n<h2><b>SMART on FHIR: The Authorization Layer You Cannot Skip<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Every FHIR API call to Epic requires authentication via SMART on FHIR, an authorization framework layered on OAuth 2.0 and OpenID Connect.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Understanding this before you start building saves you from the authentication rework that kills most early Epic integration projects.<\/span><\/p>\n<h3><b>The launch context distinction matters enormously:<\/b><\/h3>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>EHR Launch (from within Epic Hyperspace):<\/b><span style=\"font-weight: 400;\"> A clinician is working in Epic and clicks to launch your application. Epic initiates the SMART launch sequence, providing your app with a launch token that carries patient context (which patient is open), encounter context (which encounter), and user context (who is logged in). Your app exchanges this token for an access token scoped to that specific patient and user. This is the integration model for apps that live inside the clinical workflow.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Standalone Launch:<\/b><span style=\"font-weight: 400;\"> Your app launches independently and must authenticate without Epic providing context. Users authenticate with MyChart credentials and you discover patients through FHIR search. This is appropriate for patient-facing apps but creates friction in multi-provider scenarios.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>The scopes problem:<\/b><span style=\"font-weight: 400;\"> SMART on FHIR scopes define precisely what data your app can access. <\/span><span style=\"font-weight: 400;\">patient\/Observation.read<\/span><span style=\"font-weight: 400;\"> lets you read vital signs and lab results for the current patient. <\/span><span style=\"font-weight: 400;\">user\/MedicationRequest.write<\/span><span style=\"font-weight: 400;\"> lets you create medication orders on behalf of the logged-in user. Every scope you request must be explicitly approved first by Epic in your application registration, then by each hospital site individually.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Requesting only the scopes you genuinely need is not just a principle of minimum necessary access under HIPAA. It is a practical strategy for getting approved faster. The broader your scope requests, the longer the review process. I&#8217;ve watched teams get held up for 8 weeks because they included <\/span><span style=\"font-weight: 400;\">user\/DiagnosticReport.write<\/span><span style=\"font-weight: 400;\"> in their scope list &#8220;for future use&#8221; and triggered additional clinical safety review.<\/span><\/p>\n<h3><b>The technical implementation pattern:<\/b><\/h3>\n<ol>\n<li><span style=\"font-weight: 400;\"> Register app at open.epic.com \u2192 receive client_id<\/span><\/li>\n<li><span style=\"font-weight: 400;\"> Direct user to Epic&#8217;s authorization endpoint<\/span><\/li>\n<\/ol>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\/oauth2\/authorize?response_type=code<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0&amp;client_id={your_client_id}<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0&amp;redirect_uri={your_uri}<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0&amp;scope={your_scopes}<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0&amp;state={random_state}<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0&amp;aud={fhir_base_url}<\/span><\/p>\n<ol start=\"3\">\n<li><span style=\"font-weight: 400;\"> Epic authenticates user, user consents<\/span><\/li>\n<li><span style=\"font-weight: 400;\"> Epic redirects to your URI with authorization code<\/span><\/li>\n<li><span style=\"font-weight: 400;\"> Exchange code for tokens via POST \/oauth2\/token<\/span><\/li>\n<\/ol>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0Include: code, client_id, redirect_uri,\u00a0<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0grant_type=authorization_code<\/span><\/p>\n<ol start=\"6\">\n<li><span style=\"font-weight: 400;\"> Receive access_token + refresh_token + id_token<\/span><\/li>\n<li><span style=\"font-weight: 400;\"> Use access_token as Bearer token in FHIR API calls<\/span><\/li>\n<\/ol>\n<p><span style=\"font-weight: 400;\">For backend services (no user interaction), Epic supports the Backend Services authorization flow using JWT assertions signed with your private key. This is the pathway for bulk data exports and system-to-system integrations.<\/span><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-22883\" src=\"https:\/\/engineerbabu.com\/blog\/wp-content\/uploads\/2026\/05\/epic_img2_smart_auth_flow.png\" alt=\"\" width=\"812\" height=\"600\" title=\"\"><\/p>\n<h2><b>The Resources That Actually Matter: What Your App Can Read<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Epic provides approximately 450 FHIR R4 API endpoints across 55 resource types. In practice, the resources you&#8217;ll actually use in the majority of clinical app integrations fall into a much smaller set:<\/span><\/p>\n<p><b>Clinical data, most commonly needed:<\/b><\/p>\n<table>\n<tbody>\n<tr>\n<td><b>Resource<\/b><\/td>\n<td><b>What it contains<\/b><\/td>\n<td><b>Common use<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Patient<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Demographics, contact info, MRN<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Identity verification, patient matching<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Condition<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Active and historical diagnoses (ICD-10)<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Problem list, clinical context<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">MedicationRequest<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Prescribed medications, dosing<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Medication reconciliation, safety checks<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Observation<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Lab results, vital signs, social history<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Clinical decision support, monitoring<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">AllergyIntolerance<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Drug and food allergies<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Safety alerts, prescription validation<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">DiagnosticReport<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Lab result summary reports<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Clinical review<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Appointment<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Scheduled visits<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Scheduling apps, care coordination<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">DocumentReference<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Clinical notes, discharge summaries<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Chart review, ambient documentation<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Immunization<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Vaccination records<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Preventive care, public health<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Procedure<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Procedures performed<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Clinical history, coding support<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><b>The optionality problem:<\/b><span style=\"font-weight: 400;\"> Not every patient has structured allergies. Not every observation has a <\/span><span style=\"font-weight: 400;\">valueQuantity<\/span><span style=\"font-weight: 400;\">. Not every medication has a structured <\/span><span style=\"font-weight: 400;\">dosageInstruction<\/span><span style=\"font-weight: 400;\">.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Epic returns what it has, which varies by how the clinical encounter was documented. Your application must be defensively coded to treat missing fields as expected, not exceptional.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">An app that crashes because <\/span><span style=\"font-weight: 400;\">Observation.valueQuantity<\/span><span style=\"font-weight: 400;\"> is null will fail in production even though it worked perfectly in sandbox.<\/span><\/p>\n<h2><b>Read Access vs. Write Access: The Line Most Teams Cross Too Late<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">This is the single most important distinction in Epic FHIR integration that most developers don&#8217;t internalize until they&#8217;ve scoped a project incorrectly.<\/span><\/p>\n<p><b>Read access<\/b><span style=\"font-weight: 400;\">: Querying patient data from Epic is relatively accessible. The FHIR R4 read endpoints are well-documented at open.epic.com, the sandbox is publicly available, and the approval process, while not instant, is structured.<\/span><\/p>\n<p><b>Write access<\/b><span style=\"font-weight: 400;\">: Creating or modifying data in Epic is a fundamentally different category. Writing clinical notes, placing orders, updating the problem list, modifying appointment records, each of these carries clinical liability implications that Epic and individual hospital sites take seriously.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Write access requires:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Specific write scopes explicitly approved at the application level<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Additional clinical safety review at the Epic Vendor Services level<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Individual hospital IT governance approval at each site<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">In many cases, review by the hospital&#8217;s clinical informatics committee<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">The practical implication: if your product roadmap includes writing anything back to Epic, ambient documentation posting notes, prior auth status updating patient records, AI-generated coding suggestions modifying claims build that into your timeline as a 2\u20134 month additional process per site. Not per integration type. Per site.<\/span><\/p>\n<h2><b>The App Orchard \u2192 App Market \u2192 Showroom History You Need to Understand<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Epic has gone through three iterations of its third-party developer program since 2016, and the resulting confusion is actively costing healthtech teams months of wasted time.<\/span><\/p>\n<p><b>App Orchard (2016\u20132021):<\/b><span style=\"font-weight: 400;\"> Epic&#8217;s original third-party app marketplace. Charged developers up to 30% revenue share. Was widely criticized for slow processing and outright pauses on new applications for months at a time.<\/span><\/p>\n<p><b>App Market (2021\u20132022):<\/b><span style=\"font-weight: 400;\"> A rebranding of App Orchard. Shut down entirely in 2022.<\/span><\/p>\n<p><b>Showroom (2024\u2013present):<\/b><span style=\"font-weight: 400;\"> Epic&#8217;s current marketplace, featuring three tiers:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Connection Hub:<\/b><span style=\"font-weight: 400;\"> Basic listing for third-party applications. Starts at $500\/year. This is where most third-party apps live.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Toolbox:<\/b><span style=\"font-weight: 400;\"> Curated patterns and specifications. Provides more visibility to Epic customers.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Workshop:<\/b><span style=\"font-weight: 400;\"> Reserved for vendors Epic is actively co-developing with Nuance (ambient documentation), Abridge (ambient documentation), Press Ganey (patient satisfaction). This is not a tier you apply to.<\/span><\/li>\n<\/ul>\n<p><b>The crucial confusion still happening today:<\/b><span style=\"font-weight: 400;\"> Hospital IT leads frequently tell vendors &#8220;we&#8217;ll only consider you once you&#8217;re listed in App Orchard.&#8221; App Orchard no longer exists. Epic Vendor Services (the developer program) has no direct connection to Showroom listing. Yet this belief persists widely in hospital IT departments and is delaying integrations across the industry.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">If a hospital IT lead tells you this, send them to showroom.epic.com and explain the distinction between Vendor Services registration (required for production API access) and Connection Hub listing (recommended but separate).<\/span><\/p>\n<p><b>The practical guidance:<\/b><span style=\"font-weight: 400;\"> Register with Epic Vendor Services to get production API access. Submit a Connection Hub listing in Showroom for discovery and to reduce friction in hospital IT conversations. Start both processes on Day 1 of your integration project, not after development is complete.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The review queues are backlogged. Early submission consistently beats late submission by 6\u201310 weeks.<\/span><\/p>\n<h2><b>The Per-Site Go-Live Reality That Destroys Timelines<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">This is the part of Epic integration that most cost and timeline guides mention briefly and most founders don&#8217;t truly internalize until it&#8217;s too late.<\/span><\/p>\n<h3><b>An integration that works at Hospital A does not go live at Hospital B.<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Epic is configured differently at every organization. The FHIR base URL is different. The custom SmartData Elements are different. The scope of locally available FHIR resources varies. The internal governance process who needs to approve a new third-party integration varies. The hospital IT team&#8217;s availability varies.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Every new Epic customer site requires:<\/span><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>IT Governance Approval:<\/b><span style=\"font-weight: 400;\"> Hospital&#8217;s IT security team reviews your application and security posture. This typically involves their own vendor security questionnaire, separate from Epic&#8217;s. Budget 4\u201310 weeks.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Interface Build:<\/b><span style=\"font-weight: 400;\"> The hospital&#8217;s Epic team configures the integration on their end. Their IT team&#8217;s availability and workload determine how fast this happens and you have zero control over their queue.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Vendor Test Environment (VTE) Testing:<\/b><span style=\"font-weight: 400;\"> Epic provides a Vendor Test Environment where you test against the hospital&#8217;s actual Epic configuration before production go-live. This surfaces the site-specific quirks that passed in the generic sandbox.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>User Acceptance Testing (UAT):<\/b><span style=\"font-weight: 400;\"> Clinical end users, physicians, nurses, staff, test the integration in a pre-production environment. Any workflow issues discovered here add weeks.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Go-Live Approval:<\/b><span style=\"font-weight: 400;\"> Final sign-off from hospital IT, clinical informatics, and sometimes legal\/compliance.<\/span><\/li>\n<\/ol>\n<h3><b>The timeline reality per site:<\/b><\/h3>\n<table>\n<tbody>\n<tr>\n<td><b>Scenario<\/b><\/td>\n<td><b>Timeline<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">FHIR read-only, minimal scopes, simple app<\/span><\/td>\n<td><span style=\"font-weight: 400;\">2\u20134 months<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">FHIR bidirectional + write access<\/span><\/td>\n<td><span style=\"font-weight: 400;\">6\u201310 months<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">HL7 v2 + FHIR combined (clinical events + data)<\/span><\/td>\n<td><span style=\"font-weight: 400;\">8\u201314 months<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Enterprise multi-site (3+ hospitals)<\/span><\/td>\n<td><span style=\"font-weight: 400;\">12\u201324 months<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><span style=\"font-weight: 400;\">That timeline repeats, in modified form, for every Epic hospital site you want to go live with. A 50-hospital deployment is not one integration, it is 50 integrations, each with its own IT approval cycle, each with its own Epic configuration quirks, each with its own go-live queue.<\/span><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-22882\" src=\"https:\/\/engineerbabu.com\/blog\/wp-content\/uploads\/2026\/05\/epic_img3_goLive_timeline.png\" alt=\"\" width=\"812\" height=\"540\" title=\"\"><\/p>\n<h2><b>The Realistic Cost Breakdown<\/b><\/h2>\n<table>\n<tbody>\n<tr>\n<td><b>Component<\/b><\/td>\n<td><b>Cost Range<\/b><\/td>\n<td><b>Notes<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Epic Showroom Connection Hub listing<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$500\/year<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Discovery; not required but strongly recommended<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Initial FHIR read integration build<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$15,000\u2013$40,000<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Sandbox \u2192 production API access \u2192 first site live<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Bidirectional integration (read + write)<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$40,000\u2013$80,000<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Write scopes dramatically increase review complexity<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Per additional site go-live<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$5,000\u2013$20,000<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Configuration, VTE testing, UAT, IT governance<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">HL7 v2 integration (Mirth Connect)<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$20,000\u2013$50,000<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Integration engine setup, message mapping, per-hospital HL7 profile<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Enterprise multi-site (5+ hospitals)<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$100,000\u2013$500,000+<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Developer cost + per-site fees + management overhead<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Annual maintenance (FHIR version updates, Epic quarterly upgrades)<\/span><\/td>\n<td><span style=\"font-weight: 400;\">15\u201320% of build<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Epic releases updates regularly; integrations must evolve<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><b>The hidden cost most teams miss:<\/b><span style=\"font-weight: 400;\"> Epic releases quarterly updates. FHIR endpoints change. Resource types are added. HL7 message profiles are updated. Your integration is not finished when it goes live, it requires ongoing maintenance to stay current with Epic&#8217;s release cadence.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Budget 15\u201320% of your initial build cost annually for maintenance, whether you&#8217;re building or buying the integration layer.<\/span><\/p>\n<h2><b>Five Mistakes That Kill Epic Integration Timelines<\/b><\/h2>\n<h3><b>Mistake 1: Treating sandbox success as production-ready.<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">The Epic public sandbox at <\/span><a href=\"http:\/\/open.epic.com\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">open.epic.com<\/span><\/a><span style=\"font-weight: 400;\"> is an excellent development environment. It is not representative of individual hospital configurations. Medication resources that return perfectly in sandbox return empty in some hospital configurations because of how those sites configured drug database references. Test against the specific hospital site&#8217;s Vendor Test Environment before assuming your integration will work.<\/span><\/p>\n<h3><b>Mistake 2: Requesting write scopes before you need them.<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Every write scope you request triggers additional review. If your v1 product only reads patient data to display it in your UI, request only read scopes. Add write scopes in a subsequent approval cycle when you&#8217;re ready to use them. Requesting <\/span><span style=\"font-weight: 400;\">user\/MedicationRequest.write<\/span><span style=\"font-weight: 400;\"> &#8220;for future use&#8221; can add 8\u201312 weeks to your approval timeline.<\/span><\/p>\n<h3><b>Mistake 3: Starting the Showroom\/Vendor Services process after development.<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Epic&#8217;s Interoperability Request process, submitting your <\/span><a href=\"https:\/\/engineerbabu.com\/services\/api-development\"><span style=\"font-weight: 400;\">API<\/span><\/a><span style=\"font-weight: 400;\"> requirements for Epic technical review is a prerequisite for production API access. Starting this on the day your development completes puts you 6\u201310 weeks behind where you could have been. Submit your Interoperability Request during week 2 of development.<\/span><\/p>\n<h3><b>Mistake 4: Ignoring FHIR version drift.<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Hospitals running older Epic deployments may be on FHIR DSTU2 or STU3, not R4. FHIR R4 should be your primary build target for everything new, but if your hospital client base includes any organizations on older Epic versions, you need an adapter layer that normalizes resource structures across FHIR versions. Discovering this after you&#8217;ve built an R4-only application means rewriting significant portions of your data layer.<\/span><\/p>\n<h3><b>Mistake 5: Underestimating clinical informatics review.<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Especially for any application that writes to Epic, ambient documentation, clinical decision support, prior authorization, hospital clinical informatics committees review the application before approving go-live. These committees include physicians, nursing leadership, and pharmacists who evaluate whether your application&#8217;s write-backs could introduce clinical risk. Their approval timeline is independent of IT and is typically 4\u20138 weeks. It cannot be accelerated by your sales team.<\/span><\/p>\n<h2><b>What This Means for Your Product Architecture<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Three architecture decisions made at the start of an Epic integration project have outsized impact on long-term velocity:<\/span><\/p>\n<p><b>Build a FHIR-normalized data layer.<\/b><span style=\"font-weight: 400;\"> Instead of writing Epic-specific code throughout your application, build a translation layer that converts Epic&#8217;s FHIR resources into your application&#8217;s internal data model. When you add Cerner or Athenahealth integration later, you add a new translation layer and not rewrite the application. This is the single highest-leverage architecture decision for a product that will integrate with multiple EHRs.<\/span><\/p>\n<p><b>Gate features by site capability.<\/b><span style=\"font-weight: 400;\"> Build a per-site conformance registry, a configuration file that records which FHIR resources, which scopes, and which FHIR version each hospital site supports. Your application routes around missing capabilities rather than failing. This is what production-grade EHR integration at scale looks like.<\/span><\/p>\n<p><b>Treat each hospital site as a separate deployment.<\/b><span style=\"font-weight: 400;\"> This is not just a mindset shift, it&#8217;s an operational reality that needs to be reflected in your project management. A dedicated go-live checklist per site. A site-specific configuration file. A site-specific test plan. Teams that treat Epic integration as a single project and not a template for repeated site deployments consistently underestimate the operational overhead.<\/span><\/p>\n<h2><b>The Honest Bottom Line<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">When you try to integrate with Epic FHIR API in the USA, you realize it is a technical problem wrapped inside an organizational, bureaucratic, and governance problem and the organizational layer typically takes longer than the technical layer.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The teams that succeed with Epic integration consistently do three things differently:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">They start the Vendor Services and Showroom registration process on Day 1 of the project;<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">They build for per-site variability rather than assuming a generic Epic integration; and<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">They treat every write-back scope as a clinical governance decision requiring hospital approval, not just an API permission.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">The 21st Century Cures Act made the data technically accessible. The per-site reality of 250 million patient records spread across hundreds of differently configured hospital Epic deployments means the work of actually reaching those patients is an 80% organizational challenge with 20% code.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The EngineerBabu team has shipped FHIR integrations, bidirectional Epic write-back systems, and HL7 v2 interfaces for healthcare clients across the USA.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">If you&#8217;re scoping an Epic integration and want to understand the timeline and organizational dependencies before you commit to a product roadmap, that&#8217;s exactly the kind of conversation I have before a project begins. Reach me at <\/span><a href=\"mailto:mayank@engineerbabu.com\"><span style=\"font-weight: 400;\">mayank@engineerbabu.com<\/span><\/a><span style=\"font-weight: 400;\">.<\/span><\/p>\n<p><b>Author:<\/b><span style=\"font-weight: 400;\"> Mayank Pratap Co-Founder, EngineerBabu Google AI Accelerator 2024 \u00b7 CMMI Level 5 \u00b7 500+ Products \u00b7 20+ Countries<\/span><a href=\"https:\/\/www.linkedin.com\/in\/mayankpratap\/\" target=\"_blank\" rel=\"noopener\"> <span style=\"font-weight: 400;\">LinkedIn<\/span><\/a><\/p>\n<h2><b>FAQ<\/b><\/h2>\n<ul>\n<li aria-level=\"1\">\n<h3><b>How long does Epic FHIR integration take?<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">A simple FHIR read-only integration for a single hospital site takes 2\u20134 months from starting development to production go-live. Bidirectional integration with write access takes 6\u201310 months. HL7 v2 combined with FHIR for event-driven workflows takes 8\u201314 months. These timelines include Epic Vendor Services review, per-site IT governance, Vendor Test Environment testing, and UAT not just development time.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>How much does Epic FHIR integration cost?<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">A basic FHIR read integration for the first site costs $15,000\u2013$40,000. Bidirectional integration costs $40,000\u2013$80,000. Each additional hospital site go-live adds $5,000\u2013$20,000 in configuration, testing, and IT governance costs. Enterprise multi-site deployments (5+ hospitals) run $100,000\u2013$500,000+. Annual maintenance is 15\u201320% of build cost.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Do I need to be listed on Epic App Orchard?<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">App Orchard no longer exists, it was replaced by Epic Showroom with Connection Hub, Toolbox, and Workshop tiers. You do not technically require a Connection Hub listing to integrate with Epic, but it substantially reduces friction with hospital IT teams. Many hospital IT leads still ask for &#8220;App Orchard&#8221; listing, explaining that the Connection Hub listing on Showroom is the current equivalent.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>What is the difference between FHIR read and write access in Epic?<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Read access is accessible with standard SMART on FHIR authorization and Epic Vendor Services registration. Write access requires additional scope approvals, clinical safety review, and individual hospital governance approval at each site. Write access adds 2\u20134 months to the per-site approval process.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>What is SMART on FHIR and why does it matter for Epic integration?<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">SMART on FHIR is the authorization framework that governs how apps access Epic&#8217;s FHIR APIs. Built on OAuth 2.0, it provides launch context (which patient, which encounter, which user), issues scoped access tokens, and supports both clinician-launched apps inside Epic Hyperspace and standalone patient-facing apps.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>A healthtech founder told me his Epic integration was &#8220;basically done&#8221; when he got on a call with me. He&#8217;d completed the sandbox testing. The FHIR calls were working. He was ready to go live with his first hospital client. What he hadn&#8217;t done: submitted an Interoperability Request to get production API access. Hadn&#8217;t initiated [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":22885,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1246],"tags":[],"class_list":["post-22879","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-healthtech"],"_links":{"self":[{"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/posts\/22879","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/comments?post=22879"}],"version-history":[{"count":2,"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/posts\/22879\/revisions"}],"predecessor-version":[{"id":22887,"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/posts\/22879\/revisions\/22887"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/media\/22885"}],"wp:attachment":[{"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/media?parent=22879"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/categories?post=22879"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/tags?post=22879"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}