Epic FHIR and Interoperability: SMART on FHIR, Patient Access APIs, and the CMS Interoperability Rule
Epic FHIR implementation is simultaneously a regulatory compliance requirement, a technical integration challenge, and an organizational change management exercise – and most implementation teams underestimate all three. The CMS Interoperability and Patient Access Rule (CMS-9115-F) and the ONC 21st Century Cures Act rule mandate specific FHIR API capabilities and create penalties for information blocking. This article covers exactly what Epic exposes through FHIR R4, how SMART on FHIR authorization works, what the CMS Interoperability Rule requires and when, and what implementation teams consistently get wrong about all of it.
- What FHIR Is and Why It Matters for Epic
- Epic’s FHIR API Landscape: What Gets Exposed
- Key FHIR R4 Resources in the Epic Context
- SMART on FHIR: Authorization and App Launch
- The CMS Interoperability Rule: What It Requires and By When
- Information Blocking: The ONC Rule and What It Means Practically
- Payer-to-Provider and Provider-to-Payer FHIR APIs
- Testing Epic FHIR APIs: Tools and Validation Patterns
- Epic FHIR Implementation Pitfalls and How to Avoid Them
- Roles, Certifications, and Career Path
- Downloads
What FHIR Is and Why It Matters for Epic
HL7 FHIR (Fast Healthcare Interoperability Resources) is a standard published by Health Level Seven International that defines how health information is represented (as Resources) and exchanged (via RESTful APIs). FHIR R4, published in 2019, is the version required by CMS and ONC regulations and is the version Epic’s production APIs are built on as of 2026. FHIR is not an Epic-specific technology – it is an open standard that any EHR, payer system, or health application can implement. But Epic’s implementation of FHIR is the most widely deployed in US healthcare, making Epic’s specific FHIR behavior the de facto reference for most health system interoperability projects.
FHIR uses a RESTful API architecture. Every health data element is represented as a Resource – a Patient resource, a MedicationRequest resource, a Condition resource, an Encounter resource. Each resource has a defined JSON or XML structure, a canonical URL, and supports standard HTTP operations: GET to retrieve, POST to create, PUT to update. An application that wants a patient’s medication list sends a GET request to the MedicationRequest endpoint with the patient’s FHIR ID. The response is a JSON bundle containing all MedicationRequest resources for that patient.
FHIR matters for Epic implementations because it is the mechanism through which Epic exposes clinical data to external applications, patient-facing apps, payer systems, and other health systems. Every time a patient connects their health data to a third-party app (Apple Health, a personal health record), that data flows through Epic’s FHIR API. Every time a payer requests prior authorization status data from a health system, FHIR is the protocol. The broader Epic module context for understanding how clinical data is generated before it reaches FHIR is covered in the Epic EHR Learning Hub.
Epic’s FHIR API Landscape: What Gets Exposed
Epic exposes FHIR data through two primary API categories: the Patient Access API (patient-facing, requires patient authorization) and the System API (application-to-application, requires backend service credentials). A third category – Provider APIs – supports clinical app integrations launched within the Epic clinical context.
Patient Access API (Open.epic.com)
Epic’s Patient Access API allows patients to authorize third-party applications to access their health data using OAuth 2.0 / SMART on FHIR. When a patient installs a health app and connects it to their Epic-based health record, the app sends an authorization request to Epic’s FHIR authorization server. The patient authenticates via MyChart. Epic issues an access token scoped to the resources the app requested. The app uses that token to query patient data from Epic’s FHIR R4 endpoint.
Epic’s open.epic.com sandbox allows developers to test FHIR API calls against synthetic patient data without a production Epic connection. This is the starting point for any third-party application development team building against Epic’s FHIR APIs. The sandbox supports the same resource types and authorization flow as production, with the important caveat that synthetic data does not always reflect the full complexity of real patient records – edge cases in data completeness and coding that exist in production patient records do not appear in sandbox data.
System (Backend Service) API
The System API supports machine-to-machine data exchange without patient-level authorization – the application authenticates as a system rather than on behalf of an individual patient. This API is used for bulk data export (CMS’s $export operation for population-level data), payer-to-provider data exchange, and analytics platform integrations. System API access uses SMART Backend Services authorization – the client authenticates with a JSON Web Token (JWT) signed with a private key registered with Epic.
The distinction between Patient Access and System APIs matters significantly for data governance. Patient Access API calls are logged per-patient and are covered by individual patient authorization. System API calls are logged at the application level and require organizational-level data use agreements. The compliance obligations differ, and health system compliance and privacy officers must review and approve each API type separately. The analytics context for what FHIR exposes from Cogito reporting is described in the Epic Cogito Reporting and Analytics guide.
Key FHIR R4 Resources in the Epic Context
| FHIR Resource | Clinical Meaning | Epic Source System | Common Use Case |
|---|---|---|---|
| Patient | Patient demographics and identifiers | Prelude (registration) | Patient identity matching, app personalization |
| Encounter | Patient visits, admissions, ED encounters | Prelude / Grand Central | Care coordination, longitudinal care records |
| Condition | Diagnoses and problem list entries | ClinDoc / Ambulatory | Risk stratification, chronic disease management |
| MedicationRequest | Medication orders and prescriptions | Willow / CPOE | Medication reconciliation, formulary integration |
| Observation | Lab results, vital signs, assessments | Beaker / Nursing flowsheets | Lab trend tracking, remote patient monitoring |
| DiagnosticReport | Radiology reads, lab reports | Beaker / Radiology | Clinical decision support, image retrieval |
| Immunization | Vaccination records | Epic immunization module | Public health reporting, patient access to records |
| AllergyIntolerance | Documented allergies and reactions | ClinDoc / Ambulatory | Medication safety, care transitions |
| Procedure | Surgical and clinical procedures | OR / Ambulatory | Surgical history, prior auth documentation |
| CarePlan | Oncology treatment plans, care plans | Beacon / Ambulatory | Oncology platform integration, care coordination |
| Coverage | Insurance coverage information | Prelude (coverage records) | Prior authorization, eligibility verification, payer exchange |
Each FHIR resource maps to specific Epic source workflows. The Condition resource is populated from problem list entries and encounter diagnoses. The quality of FHIR data depends entirely on the quality of documentation in Epic’s clinical modules. A poorly coded problem list entry produces a low-quality Condition resource. This is why FHIR interoperability is partly a clinical documentation governance problem, not just a technical integration problem. The orders and documentation that feed FHIR resources are covered in the Epic EHR Orders and CPOE guide.
SMART on FHIR: Authorization and App Launch Framework
SMART on FHIR (Substitutable Medical Applications, Reusable Technologies) is the OAuth 2.0-based authorization framework that governs how external applications access FHIR data. SMART on FHIR defines the authorization flow, the scopes that apps can request, and the context information that gets passed when an app launches inside an EHR (like launching a clinical decision support app from within the Epic clinical interface).
SMART Authorization Flow for Patient-Facing Apps
The SMART patient-facing authorization flow works as follows. A patient opens a third-party health app and selects “Connect to Epic.” The app sends an authorization request to Epic’s authorization server with the app’s registered client ID and the FHIR scopes it is requesting (patient/Patient.read, patient/Observation.read, patient/MedicationRequest.read). Epic redirects the patient to MyChart for authentication. The patient logs in and consents to the requested scopes. Epic issues an authorization code. The app exchanges the code for an access token. The app uses the access token to make FHIR API calls for the patient’s data.
FHIR scopes define what data the app can access. The scope patient/Observation.read allows the app to read Observation resources (lab results, vitals) for the authenticated patient. The scope patient/*.read requests read access to all patient-facing resources. Apps should request only the scopes they need – over-requesting scopes is a HIPAA minimum necessary violation and will cause patient trust issues if the consent screen shows an overly broad access request.
EHR Launch: SMART Apps Inside Epic
SMART also defines an EHR Launch context where a clinical app launches from within the Epic interface with the current patient context automatically passed. A clinical decision support app embedded in Epic’s chart launcher receives the current patient’s FHIR ID, the current encounter ID, and the authenticated provider’s identity through the SMART launch context. This allows apps to retrieve patient-specific data without requiring the provider to re-authenticate or re-identify the patient.
Epic manages EHR Launch apps through the Epic App Orchard – Epic’s curated marketplace for SMART on FHIR clinical applications. Apps in the App Orchard have been reviewed by Epic for security and FHIR conformance. Organizations that build custom SMART apps for internal use can deploy them through Epic’s Interconnect server configuration without going through App Orchard, but they take on full responsibility for security review and FHIR conformance testing.
A regional health system deployed a patient engagement app that connected to Epic via SMART on FHIR. The app’s development team had requested the scope patient/*.read during development to avoid having to enumerate specific resource types. The scope was approved in the development environment. When the app went to production review, the health system’s privacy officer reviewed the consent screen that patients would see – it stated the app would have access to “all of your health records.” Twenty-two patients enrolled in the pilot and immediately called the health system asking why an app needed all of their health data to schedule appointments. The scope had to be narrowed to patient/Patient.read patient/Appointment.read patient/Encounter.read before the app could proceed to general availability. The production re-review and re-consent for pilot patients delayed the launch by 6 weeks.
The CMS Interoperability Rule: What It Requires and When
The CMS Interoperability and Patient Access Rule (CMS-9115-F), finalized in 2020 with subsequent updates, requires CMS-regulated payers (Medicare Advantage, Medicaid, CHIP, and qualified health plans on the federal exchange) to implement specific FHIR APIs and to not engage in information blocking. Health systems are directly affected by this rule primarily through the payer-to-provider and provider-to-payer data exchange requirements.
Patient Access API Requirement
CMS requires regulated payers to implement a Patient Access API that allows beneficiaries to connect third-party apps to their claims and clinical data using FHIR R4. This means a patient with Medicare Advantage coverage can use a SMART on FHIR app to pull their claims history, prior authorization status, and clinical data from their payer’s FHIR endpoint. Health systems are not directly subject to the Patient Access API requirement as providers – that obligation falls on payers. But health systems that accept patients from CMS-regulated payers will need to support FHIR-based care record exchange when those payers request it.
Provider Directory API Requirement
CMS-regulated payers must implement a Provider Directory API – a publicly accessible FHIR endpoint exposing their current provider network directory. The directory must include each in-network provider’s name, address, specialty, NPI, and the plans they accept. Health systems that contract with CMS-regulated payers must ensure that their provider directory information is accurate and up to date in the payer’s directory – because the payer is legally required to expose that data via FHIR and patients rely on it to select in-network providers.
Prior Authorization API (2026 Effective Date)
The most operationally significant component of CMS’s interoperability requirements for health systems is the Prior Authorization API, which became effective for most payers in January 2026. CMS-regulated payers must implement FHIR-based prior authorization APIs that allow providers to submit prior authorization requests electronically and receive responses within specific timeframes. Health systems must configure Epic to submit prior authorization requests through the FHIR-based API to payers who have implemented it.
The prior authorization FHIR exchange uses the HL7 Da Vinci Prior Authorization Support (PAS) Implementation Guide built on FHIR R4. Epic’s Cogito and administrative modules must be configured to generate FHIR-compliant prior authorization requests. The payer must expose a FHIR endpoint that accepts these requests and returns a CoverageEligibilityResponse or ClaimResponse. This is an end-to-end integration that requires coordination between the health system’s Epic team, the payer’s FHIR team, and potentially a clearinghouse. The patient registration and coverage workflows where prior authorization begins are described in the Epic Prelude and Grand Central guide.
| CMS Requirement | Who Must Implement | Effective Date | Health System Impact |
|---|---|---|---|
| Patient Access API | CMS-regulated payers | January 2021 | Low direct; patients may request care records from health system via FHIR |
| Provider Directory API | CMS-regulated payers | January 2021 | Medium – health systems must keep provider directory data accurate with payers |
| Prior Authorization API | CMS-regulated payers + providers submitting PA | January 2026 | High – health systems must configure FHIR-based PA submission in Epic |
| Information Blocking Prohibition | All covered entities including health systems | April 2021 | High – health systems cannot unreasonably restrict FHIR API access |
Information Blocking: The ONC Rule and What It Means Practically
The ONC 21st Century Cures Act Final Rule (effective April 2021) prohibits health systems, health IT developers, and health information networks from engaging in practices that unreasonably limit the access, exchange, or use of Electronic Health Information (EHI). Violations can result in civil monetary penalties for health systems and decertification for health IT developers. This rule has direct operational implications for how health systems configure Epic’s FHIR APIs.
Information blocking practices that health systems must avoid include: requiring a provider to submit a manual request for data that is available via FHIR API when an automated exchange would work, requiring unnecessary data agreements with third-party apps that the patient has already authorized, charging unreasonable fees for providing EHI to authorized requestors, and restricting FHIR API access to patient data in ways not covered by a recognized exception.
The ONC rule defines eight recognized exceptions to the information blocking prohibition – situations where restricting EHI access is permissible. These include: preventing harm to patients (a valid harm exists, not speculative), privacy (honoring a patient’s HIPAA opt-out), security (reasonable security measures), infeasibility (technically not possible to fulfill the request), health IT performance (preventing performance degradation), content and manner (the specific format or method requested is technically burdensome), licensing (disputes with third parties about licensing terms), and consent (the patient has not consented). Claiming a recognized exception requires documentation of the specific factual basis for the exception – it is not a blanket defense.
Payer-to-Provider and Provider-to-Payer FHIR Data Exchange
The HL7 Da Vinci Project develops FHIR implementation guides specifically for payer-provider data exchange. Three Da Vinci implementation guides are most relevant to Epic health system implementations: Payer Data Exchange (PDex), Coverage Requirements Discovery (CRD), and Documentation Templates and Rules (DTR).
PDex: Payer Data Exchange
PDex governs how payers share claims and clinical data with providers and patients via FHIR. When a new patient presents at a health system and they have history with a CMS-regulated payer, the provider can request the patient’s prior claims and clinical data from the payer via the PDex FHIR API. This allows the receiving provider to access the patient’s medication history, prior diagnoses, and care utilization history without requiring the patient to manually gather records. PDex uses FHIR R4 and the US Core implementation guide as its baseline.
CRD and DTR: Coverage Requirements Discovery
Coverage Requirements Discovery (CRD) allows an Epic SMART app to query a payer’s FHIR endpoint at the time a provider orders a service, to determine in real time whether prior authorization is required for that specific service for that specific patient’s coverage. The CRD hook fires when the provider places an order in CPOE. Epic sends a FHIR request to the payer’s CRD server. The payer responds with coverage requirements – including whether PA is needed, what documentation is required, and any coverage limitations.
Documentation Templates and Rules (DTR) extends CRD by providing the payer’s documentation questionnaire directly within the Epic clinical interface. Instead of the provider navigating to a payer portal to fill out PA documentation, the DTR implementation delivers the payer’s required clinical documentation form as a FHIR Questionnaire resource that opens within Epic. The form auto-populates from the patient’s Epic record where possible. This reduces the prior authorization documentation burden from 20+ minutes of portal navigation to a few minutes of confirmation within the clinical workflow.
Testing Epic FHIR APIs: Tools and Validation Patterns
Testing FHIR API integrations requires a different approach from testing traditional EHR module builds. The integration spans Epic’s server, the authorization server, the third-party application, and potentially a payer’s FHIR endpoint. Each component must be validated independently and together.
Epic FHIR Sandbox Testing
Epic’s open.epic.com sandbox provides synthetic patient records and a test authorization server for FHIR API development. Developers can test the complete SMART authorization flow against the sandbox before requesting access to a production Epic environment. Standard API testing tools – Postman, Insomnia, curl – work with Epic’s FHIR endpoints. The authorization flow requires obtaining an access token first, then including it as a Bearer token in subsequent FHIR API requests.
The test pattern for validating a FHIR API call against Epic’s sandbox: authenticate and obtain an access token, make a GET request to the target FHIR endpoint with the Bearer token, validate that the response is a valid FHIR R4 JSON structure, confirm that the resource fields expected by the application are populated, and validate that the FHIR conformance matches the Implementation Guide requirements (US Core, Da Vinci PDex, etc.). BAT methodology applies to FHIR integration testing as much as it does to clinical EHR workflows – described in the BAT vs UAT guide.
FHIR Conformance Validation Tools
Epic’s FHIR responses must be validated against the FHIR R4 specification and the applicable US Core Implementation Guide. HL7’s official FHIR validator (available as a command-line tool and as a web service) validates FHIR JSON resources against the specification and against implementation guide profiles. The Inferno testing framework, developed by ONC, is used for certifying FHIR API conformance under the ONC certification program. Health systems that participate in ONC certification programs must use Inferno to demonstrate their FHIR API implementations meet the required test suite.
A health system began configuring Epic’s FHIR-based prior authorization integration with a large commercial payer that had implemented the CMS Prior Authorization API requirement. The Epic technical team submitted test prior authorization requests to the payer’s FHIR sandbox and received successful responses. When the integration moved to production testing with real patient coverage records, 40% of PA requests returned an OperationOutcome error with the code “business-rule” and the message “Coverage not found.” Investigation with the payer’s technical team revealed that the payer’s production FHIR endpoint used a different Coverage resource identifier format than the sandbox – production required the payer’s member ID in a specific format (prefix + member number) that did not match what Epic was sending from Prelude’s coverage record. The member ID format in the Epic coverage record had to be reformatted in the FHIR mapping before the integration worked correctly. Six weeks of production testing were required after the sandbox testing appeared successful, demonstrating that sandbox validation is necessary but not sufficient for production FHIR integrations.
Epic FHIR Implementation Pitfalls and How to Avoid Them
| Pitfall | What Goes Wrong | Prevention |
|---|---|---|
| Requesting over-broad FHIR scopes | Consent screen shows all-data access; patients object; HIPAA minimum necessary violation | Enumerate only the specific resource types the app actually reads. Privacy officer reviews consent screen language before production. |
| Assuming sandbox = production behavior | Sandbox synthetic data misses edge cases. Payer FHIR endpoints differ between sandbox and production configuration. | Run production integration testing with real (de-identified) data. Budget 4-8 weeks for production FHIR testing after sandbox success. |
| Not validating FHIR resource data quality | FHIR resources reflect documentation quality. Empty Condition resources, missing MedicationRequest codes, or incomplete Observations break downstream app logic. | Audit clinical documentation quality in Epic before relying on FHIR output. FHIR is only as good as the documentation it reflects. |
| Missing BAA for third-party FHIR integrations | Third-party app receives PHI through FHIR without a Business Associate Agreement – HIPAA breach risk | Confirm BAA status for every app registered in Epic’s SMART App configuration before enabling production access. |
| Treating information blocking as a technical issue only | Legal and compliance team not involved. Health system restricts FHIR access without a recognized exception. ONC complaint risk. | Include legal, compliance, and privacy officer in all FHIR API access decisions. Document exceptions with factual justification. |
| Using FHIR ID interchangeably with Epic internal ID | FHIR Patient ID is not the same as Epic PAT_ID. Mixing them in integration code produces record-not-found errors or wrong-patient data. | Use FHIR ID (from FHIR API responses) only in FHIR API calls. Use Epic internal IDs only in Clarity/Caboodle queries. Never mix them. |
Roles, Certifications, and Career Path for Epic FHIR Work
| Role | Key Credentials | Key Skills | Salary Range (2026) |
|---|---|---|---|
| FHIR Integration Analyst | Epic Bridges + FHIR knowledge | OAuth 2.0, SMART on FHIR, API testing, Epic Interconnect | $85,000 – $120,000 |
| FHIR Developer | Software development background + FHIR | REST APIs, SMART auth, JSON, FHIR R4, healthcare domain | $100,000 – $145,000 |
| Interoperability Architect | Epic Bridges + enterprise architecture | Da Vinci IGs, payer-provider exchange, CMS rule compliance | $130,000 – $175,000 |
| Compliance Analyst (FHIR) | Healthcare compliance + FHIR regulatory | ONC rules, information blocking, HIPAA minimum necessary | $95,000 – $130,000 |
Never assume sandbox FHIR test success means production integration will work. Payer FHIR endpoints differ between sandbox and production in identifier formats, code systems, and response structures. Always run a production integration test phase with real coverage records and real payer endpoints, with both technical and compliance staff present to identify both technical failures and HIPAA compliance gaps simultaneously. The production integration test phase should be budgeted at 4-8 weeks regardless of how well sandbox testing went.
Authoritative References
- HL7 FHIR R4 Specification – Resource Definitions, RESTful API, SMART on FHIR Authorization, and US Core Implementation Guide
- CMS – Interoperability and Patient Access Rule (CMS-9115-F): Fact Sheet, Requirements, and Effective Dates