Epic Showroom, Connection Hub, and Epic Vendor Services: What Replaced App Orchard and How Third-Party FHIR Apps Integrate

Digital health engineers, clinical trial software architects, and hospital informatics teams searching for Epic Showroom, Epic Vendor Services, or Epic App Orchard need to navigate Epic Systems’ restructured third-party interoperability ecosystem. To separate developer engineering support from its public customer-facing directory, Epic Systems retired the legacy App Orchard brand and divided its functions across three portals: open.epic / fhir.epic.com (free public API standards and sandbox registration), Epic Vendor Services (tiered technical support and advanced testing), and Epic Showroom (including Connection Hub, the public directory of live-validated integrations).

What Replaced the Epic App Orchard Developer Program?

Historically, What is Epic App Orchard referred to Epic’s single combined marketplace and developer program launched to support SMART on FHIR and proprietary web-service integrations. Because health system chief information officers needed to distinguish between developmental sandbox apps and software already proven in live hospital production, Epic retired the App Orchard name and split the ecosystem into distinct functional layers:

• open.epic (fhir.epic.com): The free, self-service developer portal where any researcher, health system developer, or commercial vendor can create an account, read HL7 FHIR Release 4 (R4) and CDS Hooks documentation, register applications to obtain non-production and production Client IDs, and test against Epic’s public sandbox without upfront membership fees.
• Epic Vendor Services (vendorservices.epic.com): The optional paid developer membership and technical support program that replaced the developer-tooling side of App Orchard. Vendor Services provides dedicated Epic sandbox instances, extended HL7 v2 / X12 and private API documentation, architecture design consultations, and developer workshop access.
• Epic Showroom (showroom.epic.com) & Connection Hub: The public-facing directory that replaced the marketplace gallery side of App Orchard, allowing Epic health systems to browse third-party software, medical devices, and diagnostic partners that have verified live production integrations at one or more Epic customer sites.

What Is the Difference Between Epic Vendor Services, Connection Hub, and Epic Showroom?

When planning an Epic EHR integration, teams encounter three distinct program names plus specialized Showroom categories:

Platform / Program	Primary Audience	Core Function & Listing Prerequisite
open.epic (fhir.epic.com)	Software engineers, academic researchers, app developers	Free API specifications, OAuth 2.0 / SMART on FHIR app registration, sandbox testing, and production Client ID generation. Required for all FHIR integrations.
Epic Vendor Services	Commercial software and medical device vendors	Annual paid developer support program offering dedicated test environments, technical support tickets, and access to expanded APIs beyond public USCDI FHIR endpoints.
Epic Showroom	Health system CIOs, CMIOs, and procurement teams	The umbrella public directory at showroom.epic.com organizing third-party partner solutions across clinical, patient engagement, CRM, and diagnostic categories.
Connection Hub (within Showroom)	Health systems evaluating third-party software apps	The specific Showroom catalog tier for clinical, operational, and patient-facing software integrations. Requires at least one verified live production deployment at an Epic customer site.
Aura & Cheers (within Showroom)	Diagnostic labs, device makers, and patient access teams	Specialized Showroom tracks for specialty diagnostic laboratories/devices (Epic Aura) and customer relationship management / call-center integrations (Epic Cheers).

What Are the Technical Steps to Integrate a Third-Party Application with Epic EHR?

A critical architectural principle for anyone learning how to integrate with Epic is that third-party clinical or provider-facing applications do not turn on “globally” across all Epic hospitals at once. While patient-facing consumer apps using USCDI FHIR APIs can dynamically connect via patient portal credentials (Epic MyChart), clinician-facing and backend enterprise integrations follow a five-step deployment lifecycle:

Step 1: Register on open.epic and Select the Authentication Architecture

Create a free developer account at fhir.epic.com and register the application under one of three primary OAuth 2.0 / FHIR integration patterns:

• Clinician-Facing SMART on FHIR (EHR Launch): Launched as an embedded iframe or external tab inside the clinician’s Hyperspace or web-based Hyperdrive workspace. Uses OAuth 2.0 authorization code flow with PKCE and receives launch context tokens (such as current patient, encounter, and fhirUser).
• Patient-Facing SMART on FHIR (Standalone Launch): Authenticates patients via their MyChart credentials to read US Core / USCDI clinical data or submit patient-reported outcomes (PROs) and Apple HealthKit / device telemetry (historically bridged via Epic Kit / MyChart mobile device integration).
• Backend System-to-System Services: Headless background integrations (such as clinical trial eligibility screening, ambient AI scribes, or revenue-cycle automation) that authenticate without user interaction using Backend OAuth 2.0 JWT Bearer Tokens signed with an asymmetric X.509 public/private key pair registered on open.epic.

Step 2: Build and Validate Against the FHIR R4 Sandbox

Develop against Epic’s HL7 FHIR R4 endpoints (including Patient, Encounter, Condition, Observation, MedicationRequest, DocumentReference, and ServiceRequest) and CDS Hooks specifications. Validate token exchange, scope minimization, and error handling against Epic’s public sandbox test harnesses or a dedicated Vendor Services virtual environment.

Step 3: Mark Application Ready for Production and Synchronize Client IDs

Once technical testing is complete, upload the production JSON Web Key Set (JWKS) URL or public certificate, define the exact FHIR resource scopes required, and mark the application “Ready for Production” on open.epic. Epic’s directory automatically distributes the application’s production Client ID metadata to customer health systems’ local Epic environments within 24 hours.

Step 4: Health System Customer Sponsorship and Interconnect Configuration

For clinician-facing or backend apps, the vendor must contract with a sponsoring Epic health system customer. The health system’s internal Epic analyst and Epic Interconnect team enable the application’s Client ID in their non-production (TST / SUP) environment, map internal security points (EMP / SER records), configure Hyperspace/Hyperdrive launch activities or incoming API rules, and conduct institutional InfoSec and HIPAA review before cutting over to production (PRD).

Step 5: Live Customer Attestation and Epic Showroom Listing

After the integration is live in production at an Epic health system customer, the vendor can apply through Epic Vendor Services to publish a verified product listing in Epic Showroom (Connection Hub), making the pre-configured integration discoverable to other Epic hospital systems.

Ambient AI and Foundation Model Integrations in the Epic Ecosystem

Recent searches for OpenAI Epic EHR integration healthcare and Epic EHR integration partners reflect two distinct pathways by which generative AI enters Epic workflows:

• Native Cloud AI via Microsoft Azure and Epic Nebula: Through Epic’s strategic partnership with Microsoft, health systems deploy Azure OpenAI Service models natively inside Epic workflows (such as drafting MyChart in-basket message replies, summarizing longitudinal chart histories prior to rounds, and extracting social determinants of health) executed via Epic’s cloud infrastructure.
• Third-Party Ambient and Clinical AI via Showroom / FHIR: Independent ambient documentation and clinical decision support platforms integrate via SMART on FHIR, FHIR R4 DocumentReference write-backs, and Epic’s Ambient Module APIs listed in Epic Showroom.