Is this page different from your general Epic integration services?

Yes, deliberately — this page covers FHIR-specific work through Epic's modern API layer and SMART on FHIR apps, while our general Epic integration services cover the broader HL7 v2 interface work most Epic sites still depend on daily.

Does every Epic site support the same FHIR resources?

Not necessarily identically — while Epic's FHIR API follows a consistent standard, each health system configures and approves connections individually, so available resources and activation timelines can vary somewhat between different Epic customer sites.

Can Epic's FHIR API handle high-volume, real-time event notifications?

Generally no, that's still HL7 v2's domain — FHIR's request-response model suits read-based data access and embedded applications better than the sub-second, continuous event triggering that ADT and similar workflows typically require.

How long does Epic App Market approval typically take?

This varies by application complexity and each health system's own review process, so there's no fixed universal timeline, though proper upfront scoping and sandbox testing generally shortens the overall approval and activation timeline.

Do I need a separate integration for every Epic health system I connect to?

Each health system approves and activates connections individually even for the same application, so yes, expect some per-site coordination, though a well-built FHIR integration reduces the technical rework needed for each new site.

Can Mirth Connect help bridge Epic's FHIR and HL7 v2 layers together?

Yes, Mirth Connect can transform between HL7 v2 and FHIR formats, making it a practical tool for projects needing to bridge Epic's real-time HL7 v2 event data with FHIR-based downstream applications or data stores.

Epic FHIR Integration Services via Mirth Connect

Epic FHIR Integration Services: Built Around Epic's Modern API Layer

Epic FHIR integration services on this page cover something specific: connecting applications to Epic through its FHIR R4 API, SMART on FHIR launch framework, and App Market listing process, distinct from the broader HL7 v2 interface work covered on our general Epic integration page. Epic's FHIR layer, delivered through its Interconnect server, supports read access to clinical data like patient demographics, observations, medications, and conditions, along with SMART on FHIR apps launching directly inside Hyperspace, Canto, or Haiku with patient context passed automatically.

Below is what Epic's FHIR API actually supports, how we approach a FHIR-specific integration project, and where FHIR fits alongside the HL7 v2 work most Epic sites still depend on. If you're scoping a FHIR-specific Epic project, our free Mirth Health Check can review your requirements directly — part of the Mirth Connect support work we do for US healthcare teams.

What Epic's FHIR API Actually Supports Today

Epic's FHIR R4 API, accessed through its Interconnect server, covers a defined set of clinical data access patterns rather than every possible Epic interaction, and understanding that scope upfront prevents scoping mistakes later in a project.

Read Access to Core Clinical Resources

Epic's FHIR API supports reading patient demographics, encounters, observations, medications, allergies, conditions, procedures, and lab and imaging results, covering the core clinical data most external applications actually need to consume.

SMART on FHIR Apps Launching Inside Epic

Apps built using the SMART on FHIR standard can launch directly inside Epic's own clinical workflow tools, with patient and user context passed automatically, giving clinicians an embedded experience rather than a separate disconnected application.

Limited Write-Back Where Epic Explicitly Permits It

Epic permits write-back for specific use cases like clinical notes through DocumentResource or draft orders for clinician review, though write access is considerably more restricted than read access across the FHIR API surface.

Per-Health-System Activation, Not a Single Universal Endpoint

Every Epic customer runs its own instance and approves outside connections individually, so a working integration is an agreement between your application, Epic's interface layer, and each specific health system, not a single universal endpoint.

How We Approach a FHIR-Specific Epic Integration Project

A FHIR-focused Epic project has its own distinct process, shaped by Epic's App Market listing requirements and the per-site activation model that governs how your application actually reaches production.

Scoping Exactly Which FHIR Resources You Need

We start by identifying precisely which FHIR resources your application actually requires, since requesting broader access than necessary complicates both Epic's review process and each health system's own approval decision later.

Navigating Epic's App Market and Showroom Listing

Getting an application discoverable and approved through Epic's own marketplace involves a defined technical and documentation process, which we help navigate so your application is positioned correctly for health systems evaluating it.

Building the SMART on FHIR OAuth Flow Correctly

SMART on FHIR authentication has its own specific OAuth 2.0 patterns and launch context handling that differ from generic REST API authentication, and getting this right the first time avoids rework during health system testing.

Testing Against Epic's Sandbox Before Any Live Site

We validate the integration against Epic's own sandbox environment before any real health system connection, catching issues in a safe testing environment rather than during an actual site's limited activation window.

Where FHIR Fits Alongside Epic's HL7 v2 Interfaces

Most Epic sites still rely heavily on HL7 v2 for real-time, event-driven workflows, and understanding where FHIR complements rather than replaces that existing interface layer matters for realistic project scoping.

HL7 v2 Still Handles Most Real-Time Event Workflows

Admission, discharge, and transfer notifications and other high-volume, sub-second event triggering still commonly run through HL7 v2 via Epic Interconnect, since FHIR's request-response model doesn't naturally fit that same real-time event pattern.

FHIR Excels at Read-Based, App-Launched Use Cases

FHIR's strength lies in read-based data access and embedded SMART on FHIR applications, making it the right choice for use cases like clinical decision support tools rather than high-volume, continuous event streaming.

Many Projects Genuinely Need Both Standards

A complete Epic integration project frequently uses HL7 v2 for event-driven workflows and FHIR for app-embedded, read-based access simultaneously, rather than treating the two standards as mutually exclusive choices for the same project.

We Scope Your Project to the Standard That Actually Fits

Rather than defaulting to FHIR because it's the newer standard, we scope each specific use case to whichever protocol, FHIR or HL7 v2, genuinely fits that particular workflow's actual technical requirements. See our general Epic EHR integration page for the broader HL7 v2 work.

Scoping a FHIR-specific Epic project?

Start with a free Mirth Health Check to review your requirements, send us the exact error if you're troubleshooting an existing integration, or check pricing for our support plans.