Epic Integration:
Bridges, App Orchard, and SMART on FHIR

Epic is the dominant inpatient EHR in the United States — more than 250 million patient records live in Epic customer instances, and any healthtech company selling into US hospitals will eventually have to integrate with it. The "how" of that integration has changed significantly in the last three years: App Orchard became Showroom, the FHIR R4 surface has broadened, EHI Export is now a live ONC requirement, and SMART on FHIR has become the default for new third-party applications.

This guide is a field-tested walkthrough of what actually happens when you integrate with Epic — the components you'll touch, the programs you'll enroll in, the timelines you should plan for, and the mistakes to avoid. It's written for integration engineers, product managers, and implementation leads who have heard the acronyms but want the real picture.

If you're scoping or mid-build on an Epic project, our Epic EHR integration services cover architecture, Showroom paperwork, HL7 v2 Bridges design, and SMART on FHIR build — and we staff jointly with the customer's Epic TIE so the handoffs don't stall.

1. The Epic Integration Stack in 2026

Epic integration isn't one thing — it's a layered stack of messaging, web services, applications, and governance programs. Understanding which layer your use case lands in is the first step.

The primary layers:

• Epic Bridges — HL7 v2 interfaces. The plumbing for ADT, ORM, ORU, SIU, MDM, DFT, and other traditional hospital messages. Runs over MLLP (often MLLPS).
• Interconnect — Epic's web-services engine. Hosts the FHIR R4 API, SMART on FHIR OAuth, and legacy proprietary APIs.
• App Orchard / Showroom — the marketplace and vendor program for third-party applications built on Epic's web services.
• MyChart — the patient-facing web/mobile portal. Patient-scoped SMART on FHIR apps launch from or alongside MyChart.
• EpicCare / Hyperspace — the provider-facing clinician UIs where EHR-launch SMART on FHIR apps appear.
• Care Everywhere — cross-organization document exchange over IHE XCA/XCPD, plus Carequality and TEFCA bridges.
• Cogito / Clarity / Caboodle — Epic's analytics stack. Data extracts, batch integrations, and BI land here. Not typically the surface for real-time integrations but relevant for data-warehouse use cases.

You'll often need multiple layers at once. A medication adherence app might read medications from the FHIR API (Interconnect), receive ADT events via Bridges (HL7 v2) to track admissions, and publish a CDS Hook back into EpicCare when an intervention is needed.

For the broader landscape see our EHR integration guide and healthcare interoperability guide.

2. Bridges — HL7 v2 Interfaces Up Close

Bridges is Epic's name for the HL7 v2 interface layer. Despite two decades of "FHIR is coming" chatter, the vast majority of real-time clinical data movement between Epic and ancillary systems — labs, radiology, scheduling, pharmacy, EMPIs, billing — still happens over HL7 v2 via Bridges. Understanding Bridges is still essential.

What Bridges actually is

Bridges is an Epic-managed set of MLLP endpoints and message specifications. For every interface, an Epic TIE (Technical Implementation Engineer) works with the vendor or ancillary system to:

• Agree on the trigger events (e.g., ADT A01, A03, A08; ORU R01; ORM O01; SIU S12, S14, S15).
• Define the message structure — segments, fields, Z-segments, code systems.
• Establish the transport — MLLP port, TLS posture, keepalive behavior, ACK expectations.
• Build and test the interface in Epic's non-production environment (POC, then TST/VAL).
• Promote to production during a scheduled cutover.

A typical Bridges ADT message

MSH|^~\&|EPIC|HOSPITAL|LIS|LAB|20260421093000||ADT^A08|MSG00123|P|2.5.1
EVN|A08|20260421093000
PID|1||MRN1234567^^^EPIC^MR||DOE^JANE^A||19850415|F|||123 MAIN ST^^BOSTON^MA^02118
PV1|1|I|MED3^301^A^HOSP|EL|||1234^SMITH^JOHN^MD|||MED||||7|||1234^SMITH^JOHN^MD|INP|VN987654|SELF
DG1|1|ICD-10-CM|I10|Essential hypertension|20260421|A

Bridges message patterns we see constantly

• ADT (Admit/Discharge/Transfer) — patient demographic and visit events. The backbone of almost every hospital integration.
• ORM / OML — order messages (radiology, lab orders, etc.).
• ORU — observation results (lab results, radiology reports).
• SIU — scheduling events.
• DFT — detail financial transactions (charges).
• MDM — medical document management (notes, transcribed documents).
• VXU — vaccination history updates, often to state IIS registries.

MLLPS — the transport

Bridges interfaces in 2026 almost always run over MLLPS (MLLP over TLS 1.2+). The sender wraps each HL7 message in <VT>...<FS><CR> framing and pushes it over a long-lived TLS-encrypted TCP socket. The receiver ACKs with an MSA segment wrapped in the same framing. If you're terminating Bridges on the vendor side, see our troubleshooting guide for MLLP connection refused errors and our HL7 integration guide.

3. App Orchard → Showroom Rebrand

For about a decade, Epic's marketplace for third-party applications was called App Orchard. In 2024, Epic rebranded it to Showroom. The program is structurally similar, but the branding, portal URL, and some tier names have changed. Older docs still say App Orchard; the current name is Showroom.

Why Showroom exists

Epic customers (hospitals) don't want to individually vet every third-party app, manage OAuth clients, or negotiate security and data-use terms. Showroom is the layer that handles this centrally:

• Epic reviews the vendor's security posture, business use case, and technical design.
• Approved apps list in the Showroom catalog, visible to Epic customers.
• Customers "subscribe" to an app, which provisions OAuth clients and configures access scopes on their Interconnect instance.
• Vendors pay an annual program fee plus per-customer licensing arrangements.

Showroom tiers (as of 2026)

The tier structure determines what APIs, what write access, and what sandbox depth you have. Lower tiers suit read-only apps with public-listed scopes; higher tiers support write-back and proprietary APIs. Specific tier names evolve — the current Showroom portal is the source of truth, and an Epic Showroom coordinator will guide new vendors through tier selection.

The Showroom application path

1. Express interest via the Showroom portal; complete preliminary questionnaire on use case and architecture.
2. Sign NDAs and program agreements; pay the tier's annual fee.
3. Receive sandbox access (fhir.epic.com) and begin building.
4. Submit the app for security review (SOC 2 or equivalent typically required).
5. Complete the listing — screenshots, documentation, pricing, support model.
6. Listing goes live; Epic customers can discover and subscribe.

Plan 4–6 months from "we want to list" to an active Showroom listing. Plan another 2–4 months per customer go-live once subscribed.

4. SMART on FHIR and OAuth 2.0

SMART on FHIR is the open standard Epic (and every major EHR) implements for third-party app launch and OAuth-based API access. It defines how apps discover endpoints, authenticate, obtain scoped access tokens, and call FHIR APIs with that access.

Launch contexts

• EHR launch — an Epic user clicks a button inside EpicCare/Hyperspace; Epic opens the third-party app with a launch token that identifies the current patient and encounter.
• Standalone launch — the user goes to the third-party app directly, which redirects them to the Epic OAuth endpoint for authorization.
• Backend services — no user involved; a backend service authenticates with a signed JWT (asymmetric client authentication) and gets a token for bulk/population APIs.

SMART configuration discovery

The .well-known/smart-configurationendpoint is where you discover a specific customer's Interconnect endpoints:

GET https://apporchard.epic.com/interconnect-aocurprd-oauth/api/FHIR/R4/.well-known/smart-configuration

{
  "authorization_endpoint": "https://apporchard.epic.com/interconnect-aocurprd-oauth/oauth2/authorize",
  "token_endpoint": "https://apporchard.epic.com/interconnect-aocurprd-oauth/oauth2/token",
  "token_endpoint_auth_methods_supported": [
    "client_secret_post",
    "private_key_jwt"
  ],
  "scopes_supported": [
    "launch",
    "launch/patient",
    "patient/*.read",
    "user/*.read",
    "system/*.read",
    "offline_access",
    "openid",
    "fhirUser"
  ],
  "response_types_supported": ["code"],
  "capabilities": [
    "launch-ehr",
    "launch-standalone",
    "client-public",
    "client-confidential-symmetric",
    "client-confidential-asymmetric",
    "sso-openid-connect",
    "permission-patient",
    "permission-user"
  ]
}

A typical EHR-launch flow

# 1. Epic launches your app with a launch token in the URL:
https://app.example.com/launch?iss=https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/R4&launch=abc123

# 2. Your app discovers endpoints from iss/.well-known/smart-configuration

# 3. Your app redirects the user's browser to the authorize endpoint:
GET https://apporchard.epic.com/.../oauth2/authorize?
  response_type=code&
  client_id=YOUR_CLIENT_ID&
  redirect_uri=https://app.example.com/callback&
  scope=launch+openid+fhirUser+patient/Patient.read+patient/Observation.read&
  launch=abc123&
  state=RANDOM_STATE&
  aud=https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/R4

# 4. After Epic auth, user is redirected back to your callback with a code:
GET https://app.example.com/callback?code=AUTH_CODE&state=RANDOM_STATE

# 5. You exchange the code for an access token:
POST https://apporchard.epic.com/.../oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=AUTH_CODE&
redirect_uri=https://app.example.com/callback&
client_id=YOUR_CLIENT_ID

# Response includes access_token, patient (FHIR ID), encounter, scope, expires_in

Backend services with JWT client auth

For server-to-server integrations (no user present), Epic requires asymmetric client authentication — you register a public key with Epic and sign a JWT with your private key for every token request. Epic verifies the JWT and returns an access token scoped to system/* permissions. This is what Bulk Data ($export) flows use.

5. Epic's FHIR R4 API (Patient, Clinical, Bulk)

Epic's FHIR R4 API is hosted on Interconnect and is the primary surface for modern app integrations. Coverage has expanded substantially since 2021 but is not uniform across all Epic customers — older customer versions support a narrower surface.

Categories you'll use most:

• Patient API — demographics, identifiers, contact info, MRN lookups
• Appointment API — scheduling, slot search, booking, cancellation
• AllergyIntolerance, Condition, MedicationRequest, Observation — clinical read
• DocumentReference — notes, imaging reports, discharge summaries
• Encounter — admission, discharge, transfer history plus outpatient visits
• Flowsheet / Observation write — limited write-back from approved apps
• Bulk Data ($export) — population-level extracts for accountable-care and research
• CDS Hooks — clinical decision support injected into Epic workflows

A typical patient read

GET https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/R4/Patient/eXaMpLe-FHIR-ID
Authorization: Bearer ACCESS_TOKEN
Accept: application/fhir+json

HTTP/1.1 200 OK
Content-Type: application/fhir+json

{
  "resourceType": "Patient",
  "id": "eXaMpLe-FHIR-ID",
  "identifier": [
    { "system": "urn:oid:1.2.840.114350.1.13.123.1.7.5.737384.0", "value": "MRN1234567" }
  ],
  "name": [
    { "use": "official", "family": "Doe", "given": ["Jane", "A"] }
  ],
  "gender": "female",
  "birthDate": "1985-04-15",
  "address": [
    {
      "use": "home",
      "line": ["123 Main St"],
      "city": "Boston",
      "state": "MA",
      "postalCode": "02118"
    }
  ]
}

Bulk Data ($export)

The Bulk Data Access specification lets backend services request large ndjson exports of FHIR resources. Epic supports group-level and system-level exports (with customer permission):

GET https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/R4/Group/GROUP_ID/$export
Authorization: Bearer SYSTEM_ACCESS_TOKEN
Accept: application/fhir+json
Prefer: respond-async

HTTP/1.1 202 Accepted
Content-Location: https://fhir.epic.com/.../bulkdata/JOB_ID

# Poll Content-Location until status = complete, then download the ndjson files listed in the response:
GET https://fhir.epic.com/.../bulkdata/JOB_ID
{
  "transactionTime": "2026-04-21T09:30:00Z",
  "request": "...",
  "requiresAccessToken": true,
  "output": [
    { "type": "Patient", "url": "https://fhir.epic.com/.../Patient-1.ndjson" },
    { "type": "Observation", "url": "https://fhir.epic.com/.../Observation-1.ndjson" }
  ]
}

For the FHIR fundamentals see our FHIR integration guide.

6. EHI Export and ONC Compliance

Electronic Health Information (EHI) Export is a requirement of the ONC 21st Century Cures Act Final Rule — certified EHRs must be able to export the full EHI for a single patient or for the entire patient population, in a computable format, on patient request.

Epic implements EHI Export as:

• A FHIR R4 $export operation for data that maps to US Core FHIR resources.
• A proprietary supplemental format for data that doesn't cleanly map to FHIR yet (certain flowsheet rows, scanned images, etc.).
• A patient-facing request workflow from MyChart or the hospital's release-of-information process.

For third-party apps building around EHI Export — personal health records, care-coordination apps, record-transfer services — the primary API surface is FHIR $export combined with the supplemental format handling. Plan for the supplemental format to be a meaningful engineering effort; it's not just FHIR.

7. Care Everywhere and Cross-Organization Exchange

Care Everywhere is Epic's cross-organization HIE. It's how one Epic hospital sees a patient's records from another Epic hospital — and, via bridges, from non-Epic networks.

Technically:

• Runs over IHE XCA (Cross-Community Access) and XCPD (Cross-Community Patient Discovery).
• Moves CCDA documents, not raw FHIR resources — the "unit of exchange" is a structured summary document.
• Bridges to Carequality (a federated network of networks) and, increasingly, to TEFCA Qualified Health Information Networks (QHINs).
• Is configured at the customer level — vendors rarely interact with Care Everywhere directly.

If your integration needs cross-org data (e.g., pulling an outside hospital's records to populate a comprehensive patient view), work with the customer to surface Care Everywhere documents into an accessible location — often a FHIR DocumentReference or a local document repository that your app can query.

8. Interconnect — The Engine Behind Epic's APIs

Interconnect is Epic's web services engine. It's an internal component that hosts FHIR endpoints, SMART on FHIR OAuth, legacy proprietary APIs (EpicCare Link web services, Chronicles web services), and more. When you call a FHIR endpoint at an Epic customer, your request hits Interconnect, which translates it into calls against Epic's Caché/IRIS database and Chronicles data model.

Why it matters to integrators

• Endpoint availability varies. Different customers run different Interconnect versions; available endpoints and supported scopes aren't identical. Always discover via /.well-known/smart-configuration and /metadata.
• Rate limits are enforced. Interconnect throttles aggressive clients. Design for exponential backoff and respect 429 responses.
• Performance isn't uniform. Complex searches (e.g., broad Observation?patient=X&category=vital-signs&date=ge... with no narrowing) can be slow; use pagination and targeted filters.
• Versioning is per-customer. An Epic org upgrades to a new version on its own schedule. An API behavior that's identical on three customers may differ on a fourth running an older version.

A note on Kuiper: Epic previously promoted Kuiper as a next-generation data platform for population analytics. In 2024 Epic announced it was deprecating the Kuiper product line in favor of Cogito/Caboodle-based analytics and broader FHIR Bulk Data adoption. If older documentation references Kuiper, treat it as a historical note; don't architect new integrations against it.

9. Where Mirth Connect Fits Alongside Epic

Mirth Connect is not Epic and doesn't replace Epic's integration layers — it lives on the vendor side or the customer's ancillary side and handles everything that Epic's built-in layers don't.

Common Mirth + Epic deployment patterns

• Mirth terminates Bridges MLLP on the vendor side. Epic sends ADT/ORU over MLLPS to a Mirth listener; Mirth parses, normalizes, and persists to a vendor data store.
• Mirth bridges HL7 v2 to FHIR. Incoming HL7 v2 is transformed into FHIR resources and pushed to an internal FHIR server or downstream app.
• Mirth calls Epic FHIR APIs. Mirth HTTP Sender with OAuth plugin authenticates against Epic's token endpoint and makes FHIR calls, bringing data into Mirth's routing logic.
• Mirth fans out to multiple downstream systems. One inbound Epic feed → many outbound destinations (data warehouse, analytics, outbound vendor APIs, SFTP archives).
• Mirth acts as the fail-safe buffer. If a downstream system is down, Mirth queues messages and retries — Epic doesn't need to know or care about downstream availability.

Why this pattern is common

Epic customers generally don't want to build and operate custom message-handling infrastructure for every vendor they onboard. Neither does most vendor engineering — HL7 v2 parsing, ACK handling, message persistence, retry logic, and TLS are solved problems in a battle-tested integration engine. Mirth is the most common choice; it's open-source, widely supported, and has decades of production use. See our Mirth Connect guide and Mirth support and HL7 integration services.

10. Realistic Implementation Timelines

A medium-complexity Epic integration — FHIR read-and-write, plus HL7 v2 Bridges for event notifications — tends to land on this shape of timeline:

• ✓Weeks 0–2: Showroom listing review, security assessment, scoping meetings
• ✓Weeks 2–6: Sandbox access provisioned, OAuth client configured, first FHIR read
• ✓Weeks 6–14: Build out core read flows, map FHIR resources to internal model
• ✓Weeks 14–22: Bridges HL7 v2 interface design, TIE engineer sessions, test harness
• ✓Weeks 22–30: Customer-side testing environment, end-to-end validation
• ✓Weeks 30–36: Production cutover, monitoring, hypercare (go-live support)

Two-thirds of most Epic integration schedules is customer-side work — TIE scheduling, security review, environment provisioning, testing sign-off, go-live planning. Plan for this; aggressive engineering timelines that assume Epic and the customer will move at your pace almost always slip.

For a broader view on realistic costs and schedules, see our EHR integration cost guide 2026 and EHR integration project timeline.

11. Common Pitfalls We See Every Project

• Assuming every Epic org exposes the same FHIR endpoints — they don't; endpoint availability varies by version and by Interconnect configuration
• Expecting write access to clinical resources without a signed Showroom agreement and specific-scope approval
• Underestimating Epic-side TIE (Technical Implementation Engineer) lead times — 4–6 weeks is common, not exceptional
• Confusing the Sandbox FHIR endpoints (fhir.epic.com) with customer-specific endpoints discovered via /.well-known/smart-configuration
• Forgetting that App Orchard / Showroom has separate listings for provider-facing, patient-facing, and B2B apps with different review criteria
• Treating Epic's OAuth 2.0 as identical to standard OAuth — Epic uses asymmetric client authentication (JWT) for backend system access
• Building to the MyChart patient portal scope when you actually need the provider-facing EHR-launch scope (or vice versa)

For help avoiding these and picking a partner who has seen them, see how to choose an EHR integration partner.

12. Frequently Asked Questions

Related Reading

• EHR Integration: The Complete Guide
• HL7 Integration Guide
• FHIR Integration Guide
• Healthcare Interoperability Guide
• Mirth Connect: The Complete Guide
• Epic EHR Integration Services
• Cerner (Oracle Health) EHR Integration Services
• Cerner / Oracle Health Integration Deep-Dive
• athenahealth Integration Guide
• NextGen EHR Integration
• EHR Integration Cost Guide 2026
• EHR Integration Project Timeline
• How to Choose an EHR Integration Partner
• Mirth Connect Helpdesk