Connect

hello@6bdigital.com
0113 350 1290
Contact us

 

Epic FHIR API integration

Epic EPR has embraced the HL7 FHIR standard to enable seamless data exchange between its EPR and third-party applications. The FHIR API enables access to a wide array of clinical resources, including patient demographics, medications, allergies, encounters, and observations. These resources are structured in compliance with FHIR standards, ensuring consistency and interoperability across different healthcare systems.

Epic supports multiple FHIR versions, notably STU3 and R4, with each version offering specific capabilities and resource support. Developers must select the appropriate FHIR version based on their application’s requirements and the functionalities offered by the target Epic system. It’s important to note that certain resources may have read-only access, while others support create, update, and delete operations. For instance, the Encounter resource typically supports read and search operations, but not creation via the FHIR API.

Authentication and Authorisation: Implementing OAuth 2.0 for Epic EPR Integrations

Security is paramount when accessing sensitive patient data. Epic uses the OAuth 2.0 protocol for authentication and authorisation, ensuring that only authorised applications and users can access specific resources. The OAuth 2.0 workflow involves obtaining an access token through an authorisation server, which is then used to authenticate API requests.

Applications must be registered with Epic to receive client credentials necessary for the OAuth process. Depending on the application type – whether it’s a patient-facing app, clinician-facing tool, or backend service – different OAuth flows may be applicable. For example, patient-facing applications often use the Authorisation Code Grant flow, requiring user interaction for consent, while backend services might utilise the Client Credentials Grant flow for system-to-system communication.

Data Access and Resource Handling
Epic’s FHIR API provides access to a comprehensive set of resources aligned with the widely used HL7 FHIR standards. These resources encompass various aspects of patient care, including:

  • Patient: Demographic information and identifiers.
  • AllergyIntolerance: Documented allergies and intolerances.
  • MedicationRequest: Prescribed medications and orders.
  • Observation: Clinical observations, lab results, and vital signs.
  • Encounter: Details of patient encounters with healthcare providers.

When interacting with these resources, developers must adhere to the constraints and capabilities defined by Epic. For instance, while some resources support full CRUD (Create, Read, Update, Delete) operations, others may be limited to read-only access. Understanding these limitations is crucial for designing applications that function correctly within the Epic ecosystem.

Handling Identifiers and Object IDs for Epic EPR Integrations

Epic utilises Object Identifiers (OIDs) to uniquely identify entities within its system. These OIDs are structured hierarchically and are essential for accurately referencing resources across different systems. For example, Epic’s root OID is 1.2.840.114350, with child OIDs assigned to specific organisations or resource types.

When integrating with Epic’s FHIR API, developers must ensure that their applications correctly handle these identifiers, especially when mapping data between Epic and external systems. Proper management of OIDs is vital for maintaining data integrity and ensuring that resources are accurately linked across different platforms.

Implementing SMART on FHIR Applications in Epic EPR

Epic supports the SMART (Substitutable Medical Applications, Reusable Technologies) on FHIR framework, allowing developers to create applications that integrate seamlessly into the Epic EPR interface. SMART on FHIR applications can be launched directly from within Epic, providing context-aware access to patient data and enabling interactive workflows for clinicians.

To develop a SMART on FHIR application, developers must:

  • Register the Application: Obtain client credentials and define the application’s launch parameters.
  • Implement OAuth 2.0: Ensure secure authentication and authorisation mechanisms are in place.
  • Design Context-Aware Interfaces: Create user interfaces that respond dynamically to the patient context provided by Epic.
  • Test in Sandbox Environments: Utilise Epic’s sandbox environments to validate application functionality before deployment.

By following the SMART on FHIR specifications, developers can create applications that enhance clinical workflows and provide value-added services within the Epic ecosystem.

Best Practices for Successful Epic EPR FHIR Integration

Achieving a successful integration with Epic’s FHIR API requires meticulous planning and adherence to best practices:

  • Thorough Documentation Review: Familiarise yourself with Epic’s FHIR API documentation to understand resource capabilities, constraints, and usage guidelines.
  • Robust Error Handling: Implement comprehensive error handling to manage API responses, including handling of fatal and warning errors as defined by Epic.
  • Data Mapping and Validation: Ensure accurate mapping between Epic’s data structures and your application’s data models, validating data integrity throughout the integration process.
  • Security Compliance: Adhere to security best practices, including the use of HTTPS for data transmission, secure storage of access tokens, and compliance with relevant healthcare data protection regulations.
  • Performance Optimisation: Design your application to handle API rate limits and optimise performance, especially when dealing with large datasets or high-frequency data access.

Conclusion

Integrating with Epic’s FHIR API offers digital health innovators a significant opportunity to enhance interoperability, streamline clinical workflows, and improve patient care. By understanding the technical specifications, implementing robust authentication mechanisms, and adhering to best practices, developers can create applications that seamlessly integrate with Epic’s EPR system. As healthcare continues to evolve towards more connected and patient-centric models, leveraging Epic’s FHIR API will be instrumental in driving innovation and delivering value across healthcare.

Frequently Asked Questions: Epic EPR FHIR Integration

What environments are available for testing Epic EPR FHIR integrations?

Epic provides sandbox environments through the Epic on FHIR platform. These are public-facing and support various FHIR versions (STU3, R4) for initial development and validation. For production-level integration, organisations must also work with an Epic customer to gain access to their specific test environments, as each health system may expose different endpoints and configurations.

Do Epic FHIR APIs support real-time data updates?

While Epic’s FHIR APIs offer near real-time access to data through RESTful endpoints, true event-based real-time updates typically require the use of Epic’s Subscription API or webhooks via App Orchard or other middleware. These are not part of the standard FHIR specification and often involve proprietary extensions. Real-time integration for use cases such as alerts or patient monitoring usually requires negotiation with the hosting Epic site and deeper technical setup.

Can Epic’s FHIR API be used for bi-directional data exchange?

Yes, but with limitations. While read access is widely supported, write capabilities are restricted to certain resources and vary between implementations. For more advanced bi-directional data exchange, many organisations rely on a combination of FHIR for reading and HL7 v2 or APIs via Epic Bridges for writing more complex data such as orders or results.

What are common integration challenges with Epic FHIR APIs?

Key challenges include: inconsistent resource availability across health systems, version discrepancies (e.g. some organisations still use STU3 while others have adopted R4), and strict security requirements around OAuth 2.0 flows. Additionally, aligning with patient-matching logic and understanding Epic’s custom resource extensions often requires close collaboration with the Epic customer organisation.

How is patient context passed in an Epic SMART on FHIR launch?

When a SMART app is launched from within Epic’s user interface, it passes context parameters such as patient, encounter, and user in the launch URL. This allows the app to initialise in a patient-specific view without requiring the clinician to re-enter details. The app must then exchange the authorisation code for an access token, which can be used to retrieve the full FHIR resource for the patient.

Is Epic FHIR integration suitable for population-level data access?

Standard FHIR APIs from Epic are designed primarily for patient-level access. For population health use cases, Epic supports FHIR Bulk Data (Flat FHIR), which allows extraction of de-identified or cohort-based datasets via asynchronous jobs. Access to these endpoints requires explicit agreement and configuration with the hosting organisation, and is typically used in research, analytics, or value-based care programmes.

Does Epic support custom FHIR extensions?

Yes. Epic often extends standard FHIR resources with proprietary fields to support specific workflows or internal data structures. These are included under the extension field of FHIR resources. Developers must account for these when integrating with specific Epic instances, especially if clinical or administrative workflows depend on these non-standard fields.

How do I deploy an app for use across multiple Epic organisations?

To scale an application across different Epic clients, it must first be listed in Epic’s App Orchard, where it undergoes review and registration. From there, each healthcare organisation decides independently whether to install and enable the app in their environment. As a result, implementation often requires custom configuration per site, including endpoint URLs, authentication details, and testing procedures.

What’s the difference between App Orchard and Epic on FHIR?

Epic on FHIR is a public-facing developer portal offering sandbox access and general FHIR documentation, whereas App Orchard is Epic’s partner programme for commercial apps. App Orchard membership provides access to production-grade APIs, testing environments, support services, and publishing capabilities, allowing you to integrate directly into live Epic systems.

Ready to accelerate your technology project?

Chat to our team of experts and let's see how we can help you.