Surviving an Epic App Orchard review: a survival guide

Epic's review process is famously rigorous. There's a reason: Epic powers 250M+ patient records, and an integration that misbehaves can ripple across hundreds of hospital systems. The process is rigorous for good reasons — but it's also navigable. We've been through it nine times. Here's what we've learned.

The three Epic integration paths

Not every integration goes through the same review. The path determines the documentation burden and the timeline.

• App Orchard (now Connection Hub for newer apps) — the marketplace path. You're publishing an app that any Epic customer can install. Highest review burden, longest timeline (typically 3-5 months), but you build once and many customers can install.
• Direct integration with a specific customer — you're integrating with one hospital's Epic instance. Customer's IT team does most of the review. Shorter (6-10 weeks), but you do this for every customer.
• Open Epic / public FHIR APIs — read-only, patient-facing FHIR. No formal Epic review at all — just the technical work. Very fast (2-4 weeks), but functionally limited.

Scoping the integration path is the first decision. Picking wrong is expensive — we've seen teams build to App Orchard requirements when they only needed direct integration, doubling their timeline.

What Epic actually reviews

Across our nine submissions, Epic's review focused on four things, in roughly this order:

Data flow and trust boundaries. They want a diagram showing what data leaves Epic, where it goes, how long it's retained, and who has access. This is the foundation of everything else.

Authentication and authorization. Are you using SMART on FHIR correctly? Do scopes match what your app actually does? If your app requests patient/*.read scope but only displays one field, that's a finding.

Performance characteristics. Epic instances are shared infrastructure. They care that your app doesn't hammer their FHIR endpoints. Expect to document expected request rates, retry behavior, and cache strategy.

Failure modes. What happens when Epic is slow? When a call returns 500? When a token expires mid-session? They want to see graceful degradation, not crashes.

Security review prep

Security review runs in parallel to functional review and often takes longer. Things to have ready before you start:

• Threat model document. STRIDE or LINDDUN, your choice. They want to see you've thought about misuse.
• Data flow diagram, with trust boundaries labeled.
• Inventory of all third-party services your app uses (cloud providers, analytics, error tracking — yes, everything).
• Encryption strategy: at-rest, in-transit, and key management. Customer-managed keys preferred.
• Incident response plan with named contacts and SLAs.
• Penetration test results from the last 12 months. If you don't have one, schedule it before you submit.
• SOC 2 attestation or equivalent (HITRUST, ISO 27001). Not strictly required for all paths, but expedites review.

Teams that show up without these inevitably go into a back-and-forth cycle that extends the timeline by 4-8 weeks. Teams that show up with these typically clear security review in 3-4 weeks.

The technical artifacts you need

Beyond the security pack, Epic wants specific technical artifacts:

• OAuth flow diagram showing the SMART on FHIR launch sequence end-to-end.
• CapabilityStatement of the FHIR resources you read or write, with the specific search parameters you use.
• List of scopes requested and exactly which features use which scopes (minimum-scope principle).
• Sample requests and responses for each operation, including error cases.
• App manifest with launch URIs, redirect URIs, and post-logout URIs.
• Test plan showing how you tested against Epic's sandbox before submission.

What slows the review down

From our submissions, the consistent slowdowns:

• Over-scoping. Requesting more SMART scopes than your app uses. Epic asks you to justify each — and if you can't, you go back and refactor.
• Slow responses to questions. Epic's reviewers ask questions in batches. A 48-hour response cycle extends a typical review by 3-4 weeks vs same-day responses.
• Missing failure-mode handling. "What happens if Epic returns 503?" If you can't show the answer in code and tests, expect a back-and-forth.
• Third-party service surprises. Forgetting to disclose that your app sends data to a logging service or analytics tool. Discover this in review and you go back to security.
• Customer-side delays. For direct integrations, the customer's IT team owns half the review. If they're slow to schedule meetings, you're slow to ship.

Tips from nine prior submissions

First: pick a launch customer who has done this before. Their familiarity with the process compresses the timeline by weeks. We've shipped first integrations to launch customers with prior Epic experience in 5-6 weeks; first-time launch customers typically run 10-12.

Second: schedule the security review before you submit. Don't wait for Epic to ask. Get the pen test scheduled, the SOC 2 evidence collected, the threat model drafted — and submit them with the initial package, not in response to questions.

Third: build to the Epic sandbox first, then to production. Their sandbox isn't perfect, but it surfaces 80% of integration issues. Teams that test only against production hit those issues during review, not before.

Fourth: name a named submission lead on your side. Epic reviewers prefer to talk to one person, not rotate through engineers. Designate the same person to answer all questions for the duration.

The timeline to plan for

Realistic timelines from kickoff to live in Epic:

• Direct integration, customer has Epic experience: 6-8 weeks
• Direct integration, first-time customer: 10-14 weeks
• App Orchard / Connection Hub, prepared team: 12-16 weeks
• App Orchard / Connection Hub, first-timer: 16-22 weeks

If your stakeholders are quoting timelines below these, they haven't done it before. Push back. The way you save time isn't by shortcutting review — it's by being prepared enough that you only go through it once.