App Orchard is Epic's developer program for third-party apps: you register, build against Epic's FHIR APIs in a sandbox with synthetic patients, submit the app for Epic's review, and once approved, it becomes available for individual health systems to install in their own live instance. Building the app rarely takes as long as everything around it, the review, and then getting each target hospital to actually approve and provision it, since Epic's blessing doesn't automatically turn on access anywhere.
The program starts with registering as a developer and getting sandbox access, which lets you build and test against Epic's FHIR APIs using fake patient data without touching anything live. From there, a real app goes through Epic's own review before it's listed, covering things like data handling, security, and whether it genuinely does what it claims against the resources it's requesting.
Getting listed through Epic's review is a milestone, not the finish line. Each individual health system still has to separately evaluate, approve, and configure the app for its own live Epic instance, your app doesn't automatically become usable everywhere Epic runs just because it's in the catalog. That per-site approval is usually the slower half of the whole process.
Epic has adjusted this program's exact structure, naming, and requirements over the years, so if you're actively building toward a listing, confirm the current process directly through Epic's developer channel rather than relying on anything written a while back, this page included.
Most delays we see aren't about the FHIR calls themselves, those tend to work close to how the sandbox predicted. The real friction shows up at the handoff to each target hospital: getting their IT or interface team to prioritize the review, matching the sandbox's clean test data against the messier reality of their production records, and scheduling a go-live window that fits their calendar, not yours.
We typically come in on one of two sides of that: building the actual integration logic behind an app that's already Epic-reviewed and waiting on a specific health system, or acting as the technical partner validating that a planned build will hold up once it moves from sandbox data to a real, messier production instance.
Once an app has Epic's review and a target health system is ready to connect, we build the data mapping and workflow logic that makes the connection actually do something useful, not just pass a test call.
Synthetic test patients rarely expose the messy edge cases a live Epic instance throws at an integration. We help stress-test an app's logic against realistic data shapes before it hits a hospital's production environment for real.
Tell us where in the process things stalled, review, per-hospital approval, or the build itself, and we'll tell you what's realistic from here.
Tell us where your app actually stands, sandbox, under Epic review, or approved and waiting on a hospital, and we'll scope what's left to build. App Orchard is one specific path into Epic; if your real need is somewhere else in the integration stack, bring that instead and we'll look at it the same way.
Let's talk →Epic's developer program for building, testing, and listing third-party apps against its FHIR APIs. It covers sandbox access, Epic's own review process, and the catalog health systems browse to find apps to install.
Sandbox and developer access are generally available at low or no cost for building and testing. Commercial terms can apply once an app is actually listed and installed at health systems, and those terms are set by Epic directly, not something we'd speak to on their behalf.
No. Being listed means Epic has reviewed and approved the app generally. Each health system still separately decides whether to install it, and that decision and setup happen one hospital at a time, not automatically across every Epic site.
The FHIR API is the technical interface your app actually calls. App Orchard is the program and approval process around getting an app built on that API reviewed and made available for health systems to install.
It varies by app complexity and how much back-and-forth the review needs, but it's commonly measured in months rather than days, and that's before accounting for the separate approval each individual health system runs on its own timeline.