Epic EHR integration connects your healthcare application to Epic, the EHR used by many of the largest U.S. health systems, so your app can read patient data, launch inside clinician workflows, and write information back to the chart. In 2026, the path runs through open.epic’s free APIs, optional Vendor Services support, and the Showroom marketplace that replaced App Orchard. This guide explains each program, the integration methods available, a step-by-step process, and the challenges that shape timelines. Our HL7 and FHIR integration services team handles Epic projects end to end.
TechEsperto is not affiliated with Epic Systems Corporation. Epic, open.epic, Showroom, and related names are trademarks of their owner.
Epic’s developer ecosystem changed significantly after App Orchard was retired. Today, developers start with open.epic, which provides standards-based and Epic public APIs free of charge, plus documentation and testing tools. Vendor Services is an optional paid program offering additional technology and support. Showroom is the marketplace where Epic customers discover third-party products. Understanding which program you actually need prevents wasted time and unnecessary fees early in your Epic integration project.
open.epic publishes hundreds of industry-standard and Epic public APIs, free to app developers, along with design guidance, developer guidelines, and testing tools such as a FHIR sandbox and test harnesses.
Epic on FHIR is the developer-facing entry point for FHIR APIs and SMART on FHIR apps, where developers register applications and build against public sandbox environments without a formal Epic relationship.
Vendor Services is an optional offering for organizations meeting enrollment criteria. It adds expanded testing environments and access to Epic representatives for technical and implementation support, billed separately.
Showroom is Epic’s marketplace for third-party products. Connection Hub, its entry listing, is for products with a live connection at an Epic customer and carries an annual listing fee.
App Orchard, later called App Market, was replaced by Vendor Services and Showroom. Older guides referencing App Orchard approval steps are outdated and can mislead project planning.
Epic supports several integration methods, and most production apps combine more than one. The right choice depends on whether clinicians use your app inside Epic, whether your system runs background data exchange, and whether you need standards-based FHIR access or traditional HL7 interfaces. Choosing methods early clarifies which approvals, scopes, and customer configurations your project needs. For the basics of the standard, see our explanation of what FHIR is.
Epic’s FHIR APIs expose resources such as Patient, Encounter, Observation, MedicationRequest, and DocumentReference. Read support is broad, while write support varies by resource and customer configuration.
Clinicians launch your app from within Epic, which passes patient and user context through OAuth 2.0. This removes separate logins and keeps your app inside existing clinical workflows.
Patients or clinicians launch your app outside Epic and authorize access to Epic data. Patient-facing apps commonly use this method to retrieve records with patient authorization.
Backend services authorization lets your server exchange data with Epic without a user present, using signed credentials. It suits population data syncs, scheduled jobs, and analytics feeds.
Many health systems still exchange scheduling, admissions, orders, and results through HL7 v2 messages. These interfaces are configured with each customer’s integration team and often run through interface engines.
A successful Epic integration follows a predictable sequence, but each step involves different stakeholders: your engineering team, Epic’s programs, and the health system that runs Epic. The health system is often the deciding factor, because it approves and configures your app’s access in its own environment. Planning for customer-side work from the start avoids the common mistake of finishing development before anyone at the hospital is ready to activate it.
List the workflows your app supports and the exact Epic data each requires, including read versus write. Narrow scopes speed approvals and simplify security reviews.
Register your app on Epic’s developer platform, obtain credentials, and build against public sandbox data. Validate authentication, launch flows, and every API call before approaching customers.
Find a customer champion, often in clinical informatics or digital health, who will advocate internally, coordinate their Epic team, and guide your app through their approval process.
Expect detailed security questionnaires, architecture reviews, and contract terms from each health system. Prepare documentation, penetration test results, and a signed BAA in advance.
The health system’s Epic team configures your app in its test environment. Validate data accuracy, launch behavior, and write-back with real workflows before production approval.
After production go-live, monitor errors and usage closely. With a live customer connection, you can optionally list the product in Connection Hub so other Epic customers find it.
Many teams assume paid Epic membership is mandatory. It is not. Standards-based APIs and sandbox testing on open.epic are free, and many integrations go live without Vendor Services. However, the paid program can be valuable when you need expanded testing environments, direct Epic support, or certain designations within Showroom. Decide based on your integration depth, customer expectations, and how many Epic sites you plan to serve.
Standards-based FHIR integrations with clear scopes, SMART launches, and a supportive health system sponsor can often be built and deployed using open.epic resources alone.
Complex integrations, proprietary APIs, larger testing needs, or plans to scale across many Epic customers may justify paid access to expanded tools and Epic representatives.
Toolbox highlights products in categories where Epic publishes recommended integration practices. It requires Vendor Services enrollment and is granted at Epic’s discretion, not purchased directly.
Epic periodically changes program structures, eligibility, and fees. Confirm current terms on open.epic and with Epic before budgeting, rather than relying on third-party summaries.
Epic integration is technically well documented, but real-world projects run into challenges that documentation does not solve. Every health system configures Epic differently, upgrades on its own schedule, and controls which apps reach production. Write access is often more limited than teams expect, and security reviews can take months. Experienced EHR integration developers anticipate these issues and plan around them from the first week.
Integration with one Epic customer does not automatically extend to others. Each health system must approve, configure, and test your app in its own environment.
Data availability, workflows, and code sets vary by organization. An integration that works at one hospital may need mapping changes at the next.
Reading data is usually easier than writing it. Confirm which resources your use case can write, and in what format, before promising structured documentation to clinicians.
Health system security teams review architecture, hosting, encryption, and vendor risk. Missing documentation or penetration test results can add months to approval timelines.
Epic customers upgrade regularly, and API behavior can change. Monitor integrations continuously and test against upgrade schedules to avoid unexpected production failures.
The cost of Epic EHR integration depends far less on Epic’s program fees than on engineering scope and customer-side effort. Building authentication, data mapping, error handling, and monitoring takes real development time, while each health system requires its own approvals and testing. Timelines are usually driven by security reviews and customer configuration queues. Specialized SMART on FHIR developers can shorten the technical portion considerably.
open.epic access is free. Vendor Services membership and Showroom listings carry their own fees, which are optional for many projects and should be confirmed directly with Epic.
Costs rise with the number of resources, write-back requirements, launch types, and backend syncs. Read-only SMART apps cost less than bidirectional clinical integrations.
Each health system’s analysts configure, test, and approve your app. Their availability and internal priorities often determine your go-live date more than your engineering speed.
Budget for monitoring, upgrade testing, credential rotation, and support across every Epic site. Maintenance grows with each additional customer connected to your product.
Our work and story have been picked up by news outlets and databases worldwide.
As featured on
Define your use case and data needs, register on Epic’s developer platform, and build against the free FHIR sandbox using SMART on FHIR or backend authorization. Then secure a health system sponsor, complete its security and contract reviews, test in its environment, and go live with monitoring in place.
Access to open.epic’s standards-based APIs, documentation, and sandbox testing is free. Optional Vendor Services membership and Showroom listings carry fees. Most of the real cost comes from development, security documentation, and health system configuration work, so budget for engineering and customer-side effort rather than program fees alone.
App Orchard, later renamed App Market, was replaced by Epic’s Vendor Services program for developer support and the Showroom marketplace for product discovery. Developers now start with open.epic and Epic on FHIR, and can optionally list live products in Showroom’s Connection Hub.
Timelines vary widely. Sandbox development for a focused SMART on FHIR app can move quickly, but health system security reviews, contracts, configuration, and testing often take several months. Having a committed customer sponsor and complete security documentation ready shortens timelines more than anything else.
Yes, for certain resources and workflows, though write support is more limited than read access and varies by customer configuration. Common examples include documents and some clinical data. Confirm write capabilities for your exact use case during sandbox testing and with each health system before committing.
Tell us what you’re building. Our team will get back to you within one business day with a clear, no-obligation plan.
