Learn

Stuck on Epic integration: the deal after the demo

If your Epic integration stalled after a good demo, the code is rarely what is holding it up. The demo ran in a sandbox. Production means one specific hospital has a sponsor who requests your app, clears you through its security review, signs a BAA, and provisions you in its own Epic instance. A Showroom listing does none of that. The deal moves again when someone owns the compliance stack behind it: your team, or a compliant SMART on FHIR runtime.

Federated access is not go-live

Epic has no central production endpoint. Each hospital runs its own Epic instance with its own FHIR base URL, credentials, security team, and change windows. So Epic integration is one build plus a separate approval at every site. A yes from one hospital, or from Epic, does not switch you on anywhere else.

Teams scope the integration as an engineering task, estimate it about right, and then wait on a process that sits entirely inside the customer. The hospital that loved the demo still has to find a sponsor, route you through security and legal, and schedule IT work around its own release calendar.

Security review and the BAA are usually the long pole

After the demo, the hospital's security team sends a vendor questionnaire and asks for evidence: a SOC 2 Type II report, where PHI is hosted, and how data is encrypted in flight. Legal starts on the BAA in parallel. If your HIPAA hosting and evidence do not exist yet, you are building them while the deal waits.

The hard part is having real answers. "We are working on SOC 2" or "we host on a general cloud account" turns into follow-up rounds, and each round costs calendar time you do not control. This does not happen once per company. It happens at every hospital, with a new questionnaire and a new legal team each time.

A Showroom listing is not production

Epic Showroom is the catalog where Epic-using hospitals discover and request third-party apps. A listing makes your app requestable. It does not host the app, sign a BAA, complete any hospital's security review, or put you live anywhere. You can go live with a customer before you are listed, and you can be listed without being live.

A listing is still useful. For multi-hospital distribution it is usually on the path, because hospitals that will not hand-walk a new vendor relationship expect to find you there. The mistake is treating listing approval as the finish line. The listing points at something that has to actually run under HIPAA, with a BAA and evidence a security team will accept. For how listing and runtime differ as buys, see Epic Showroom vs a SMART on FHIR runtime.

A sandbox is not a hospital deployment

The sandbox proves your SMART on FHIR launch works against Epic's test data. A hospital deployment runs inside that hospital's own Epic instance, with a production client ID it issues, a real FHIR base URL, real PHI, and the hosting and BAA that PHI requires. Passing the demo gets you a buyer, not production access.

The gap shows up in small ways first. Scopes that were fine in testing get questioned by the hospital's reviewers. Write-back behavior that worked against test patients needs sign-off from people who were not in the demo. The launch URL and redirect URIs need to live on HIPAA-eligible hosting, not on a developer account. All of it has to be true before the hospital turns you on.

Honest timelines are ranges, not an Epic SLA

Epic integration timelines are ranges. For Showroom, intake typically runs weeks 1–3 and Epic's review commonly runs weeks 2–8. The hospital's security review, BAA, and IT provisioning run on that hospital's calendar, and no vendor controls them. Anyone quoting a single number is describing one stage, not go-live.

If you see a Day 1 / Week 2 / Week 3+ sequence, read it as best case:

Day 1: working SMART launch in Epic.
Week 2: Showroom submission filed.
Week 3+: live at the hospital, once that hospital's security review and BAA clear.

Week 2 describes how fast a submission packet can be filed. It is not an Epic listing date, and Epic does not commit to one. The outer bound is Epic's queue plus the hospital's own review and BAA. For the full sequence, see how to get your app into Epic, and for why the calendar behaves this way, why Epic integration takes so long.

How SoFaaS™ unblocks each stall

SoFaaS™ is a compliant SMART on FHIR runtime. Your app runs on it inside Epic, so the stack a hospital asks about already exists: HIPAA hosting, a BAA, a SOC 2 Type II evidence packet, Showroom submission packaging, and maintenance through Epic's quarterly changes. The hospital still runs its own review. You answer it instead of building toward it.

Mapped to the stalls above:

Security questionnaire: SoFaaS™ is SOC 2 Type II audited, and the evidence packet is ready to share with the hospital's security team. Production PHI stays in U.S. regions, and all in-flight traffic is TLS 1.2 or higher.
BAA: a Business Associate Agreement is in place with every hospital deployment, so legal reviews an existing agreement instead of drafting one.
Hosting: the app runs on a HIPAA-compliant hosted runtime instead of infrastructure you have to build and defend.
Showroom: SoFaaS™ packages and files the submission. Epic owns the listing queue.
After go-live: SoFaaS™ maintains the integration through Epic's quarterly changes, so the next hospital reuses the same posture.

What it cannot do: find your sponsor, speed up a hospital's IT queue, or shorten Epic's review. You still own your application code, your employee access policies, and the contract with your hospital customer. Full detail is on the security page.

What each step gives you, and what it does not

Step	What it gives you	What it does not
Demo / sandbox	Proof the app launches with SMART on FHIR and works against test data, plus a buyer who wants it.	Production credentials, a hospital FHIR base URL, a BAA, or security sign-off.
Sponsor download	A named person at one hospital who requests your app for their Epic instance and starts that site's process.	Security clearance, a signed BAA, IT provisioning, or access at any other hospital.
Security review / BAA	Clearance to handle PHI at that hospital, and the contract that covers it.	Clearance at the next hospital. Each site runs its own review and legal cycle.
Showroom listing	Discoverability. Epic-using hospitals can find and request the app.	Hosting, a BAA, a security review, or go-live at any site.
Compliant SMART runtime (SoFaaS™)	HIPAA hosting with a BAA, a SOC 2 Type II evidence packet, U.S. residency for production PHI, TLS 1.2 or higher, Showroom submission packaging, and quarterly Epic-change maintenance.	The hospital's sponsor, its IT queue, or Epic's review calendar. It is not a listing and not a data-translation layer.
Redox (data translation; compose with it)	Movement and translation of clinical data between systems, such as HL7 v2 feeds and other EHRs.	A clinician SMART launch runtime, hosting for your in-chart app, or a Showroom listing. Use it alongside a runtime, not instead of one.

Non-goals

Stated plainly, so nobody buys the wrong thing:

Not a public website host. Your marketing site is a different job.
Not a server-to-server FHIR consumer. Headless, no-user-launch integrations are a different SMART pattern.
Not a Redox replacement. Compose with Redox or 1upHealth for data flows outside the SMART launch path.
Not hospital logistics. Patient transport and logistics is vectorcare.com.
Not clinician licensing. That is Trust.

FAQ

Why is my Epic integration taking so long?

Usually because the work left is access, not code. Epic is federated, so each hospital runs its own security review, BAA, and IT provisioning on its own calendar. If you are building HIPAA hosting and a SOC 2 Type II evidence packet while that review is open, the deal waits on both.

Does a Showroom listing mean I'm live?

No. A Showroom listing means Epic-using hospitals can find and request your app. Going live at a given hospital still needs that site's security review, a BAA, and IT provisioning. Epic review commonly takes weeks 2–8 after intake, and even an approved listing is a catalog entry, not a deployment.

Do I need a BAA to launch in Epic?

For a clinician-facing app that handles PHI at a hospital, plan on it. The hospital will expect a business associate agreement that covers your processing before production. You can negotiate your own with each hospital, or run on a compliant runtime that already has a BAA in place for hospital deployments.

Can I go live from the sandbox?

No. The sandbox proves your SMART on FHIR launch works against test data. Production happens inside each hospital's own Epic instance, with a production client ID and FHIR base URL that hospital issues after its security review and BAA clear. The sandbox is where the build starts, not where the deal closes.

Does a SMART on FHIR runtime replace Redox?

No. Redox translates and moves clinical data between systems, such as HL7 v2 feeds and other EHRs. A compliant SMART on FHIR runtime runs your clinician-facing app inside Epic under HIPAA and a BAA. They do different jobs, and many vendors use both. Compose them rather than choosing one.

Have a deal stuck on Epic?

If an Epic deal stalled after the demo on security review, the BAA, or hosting, start here.

Talk to us