Epic on FHIR Integration, or How to Enhance Interoperability in the Medical Sector

Fragmented data in siloed healthcare systems has long hindered effective communication and collaboration. This fragmentation causes poor care coordination, operational inefficiencies, and barriers to innovation. Interoperability — the ability of different systems and applications to access, exchange, integrate, and use data cooperatively — is now a critical necessity. Achieving this relies on robust standards.

Are you looking to integrate AI solutions by harnessing the power of Epic on FHIR? SPsoft enables you to navigate the complexities of healthcare data exchange!

Get in Touch

What is Epic on FHIR?

Epic on FHIR represents Epic Systems’ commitment to using the FHIR (Fast Healthcare Interoperability Resources) standard. This enables its Electronic Health Record (EHR) platform to communicate effectively with other healthcare applications. FHIR is a modern, web-friendly standard using RESTful principles for exchanging healthcare information in an easily implementable format. 

Essentially, Epic on FHIR is Epic’s suite of FHIR-based Application Programming Interfaces (APIs) and its support infrastructure, allowing third-party applications to securely access and exchange data with the Epic EHR. This is a significant step towards a more open healthcare ecosystem.

Why Epic on FHIR is a Game-Changer for Healthcare Innovation

The implementation of Epic on FHIR is more than a technical upgrade; it’s a fundamental shift that can catalyze healthcare innovation. By enabling smoother data exchange, Epic on FHIR offers benefits that address long-standing industry challenges, paving the way for faster development, improved clinical decision-making, and more patient-centered care by dismantling data silos. This initiative reflects the industry trend towards open standards and API-driven healthcare, driven by market demand and regulatory pressures.

Key advantages of Epic on FHIR include:

• Breaking down data silos between systems like EHRs, LIS, RIS, and billing platforms. 
• Enabling real-time data access for clinicians and applications, crucial for timely decisions. 
• Empowering patients to access their health information via portals and mobile apps. 
• Streamlining workflows by automating data exchange, reducing administrative burdens and errors. 

Leveraging Epic on FHIR for advanced solutions, especially in AI, can be complex. SPsoft has deep expertise in developing and integrating sophisticated Epic on FHIR and Epic SMART on FHIR solutions, helping organizations benefit from transformative healthcare applications.

Epic on FHIR vs. Traditional Epic APIs: A Paradigm Shift

Understanding the difference between Epic on FHIR and traditional Epic APIs (like those based on older HL7 versions) highlights the advancements FHIR brings.

Understanding Traditional Epic APIs (e.g., HL7v2)

For years, Health Level 7 Version 2 (HL7v2) was standard for healthcare data exchange. Traditional Epic APIs often used HL7v2, a segment-based, pipe-and-hat delimited messaging format.  While reliable for established workflows like ADT messages or lab results, HL7v2 presents challenges for modern app development: complex parsing, inflexibility, and reliance on proprietary encoding. It’s not designed for the agility and real-time demands of current web and mobile applications, often working in batches. These limitations spurred the development of standards like FHIR.

The ‘Epic on FHIR’ Approach: Modern, Flexible, and Resource-Based

Epic on FHIR uses the FHIR standard, which is architecturally different. FHIR employs RESTful APIs and supports formats like JSON and XML. A core FHIR concept is the “resource” — discrete data objects like Patient, Observation, or Appointment. This resource-based architecture makes data granular and easier for developers to use than HL7v2’s large messages. This lowers the entry barrier for developers, allowing them to use common web development skills.

The shift to Epic on FHIR offers substantial advantages for modern healthcare apps.

Table 1. Epic on FHIR vs. Traditional Epic APIs

Feature	Epic on FHIR	Traditional Epic APIs (e.g., HL7v2)
Data Standard	FHIR (RESTful, JSON/XML)	HL7v2 (Segment-based, ER7)
Architecture	Resource-oriented	Message-oriented
Data Granularity	High (discrete resources)	Lower (larger, complex messages)
Development Ease	Easier with modern web tech	Steeper learning curve, specialized tools
Real-time Capability	Strong support	Often batch-oriented, less real-time friendly
Flexibility & Extensibility	Higher	Lower
Typical Use Cases	Mobile apps, patient portals, real-time decision support	Legacy system integration, batch data exchange (labs, billing)

This transition means a broader talent pool can now more easily develop healthcare applications, potentially reducing costs and timelines.

App Integration: Epic SMART on FHIR Explained

FHIR provides the data structure and API, while SMART on FHIR enables seamless and secure app integration within the EHR. Epic SMART on FHIR is Epic’s implementation of this framework.

What is SMART on FHIR?

SMART (Substitutable Medical Applications, Reusable Technologies) on FHIR is an open, standards-based platform. It provides open specifications for developers to create apps that integrate securely into health IT systems like Epic EHRs, patient portals, and HIEs. SMART on FHIR aims to let developers write an app once and connect it to any compliant EHR, creating “pluggable” apps. This standardization is vital for a scalable app ecosystem.

How SMART on FHIR Integrates with Epic’s Ecosystem 

Epic has embraced SMART on FHIR, allowing third-party apps to integrate directly within its Hyperspace EHR platform. Clinicians can activate an Epic SMART on FHIR app from various workflow points. The app often displays within an iFrame, feeling like a native EHR component. 

Key aspects of Epic SMART on FHIR integration include:

• Launch from within EHR context. Apps can be launched with the current patient, encounter, or other relevant clinical information already in context, streamlining the user experience. 
• Standalone application launch. Apps can also be launched independently of an active EHR session, for example, by a patient from a portal or a provider accessing a dashboard. 
• Use of SMART App Launch Framework. Epic supports standard SMART launch sequences, ensuring predictable behavior for app developers. 
• Secure context passing. When an app is launched, Epic securely passes necessary information, such as an authenticated launch token and the FHIR server URL, to the application. 

Embedding Epic SMART on FHIR apps directly into clinical workflows improves usability and efficiency, reducing system switching and clicks.

The Role of OAuth 2.0 in Secure Authentication and Authorization

Security is paramount. SMART on FHIR Epic integrations use the OAuth 2.0 protocol for secure authentication and authorization. OAuth 2.0 allows users to grant third-party apps limited data access without sharing login credentials. This is fundamental to the security of the Epic SMART on FHIR ecosystem, ensuring apps only access permitted data based on user consent and predefined scopes.

Core Capabilities: What Epic on FHIR Offers Developers

Developers need to understand the data and functionalities accessible through Epic on FHIR, including supported FHIR resources, read/write capabilities, and authentication/permission mechanisms.

Supported FHIR Resources and Endpoints

Epic provides access to many FHIR resources, representing clinical and administrative concepts. Through Epic on FHIR, developers can interact with resources such as:

• Patient (demographics, identifiers, contact information)
• Observation (vital signs, lab results, social history)
• Appointment (schedules, statuses, participants)
• AllergyIntolerance (patient allergies)
• Condition (diagnoses, health concerns)
• MedicationRequest / MedicationOrder (prescriptions)
• DiagnosticReport (test results)
• DocumentReference (clinical notes, CCDs)
• CarePlan (patient care plans)

Epic supports these across FHIR versions (DSTU2, STU3, R4), recommending R4 for new development. FHIR endpoints typically follow a RESTful structure like /api/FHIR/{version}/{ResourceType}. 

Table 2. Overview of Commonly Supported Epic FHIR Resources

FHIR Resource	Key Data Elements Often Included	Common Operations Supported by Epic (and limitations)	Typical Use Case Example
Patient	Demographics, identifiers, contact info, birthdate, gender	Read, Search	Retrieving patient banner data.
Observation	Vitals, lab results, social history, LOINC codes	Read, Search; Create (e.g., vitals, with limitations like not to closed encounters)	Displaying recent labs, trending vitals.
Appointment	Scheduling details, status, participants, slot information	Read, Search; Create (some scenarios, often via specific workflows)	Viewing appointments, facilitating scheduling.
MedicationRequest	Prescriptions, medication, dosage, route, order details	Read, Search; Create (e.g., unsigned orders via CDS Hooks)	Reviewing medication lists, drafting prescriptions.
Condition	Problems, diagnoses, clinical status, onset date	Read, Search, Create	Managing active problem lists.
Document Reference	Clinical notes, CDA documents, encounter summaries, type	Read, Search; Create (certain document types)	Accessing progress notes or care summaries.
AllergyIntolerance	Allergen, manifestation, severity, verification status	Read, Search, Create	Viewing and documenting patient allergies.

Read vs. Write Access: What’s Possible with Epic FHIR APIs?

Epic on FHIR supports both read (retrieving data) and write access (creating, updating data) for many FHIR resources. Read capabilities are extensive. Write capabilities (CRUD) are also available but are more controlled and context-dependent.

• Create: Apps can create new resources like AllergyIntolerance.Create or Observation.Create for vitals, often with limitations (e.g., not for closed encounters or future appointments). Creating internal Epic encounters via API may also be restricted.
• Update: Some resources support updates.
• Delete: Deletion is generally restricted to maintain data integrity.

Epic’s approach to write access is cautious, aiming to preserve medical record integrity and align with clinical workflows. For instance, creating medication orders might use CDS Hooks for provider review within Epic.

Authentication Deep Dive: How OAuth 2.0 Works in the Epic on FHIR Context

Authentication for Epic on FHIR and Epic SMART on FHIR uses the SMART App Launch Framework, relying on OAuth 2.0. This standard enables secure, delegated access.

The typical OAuth 2.0 flow in the Epic SMART on FHIR context involves the following key steps:

1. Application Registration. The third-party application is registered with Epic (e.g., the App Orchard). During this process, the app receives a unique client_id and provides one or more redirect_uri(s). 
2. Initiating Authorization. The app redirects the user’s browser to Epic’s OAuth 2.0 authorization server endpoint. This request includes parameters like the client_id, redirect_uri, requested scope(s), a response_type of “code”, and often a launch token. 
3. User Authentication and Consent. The user authenticates directly with Epic’s system. After successful authentication, the user is typically presented with a consent screen detailing the data the app is requesting access to.
4. Authorization Code Grant. Epic’s authorization server redirects the user’s browser back to the app’s registered redirect_uri, providing an authorization code.
5. Access Token Exchange. The application securely exchanges this authorization code for an access_token by making a direct, backend POST request to Epic’s OAuth 2.0 token endpoint.
6. API Access. Epic’s token endpoint validates the request and returns a JSON object containing the access_token. The application can then use this access_token as a “Bearer token” in the Authorization header of its FHIR API requests.

Epic supports various OAuth 2.0 client types, including confidential and public clients (often using PKCE – Proof Key for Code Exchange). 

Managing App Permissions and Scopes within Epic

SMART on FHIR utilizes “scopes” to define the specific permissions an application requests (e.g., patient/Patient.read, user/Appointment.write). This ensures applications only access necessary data, adhering to the principle of least privilege. When developers register their application with Epic, they select specific APIs (e.g., “MedicationStatement.read API”), which then map to the appropriate SMART scopes (e.g., patient/MedicationStatement.read). 

Epic’s system allows administrators to manage authorized applications and review/approve their requested scopes. Users may also be prompted to approve these scopes during the OAuth 2.0 consent process, ensuring transparency and control.

Developing and Deploying Your Epic SMART on FHIR Application

Bringing a SMART on FHIR Epic app to life means navigating Epic’s developer ecosystem, understanding registration and deployment, and using testing tools.

Getting Started: The Epic Developer Ecosystem

Primary entry points are Epic’s developer portals: fhir.epic.com and open.epic.com.

• fhir.epic.com. Dedicated to Epic on FHIR, hosting documentation, API specs, guidelines, and tutorials. Developers register apps here for client IDs and sandbox access.
• open.epic.com. Broader view of Epic’s interoperability, including FHIR, LaunchPad testing tool, and other Epic APIs. 

These portals provide essential knowledge and tools.

Registering Your App: Epic App Orchard (now Epic App Market) and MyApps

To integrate a SMART on FHIR Epic app with a live Epic EHR, developers register their app.

• MyApps on fhir.epic.com. Register here for a client_id, specifying app details, audience, required FHIR APIs (scopes), and redirect URIs.
• Epic App Orchard (now Epic App Market). A marketplace for Epic-integrated apps. Listing here involves a formal review by Epic for quality, security, and functionality. It provides APIs, data models, sandboxes, and support.

This process fosters a controlled, open ecosystem.

Technical Steps to Deploy a SMART on FHIR App in Epic’s Environment

Deploying a SMART on FHIR Epic app involves a series of technical steps:

1. Application Development. Build the SMART on FHIR application using standard web technologies.
2. App Registration with Epic. Visit fhir.epic.com, navigate to app registration, and provide details like app name, audience, required FHIR APIs, and redirect_uri(s) to obtain a client_id.
3. Integrate with a SMART FHIR Client Library (Recommended). Utilize libraries like smart-on-fhir-client-js to simplify SMART App Launch and OAuth 2.0. Configure with client_id and matching redirect_uri.
4. Implement Launch Sequences. Prepare for EHR launch (receiving launch token and iss URL) or standalone launch (configuring FHIR server URL).
5. Execute the OAuth 2.0 Authorization Flow. Discover Epic’s OAuth endpoints from the iss URL. Request an authorization code by redirecting the user to Epic’s authorization endpoint with necessary parameters. Exchange this code for an access_token via a backend request to Epic’s token endpoint.
6. Interact with Epic FHIR APIs. Use the access_token as a Bearer token in Authorization headers for FHIR API requests.
7. Deploy Your Application. Host your web application on a secure HTTPS server.
8. (Optional) Publish on Epic App Orchard. Package the app (e.g., ZIP file), 25 create an App Orchard account, submit for review, and publish if approved. 

This requires careful adherence to OAuth 2.0 and Epic’s details.

Testing and Validation: Sandbox Environments and Tools for Epic on FHIR

Thorough testing is critical. Epic provides several resources to facilitate this, including Testing Sandbox for testing FHIR API calls against example patient data using a non-production client_id. The open.epic.com/launchpad tool enables developers to test the SMART on FHIR EHR launch flow, simulating launches from within an Epic EHR session. 

For initial development, Epic’s sandbox also offers some unsecured FHIR resources accessible without OAuth tokens. For web-based applications intended for embedding within Epic’s Hyperspace, an Epic Testing Harness is available to validate compatibility. Also, the SMART on FHIR community and Epic often provide sample code and libraries, like smart-on-fhir-client-js, which serve as starting points and demonstrate best practices. While these tools are invaluable, developers must also conduct thorough testing in customer-specific non-production environments before going live, as each healthcare organization runs its own configured instance of Epic.

Navigating the Epic on FHIR Landscape: Key Considerations

Successful development with Epic on FHIR requires attention to availability, API versioning, performance, and application architectures.

Availability: Is Epic on FHIR for all customers, versions, or modules?

Epic on FHIR is broadly available. Developer resources on fhir.epic.com are generally free. Epic customers can authorize apps via an open.epic API Subscription Agreement. 

However:

• Instance-Specific. Each organization manages its own Epic instance and data. Apps connect to each customer’s system individually. 
• Version and Configuration Dependency. FHIR capabilities can vary by Epic software version and instance configuration. New features might be in later versions. 
• Module Interaction. FHIR APIs access data across many Epic modules (charting, orders, labs), but coverage might not be uniform. Creating internal Epic encounters via API may be restricted. 

Consult fhir.epic.com for up-to-date information. Variability requires planning for testing and adaptation for each customer.

FHIR API Versioning: Understanding DSTU2, STU3, R4, and Epic’s Support

FHIR evolves with versions. Epic supports multiple versions:

• DSTU2 (Draft Standard for Trial Use 2). Earlier version, important for Argonaut Project and initial USCDI phases. Epic supports DSTU2 for compatibility. 
• STU3 (Standard for Trial Use 3). Interim version with enhancements. Epic supports STU3. 
• R4 (Release 4). First normative version, mature and widely adopted. Epic recommends R4 for new development and is expanding R4 support. Accessing clinical notes via Apple Health Records, for example, requires upgrading endpoints to R4.

Check fhir.epic.com for supported versions for specific resources and interactions.  Documentation details version-specific behaviors.

Performance and Rate Limits: Best Practices for Efficient API Interaction

Specific rate limits for Epic FHIR APIs are not always publicly detailed, but Epic emphasizes responsible API use to prevent system overload. Performance issues can impact the operational EHR. 

Epic provides “Designing an Efficient Application” guidelines:

• Initial Load Response Time. Aim for <1.5 seconds for Hyperspace-launched apps.
• Appropriate Technology. Use event-driven interfaces (HL7v2, CDS Hooks) for system-to-system sync or contextual CDS, not constant API polling. FHIR APIs suit targeted, real-time data pulls.
• Data Minimization. Request only necessary data. Use FHIR search parameters.
• Bundle API Calls. Use _include to retrieve related resources in one call.
• Avoid API Polling: Opt for event-driven mechanisms.
• Cache Static Data. Cache infrequently changing data (Location, Practitioner).
• Customer Communication. Inform customers about data access patterns and volumes.
• Programmatic Guardrails. Implement internal caps on API call volume or monitoring.
• Stagger API Calls. Schedule large data pulls during off-peak hours in coordination with customers.
• Thorough Non-Production Testing. Conduct realistic load testing in customer non-production environments.

These guidelines highlight a shared responsibility for efficient API use.

Supporting Multi-Tenant or Patient-Authorized Applications

Epic on FHIR and SMART on FHIR Epic support both patient-authorized and multi-tenant app architectures.

• Patient-Authorized Applications. SMART on FHIR (with patient/… scopes and launch/patient contexts) enables patients to authorize apps to access their data. ⁷ For multiple providers using Epic, the app performs OAuth 2.0 with each provider’s instance.
• Multi-Tenant Applications. A SaaS app serving multiple healthcare organizations would need secure connections and authorizations to each organization’s Epic instance, handling configurations for each tenant.

The decentralized nature of Epic instances and the flexibility of SMART on FHIR/OAuth 2.0 allow these models.

Real-World Applications: Use Cases Powered by Epic on FHIR

Epic on FHIR and Epic SMART on FHIR unlock innovative use cases benefiting patients, providers, and organizations.

Enhancing Mobile Health Apps for Patients and Providers

Mobile health (mHealth) applications are a prime beneficiary of Epic on FHIR. For patients, these apps can securely connect to Epic EHRs, allowing individuals to access personal health records, view lab results, check appointment details, manage medications, and communicate with care teams. This empowers greater patient involvement. For providers, while Epic offers its own mobile solutions like Haiku and Rover, FHIR enables specialized third-party mobile tools that might offer niche functionalities or tailored user experiences for accessing patient data and managing workflows on the go. 

Facilitating Secure Patient Access to Their Health Data

A core goal of modern healthcare initiatives, like the 21st Century Cures Act, is easy, secure patient EHI access. Epic on FHIR is key. FHIR APIs allow patient portals and third-party apps to retrieve comprehensive health views (diagnoses, medications, allergies, notes). This improves patient engagement and shared decision-making.

Building Advanced Provider Tools and Decision Support Systems

Providers benefit from real-time data access via Epic on FHIR for advanced clinical tools:

• Clinical Decision Support (CDS). FHIR APIs feed data into CDS engines for evidence-based recommendations. CDS Hooks, with Epic SMART on FHIR, trigger external services for suggestions or app launches. 
• AI-Driven Analytics. Standardized FHIR data is ideal for AI/ML models to identify patterns, predict risks, and personalize treatments.
• Telehealth Platforms. FHIR integration with telehealth solutions ensures seamless patient information exchange.

Embedding SMART on FHIR Apps Directly into Clinical Workflows and Dashboards

One of the most powerful aspects of Epic SMART on FHIR is its ability to embed third-party applications directly into the clinician’s primary workspace, Epic Hyperspace. These embedded apps can appear as the main activity in a patient’s chart, within a sidebar panel, or be launched from custom menu buttons. This tight workflow integration is crucial for provider adoption, minimizing disruption by launching apps in context with current patient data. 

Examples of such embedded app use cases include specialized disease-specific risk calculators, advanced data visualization tools for complex datasets like genomic data or detailed lab analytics, apps that streamline administrative tasks such as prior authorization, tools for generating personalized patient education materials, and dashboards that surface AI-driven predictions relevant to the patient or workflow. 

Compliance and the Future: Epic on FHIR and Regulatory 

Epic on FHIR adoption is heavily influenced by regulations promoting interoperability and patient data access.

Epic on FHIR and the 21st Century Cures Act

The 21st Century Cures Act and ONC implementing regulations aim to promote interoperability and prevent information blocking, ensuring patient EHI access and provider IT tool flexibility. FHIR-based APIs are central. Epic on FHIR provides the API infrastructure for Epic-using organizations to comply. Epic has worked to streamline its standards-based APIs, including those supporting USCDI, to help customers meet ONC Cures Act Final Rule obligations. 

ONC Interoperability Rules and FHIR

The ONC Health IT Certification Program sets criteria for health IT products, increasingly emphasizing standardized APIs like FHIR. Certification ensures products are interoperable and secure. Epic’s FHIR capabilities align with these ONC certification requirements.

The Role of USCDI (United States Core Data for Interoperability)

USCDI is a standardized set of health data classes for nationwide interoperable exchange. ONC requires certified health IT to make this data available via FHIR APIs. Epic provides access to USCDI data elements through Epic on FHIR APIs, often making USCDI on FHIR API specifications freely available. This ensures baseline data consistency, reducing custom integration effort for developers. 

Conclusion

The journey to seamless healthcare interoperability continues, but Epic on FHIR is a monumental step forward, enabling a new era of connectivity and innovation.

While Epic on FHIR is significant progress, seamless interoperability is an ongoing journey requiring collaboration. The foundation laid by FHIR and its adoption by key players like Epic offers a promising trajectory. Health data management platforms, often leveraging FHIR, are becoming the architectural backbone for real-time data and AI scalability. Industry analysis projects a strong upward trend in FHIR adoption, with most health systems expected to adopt FHIR APIs soon, driven by regulatory mandates and the need for improved data exchange. 

Ready to reach the full potential of your healthcare data with intelligent automation? SPsoft can help you develop sophisticated healthcare AI tools using Epic on FHIR!

Contact Us

FAQ