What is the Epic Showroom?

From App Orchard to Showroom

Epic launched the App Orchard program in the mid-2010s to give third-party developers a structured way to integrate with Epic's EHR. Vendors enrolled, paid a program fee, built to Epic's API specs, got listed in a directory hospitals could browse. It worked, broadly, but the program accumulated friction over time — high fees for small vendors, an opaque review queue, and a brand that didn't quite match Epic's evolving go-to-market posture.

In recent years, Epic restructured and rebranded the program as Epic Showroom. The mechanics didn't change in spirit — vendors still enroll, build to Epic's SMART on FHIR specs, and get listed for Epic-using hospitals to discover. But the program structure was tightened, the catalog presentation was modernized, and the language around it shifted from "marketplace" to something closer to "vetted vendor showcase."

On the VectorCare site, and in any documentation written after the rename, you'll see "Epic Showroom" everywhere because that's the current correct name. Older docs and case studies still say "App Orchard." They're talking about the same program.

What Showroom actually does

Showroom does four useful things for a third-party vendor:

• A discoverable listing. Your app shows up in a catalog Epic-using hospitals can browse. They can see what your app does, what FHIR resources it touches, what scopes it requests, and how to request a deployment.
• A vendor agreement with Epic. You're enrolled in a defined program with terms — what you can build, how you handle PHI, what happens if you violate the agreement, what fees apply.
• Standardized deployment requests. When a hospital wants to evaluate your app, the request flows through Showroom's intake. The hospital gets a consistent experience; you get a sales surface that doesn't depend on you knowing every Epic admin in the country.
• Sandbox + integration documentation. Epic provides a sandbox you can build against and reference docs for the FHIR endpoints your app will call.

What Showroom doesn't do

This is where most vendors get tripped up. Showroom is distribution. It is not a runtime, not a hosting platform, not a compliance program. Specifically:

• It doesn't host or run your app. You still need a HIPAA-compliant hosting environment.
• It doesn't make you HIPAA-compliant. You still need a BAA with each hospital, a documented data-handling posture, and an audit trail their compliance team will accept.
• It doesn't give you a SOC 2 report. Every hospital security team will ask for SOC 2 Type II. Showroom doesn't substitute.
• It doesn't replace per-hospital security review. Each hospital that wants to deploy you runs their own review. The listing makes you requestable; the review decides whether they actually deploy.
• It doesn't maintain your integration. When Epic ships breaking changes — typically each quarter — you're responsible for keeping your integration working.

How submission actually goes

At a realistic pace, here's what the timeline looks like for a vendor going through Showroom submission for the first time:

• Week 1. Kickoff. Collect app metadata, technical spec, security documentation, sandbox access, demo video.
• Weeks 1–3. File the submission. Epic's intake team usually responds within a couple of weeks.
• Weeks 2–8. Epic reviews. Expect at least one round of clarifying questions. Each round adds a few weeks.
• Listing live. Once approved, your app is live in Showroom and requestable by any Epic-using hospital.

The single biggest accelerant on this timeline is having the security packet pre-built and the technical spec written in the format Epic expects. Vendors who treat submission as a one-off engineering project tend to add weeks per round. Vendors with a runtime that already produces these artifacts on demand tend to clear the queue faster.

After your app is listed

Listing isn't the end of the journey — it's the beginning of the deployment cycle. Every hospital that wants to deploy you goes through their own loop: discover from Showroom, evaluate clinically, sign a BAA, run a security review, provision the app inside their Epic instance. Each loop is its own project. The faster you can clear it, the more hospitals you reach in a quarter.

Internal-build vendors tend to scale this loop linearly with their compliance team's capacity. Vendors on a runtime like SoFaaS™ scale it with the runtime's deployment configuration — adding a hospital is a config step, not another integration project. Same code, same review packet, faster review.