Getting an application connected to Epic is a sequence, not a single approval. You register and develop against Epic's public documentation and sandbox, implement SMART on FHIR with OAuth 2.0 authorization, satisfy Epic's developer terms and data-handling conditions, and then complete a customer-side security and workflow review before a live connection is enabled. The gate that most often delays teams is not FHIR conformance — it is security evidence and named clinical workflow ownership at the health system.
The stages, in the order they actually happen
Teams commonly assume the milestone is a listing. In practice the listing is late in the process, and each earlier stage can stall for weeks if the prerequisite artifacts are not ready.
- Register as a developer and build against Epic's public documentation and sandbox environment.
- Implement SMART on FHIR launch and OAuth 2.0 authorization, including scope handling and token lifecycle.
- Align to the resources and profiles Epic exposes, and design for the fields that are actually populated rather than the full specification.
- Accept and comply with Epic's developer terms, including data collection and handling conditions.
- Complete the customer health system's security review and workflow validation before a production connection is enabled.
FHIR conformance is rarely the blocker
The standardized API certification criterion at §170.315(g)(10) means the read paths you need are broadly available across certified EHRs, and Epic publishes its API surface openly. What differs by customer is which fields are reliably populated, how the organization configures the workflow you want to launch from, and who owns the clinical decision to place your app in front of users.
Design your product so a missing optional element degrades gracefully. An integration that requires a field your customer does not capture will pass a sandbox test and fail a pilot.
Prepare the security evidence before the deal, not during it
Health system reviews ask for hosting and data-flow documentation, access control and logging design, incident response, vulnerability management, subprocessor lists, and a signed business associate agreement. Assemble these once, keep them current, and treat them as a product asset. Epic's developer terms also carry data collection and handling requirements tied to certification conditions, so your data practices need to hold up to that reading and not just to your own privacy policy.
- Data-flow diagram showing every location PHI is stored, processed, or transmitted.
- Access control, audit logging, and retention design, described in operational terms.
- Vulnerability management and penetration test cadence with dates.
- Business associate agreement and subprocessor inventory ready for review.
Name the workflow owner on the customer side
A live connection needs a clinical or operational owner who will decide where the app appears, which users see it, and what happens when it is unavailable. Where that owner is unnamed, projects reach technical readiness and then wait. Ask for the owner in the first integration call and confirm the launch context, user population, and downtime behavior in writing.
How BlockInterop supports this work
- EHR and Epic Integration consulting and implementation — Develop secure, reusable EHR integration models that support clinical workflows, application launches, data exchange, and enterprise deployment.
- Testing and Implementation Support consulting and implementation — Support interface validation, workflow testing, deployment readiness, issue resolution, and production optimization.
Sources
Every figure cited in this article links to its public source. BlockInterop publishes no client names, outcomes, or internal performance statistics.