Integrating Your App with Epic: What’s Involved (and How We Can Help)
Last updated: October 2026
We’ve designed Epic integrations across a wide range of use cases: from AI scribes to surgical device tracking in OpTime, to bulk data retrieval for population health analysis, to interoperability strategies for NIH grant proposals. Our hands-on work spans SMART on FHIR apps embedded in the clinician workflow, CDS Hooks decision support, HL7v2 messaging interfaces, and Epic's private APIs accessed through Vendor Services.
- A deep understanding of HIPAA and healthcare compliance
- Knowledge of Health System operations, governance, and IT security processes
- Expertise in clinical workflows and how clinicians actually interact with Epic
- Access to Epic’s front end
This is why we also have an Epic Physician Builder on our team — a practicing MD and Epic-certified power user. This gives us the unique ability to guide your project from the practitioner-facing side, answer real-world workflow questions, and accelerate adoption across technical and clinical stakeholders.
Why Integrating with Epic Is Different
Epic is the dominant EHR platform in the U.S., powering over 50% of all inpatient hospital beds. If you're building for healthcare, Epic is essential.
- Many Health Systems that use Epic impose strict no-screenshot policies
- Epic’s main documentation portal, UserWeb, is only available to active Epic users (ie. Health System employees)
- While you can access a public Epic sandbox for backend APIs, you cannot fully simulate or explore the Epic UI/UX without internal Health System access
- Every Health System runs its own instance of Epic, with its own build, licensing, version and local conventions, so an integration that works at one site is not automatically portable to the next
This creates a significant barrier for third parties trying to understand workflows or user interactions. That’s exactly why our Epic Physician Builder is such a critical part of our team — bridging the gap between technical API designs and the lived experience of Epic users.
How Far Will AI Get Me?
Further than you might expect, but only if you already know what to ask. There are plenty of signs that today's frontier AI models have absorbed detailed knowledge of real-world Epic implementations, yet they tend to be guarded about what they volunteer.
- Start from a blank page and you'll get a generic, high-level Implementation Guide. It will look reasonable, but it will be missing exactly the details a Health System's Epic team looks for first, and that gap tells them straight away that you haven't done this before
- Start from a detailed draft and the answers become far more specific, filling gaps, checking assumptions and expanding on the right sections
A SMART on FHIR launch is a good example. Each Health System has to build an integration record (known as an FDI record) for your app, which defines things like the launch URL and the context parameters passed to your app at launch, such as the patient, encounter and user. Leave these out of your Implementation Guide and an AI model is unlikely to bring them up, so you won't know they were needed until the Health System asks. Name them, and you can ask detailed questions and get useful answers.
AI is a powerful accelerator for experienced teams, but it can't tell you what you don't know to ask. That's where our hands-on Epic experience comes in.
You Found the FHIR APIs? Choosing the Right Integration Pattern
When vendors first start researching Epic integrations, they often discover the Epic FHIR APIs and assume that’s the whole integration path. In reality, it’s just a piece of the puzzle.
- Most FHIR resources are read-only, and write support is limited to a narrow set of resources
- Many workflows, like enrollment, scheduling, or order placement, are not fully covered
- Most FHIR searches and reads require a known Patient ID, complicating "open-ended" workflows
- FHIR is request/response, so there is no native way to be told that something happened without polling
- FHIR APIs for on-demand, patient-specific reads, SMART app launches, and a limited set of writes such as clinical documents
- HL7v2 interfaces (built with Epic's Bridges module) for real-time events: ADT feeds for admissions, discharges and transfers, SIU for appointment changes, ORM/ORU for orders and results, and MDM for transcribed documents. Event feeds are far more dependable than polling FHIR for change
- CDS Hooks for surfacing decision support at defined moments in a clinician's workflow, such as opening a chart or signing an order
- Analytics extracts from Clarity (Epic's relational reporting database) or Caboodle (its data warehouse), or FHIR Bulk Data where available, for population cohorts and longitudinal history. Thousands of sequential FHIR queries are slow, costly and load the production system
- Scheduled flat-file transfers (eg. a nightly SFTP drop) for high-volume operational batches like worklist imports. Unglamorous, but often the most resilient and cheapest option
- X12 transactions for eligibility, claims and other revenue cycle exchanges
Some things can't be integrated at all, however the interface is chosen. Cadence scheduling decision trees, for example, are built from questionnaire records that are evaluated inside the Epic client at runtime. Reporting databases record which answers patients gave, but not the branching rules themselves, so replicating that logic in an external tool means documenting it with the Health System's scheduling analysts and operations team rather than exporting it.
Choosing the right mix for your workflow is the single biggest driver of scope, cost and timeline, and it's where our deep technical experience shines.
Embedding Your App in the Clinician Workflow with SMART on FHIR
Clinician-facing apps can run inside Epic itself. Using a SMART on FHIR (EHR launch), your web app opens in an embedded browser panel within Hyperdrive, Epic's current desktop client, with the patient and user context passed to it automatically through OAuth 2.0. No separate login or patient search is needed.
- Launch points can be placed in an activity tab, a sidebar, a toolbar or menu item, a Storyboard component, or triggered from a CDS Hooks card
- A launch button tucked away in an obscure menu will rarely get used, so the launch location should be designed around the clinical workflow and recommended to the Health System as part of your implementation package
- SMART launches are configured and approved separately at each Health System. There is no global switch that makes an embedded app available to every Epic customer at once
That last point is worth keeping in mind when a high-profile partnership between Epic and a major technology company makes headlines. Those integrations are delivered through Epic itself, while third-party apps are still deployed one Health System at a time.
Writing Data Back into the Patient Record
Reading clinical data is the easy part. Writing data back into the chart is narrower in scope, more tightly governed and more complex to build.
- The mechanism depends on the data type. A signed clinical note may be filed as a FHIR DocumentReference or through an HL7v2 MDM transcription interface, while discrete values like vitals or assessment scores may land in flowsheet rows or SmartData Elements, each with different build requirements
- Clinical review is often required. Many Health Systems won't let a third-party system file finalized data directly into the active chart. Incoming data is commonly routed to a staging area, an In Basket message for review, or a pended state that a clinician must verify and sign
- Patient messaging goes through the Health System. There is no open API for an outside app to send MyChart messages or text messages to patients directly. Patient outreach runs through Epic's own engagement tools (such as Hello World for SMS and Cheers for CRM campaigns) or In Basket workflows, and must respect each patient's communication preferences, consent and department ownership of replies
Designing write-back early, with the clinical review steps agreed with the Health System, avoids rework late in the project.
Testing: Sandboxes vs. Real Epic Environments
Designing against documentation is one thing. Testing is the real bottleneck.
- You cannot spin up Epic locally as a Docker container or VM
- The public FHIR sandbox is useful for validating OAuth token exchange, JWT client authentication, SMART launch redirects and FHIR payload parsing, but it runs generic test data
- There’s a SMART on FHIR Launch Harness, but it’s basic
- There is no public HL7v2 sandbox
- Local provider, department and procedure records
- Custom terminology mappings and documentation templates
- Organization-specific security, network and firewall configuration
- Real clinical workflows, UI behavior and notifications
That testing only happens once your app is configured in the Health System's non-production environments (often called POC or TST), which is why it pays to have the sandbox work completed before then. We lean heavily on our Epic Physician Builder to test, validate, and refine integrations inside real Epic workflows.
Epic Developer Programs: Epic on FHIR, Vendor Services and Showroom
- Epic on FHIR (fhir.epic.com) is free to join. You can register client IDs, test against public FHIR APIs, and build basic SMART launches. For many read-only integrations this is enough to get started
- Vendor Services is Epic's paid developer program, at a $1,900 annual subscription fee. It adds access to a broader set of APIs (including non-FHIR web services), better documentation and examples, testing tools such as a CDS Hooks simulator, application registration management, and a support channel for interoperability requests
- Showroom (which includes Connection Hub) is a directory where vendors list their Epic integrations so Health Systems can discover them. It's a marketing channel, not an app store: a listing doesn't install anything, and every customer still has to provision, configure and security-approve your app locally
- Toolbox is a curated program within Showroom for integrations that follow Epic's recommended approach for a given category
Vendor Services replaced the old App Orchard program, offering a more accessible and predictable cost structure. We have experience navigating Vendor Services, from application onboarding to understanding its limits and opportunities.
What an Epic Integration Really Costs
- Vendor program fees: public FHIR APIs via Epic on FHIR have no transaction fees. Vendor Services carries an annual subscription, and some proprietary APIs and data warehouse access are billed per call, with rates depending on the API class
- Health System licensing: the Health System licenses API bundles and interface capacity from Epic. Depending on what they already own, adding a new HL7v2 interface or API package may require them to expand their Epic contract, which can add procurement time and a budget conversation
- Infrastructure load: high-volume API traffic adds load to the Health System's servers. For organizations hosted by Epic, this can push them into a higher hosting tier
- Health System staff time: analyst, security and interface team hours are often the largest hidden cost, and the hardest to schedule
Mapping these costs early helps you price your product realistically and gives your Health System sponsor what they need for internal approval.
Health System Build, Implementation and Timelines
APIs are only half the story. A Health System can't act on a request to "turn on the APIs". Each deployment needs coordinated build work across several IT teams.
- Security and identity: client systems administrators register and approve your app's client ID, configure OAuth 2.0 settings and public key (JWKS) endpoints, set up background service user accounts and permissions, and open firewall rules or VPN tunnels for point-to-point connections
- Application build: Epic application analysts (eg. Ambulatory, Inpatient, Willow pharmacy) map your integration to local records such as providers, departments and procedures, and build the launch points clinicians will use
- Interfaces: the integration team builds and tests any HL7v2 feeds, including message filtering and code mapping
- Governance: IT governance, security reviews and HIPAA compliance requirements, including the vendor security questionnaire
- An integration needing only 20 hours of actual configuration commonly takes 8 to 12 weeks from kickoff to production, and often longer
- Work has to fit into analyst sprint planning, testing sign-offs and change control windows, with build moved between environments in scheduled migrations
- A detailed Implementation Guide, listing the roles involved, every build and security step, and test scripts, is what gets your project prioritized over the rest of the backlog
The success of an Epic integration also depends on designing clinical workflows that make sense to end users, and on training, go-live support and change management. Our team doesn't just design the integration; we guide your project through Health System processes, security assessments, training, and clinical adoption — all the way to successful deployment and scaling. For a broader overview of the process, see our guide on how to take an app to a Health System.
Positioning Your Product Alongside Native Epic Features
Health Systems will ask whether Epic already does what your product does. Answering that well requires separating what Epic can do from what a given Health System actually uses.
- Roadmap is not reality: a feature demonstrated at an Epic conference or listed in release notes may not be licensed, installed, or adopted at a particular Health System, and upgrades can lag by a year or more
- Find the operational gaps: Epic covers broad, standardized clinical and revenue workflows well. The opportunities are usually at the edges: hand-offs between organizations, payer-specific prior authorization rules, specialized device data, and processes still held together by manual coordination
- Complement, don't compete: products that fit into native workflows (launching in context, filing results where clinicians already look) are much easier for a Health System to approve than ones that replace them
Ready to Integrate with Epic?
- Design your Epic integration architecture across FHIR, HL7v2, CDS Hooks and analytics extracts
- Build and test SMART on FHIR apps, interfaces and backend services
- Navigate Vendor Services, Showroom and Health System processes, reviews and assessments
- Test and validate integrations with real Epic users
- Write full Implementation Guides, compliance documentation and workflow plans
- Help you scope costs and timelines realistically for your roadmap and your customers