Epic and Oracle Health EHR Integration with CCM Software Using SMART on FHIR: 2026 Guide

Updated for 2026. Healthcare organizations increasingly rely on Electronic Health Record (EHR) systems and specialized Chronic Care Management (CCM) software to coordinate care for patients living with multiple chronic conditions.

However, disconnected applications can create additional work for healthcare providers and care coordinators. Patient demographics, medical conditions, medication information, laboratory results and clinical encounters may be maintained in different systems.

Two important EHR technology platforms in the U.S. healthcare market are Epic and Oracle Health, including Oracle Health Millennium, historically associated with Cerner.

Both provide FHIR-related integration capabilities that can support approved connections with external healthcare applications.

By using HL7 FHIR APIs and SMART on FHIR authorization, compatible CCM applications can exchange relevant clinical information with participating EHR environments.

This guide explains how Epic and Oracle Health integration works, how developers can approach implementation using ASP.NET Core, what information can potentially be exchanged and which security and compliance requirements must be considered.

Why EHR Integration Matters for Chronic Care Management

Chronic Care Management involves ongoing coordination for patients with multiple qualifying chronic conditions.

According to CMS, CCM services may include comprehensive care planning, medication management, patient communication, care transitions and coordination among healthcare professionals.

These activities frequently depend on accurate patient information.

When a practice uses a separate CCM application alongside its EHR, staff may otherwise need to enter information manually or repeatedly switch between systems.

Potential Benefits of EHR Integration

• Reduce repetitive patient information entry.
• Improve access to available chronic condition information.
• Support medication reconciliation workflows.
• Provide relevant laboratory and clinical observations.
• Improve visibility into available clinical encounters.
• Support patient-centered care planning.
• Help authorized care teams review clinical information across connected systems.
• Reduce avoidable administrative duplication.

The actual benefits depend on integration capabilities, data quality, authorization and workflow design.

What Is SMART on FHIR?

SMART on FHIR combines healthcare interoperability concepts with standardized authorization and application-launch mechanisms.

FHIR defines healthcare resources and exchange interfaces. SMART App Launch defines OAuth 2.0-based patterns for securely connecting applications to participating FHIR-enabled systems.

SMART supports applications that launch from within an EHR and applications that begin outside an existing EHR session.

SMART EHR Launch

A clinician using an EHR may open an authorized third-party application from within the clinical workflow.

The EHR supplies launch information that the application uses during the authorization process.

Depending on the supported implementation, the application may receive context identifying the relevant patient or encounter.

SMART Standalone Launch

A user starts an application independently and is directed through an approved EHR authorization process.

The authorization server may establish the appropriate user and patient context.

SMART Backend Services

Some integrations require approved server-to-server information exchange without an interactive user.

The SMART Backend Services framework supports this type of workflow using an OAuth 2.0 client credentials pattern with asymmetric client authentication.

Availability and permitted operations depend on vendor implementation and customer authorization.

Understanding Epic EHR Integration

Epic provides developer resources through its Epic on FHIR ecosystem.

These resources include FHIR API specifications, application registration information, documentation and sandbox testing capabilities.

Developers can explore supported resources and test approved application interactions using available sample data.

Common Epic Integration Scenarios

• Retrieving authorized patient demographic information
• Accessing recorded diagnoses and conditions
• Reviewing supported medication resources
• Accessing clinical observations
• Retrieving relevant encounter information
• Supporting approved clinician-facing SMART applications
• Connecting authorized third-party healthcare workflows

Epic publishes multiple FHIR interfaces, but resource availability and supported interactions vary by API, version and participating Epic organization.

How to Register an Application with Epic

Developers planning an Epic integration should begin with the official Epic on FHIR developer documentation.

Step 1: Create a Developer Account

Access the Epic developer platform at fhir.epic.com and review the application registration requirements.

Step 2: Register the Application

Provide the required application information, including supported connection methods, intended use and applicable registration settings.

Step 3: Obtain Application Identifiers

Epic's registration process provides production and non-production client identifiers according to its application registration workflow.

Step 4: Configure the Sandbox

Use the available Epic sandbox and its sample records to test supported API operations.

Step 5: Test Authentication and FHIR Requests

Verify the supported SMART authorization flow, granted permissions and relevant FHIR resource interactions.

Step 6: Coordinate Customer Deployment

Production deployment requires coordination with the participating Epic healthcare organization and completion of applicable agreements and activation steps.

Epic documentation describes customer-side application download and authorization activities. An app registered with Epic is not automatically enabled across every Epic customer environment.

Important: Registration, sandbox access and production deployment are separate stages. Epic does not automatically endorse or certify applications listed in its developer ecosystem.

Understanding Oracle Health EHR Integration

Oracle Health provides healthcare interoperability APIs through its Millennium Platform developer ecosystem.

The Oracle Health Millennium Platform supports FHIR APIs for approved healthcare application integrations.

Its documentation includes FHIR R4 interfaces, SMART application development, authorization guidance and testing environments.

Oracle Health no longer supports its older DSTU2 FHIR APIs and directs developers toward FHIR R4.

Common Oracle Health Integration Scenarios

• Accessing approved patient information
• Retrieving available clinical conditions
• Reviewing supported medication information
• Accessing relevant clinical observations
• Reviewing encounter-related information
• Launching approved SMART applications in supported clinical contexts
• Using approved backend integration services

Not all Oracle Health products expose the same APIs. Developers should verify the exact Millennium Platform capabilities available to the healthcare organization.

How to Register an Oracle Health SMART Application

Step 1: Review Oracle Health Developer Documentation

Visit the official Oracle Health Millennium Platform documentation.

Step 2: Review the FHIR R4 APIs

Identify supported resources, operations, authorization requirements and relevant implementation guidance.

Step 3: Register an Application

Oracle Health documentation describes application registration through code Console, including application type and privacy settings.

Step 4: Configure SMART Authorization

Review the appropriate authorization framework and configure the application's approved authentication flow.

Step 5: Test with Sandbox Data

Oracle Health documents open and secure sandbox environments for applicable integration testing.

Step 6: Coordinate Production Access

Production access depends on the participating healthcare organization, applicable vendor onboarding, application authorization and technical configuration.

A working sandbox integration does not guarantee that every production environment will expose identical resources or grant the same permissions.

Epic vs Oracle Health: FHIR Integration Comparison

Neither system should be considered universally easier to integrate. Complexity depends on the required data, workflows, available interfaces and customer environment.

FHIR Resources Relevant to Chronic Care Management

FHIR R4 provides resources that can represent important information for CCM workflows.

Support for specific resources and write operations must be confirmed separately for each participating EHR.

Recommended Architecture for Epic and Oracle Health Integration

A CCM platform connecting to multiple EHR systems should separate vendor-specific integration logic from core clinical workflows.

Example Integration Architecture

Epic FHIR API / Oracle Health FHIR API → SMART OAuth Authorization → ASP.NET Core Integration Layer → FHIR Resource Validation → Patient Matching and Mapping → CCM Database → Provider and Care Coordinator Workflows.

This architecture allows an application to maintain different EHR connections while using shared validation and clinical data processing components.

Suggested Components

• Epic-specific integration configuration
• Oracle Health-specific integration configuration
• SMART authentication service
• FHIR REST API client
• FHIR resource validation
• Clinical data mapping
• Patient identity matching
• Synchronization management
• Audit and monitoring mechanisms
• Failure handling and recovery

These are proposed architectural components, not a claim about features currently implemented in ChronicSync.

Implementing EHR FHIR Integration with ASP.NET Core 8

ASP.NET Core 8 provides a modern backend framework for developing healthcare integration services.

Applications can use dependency injection, HttpClient, background services and secure configuration management when connecting to FHIR servers.

Step 1: Create an Integration Project

dotnet new webapi -n CcmFhirIntegration -f net8.0

Developers may separate the integration service from the application's primary clinical business logic.

Step 2: Configure Approved FHIR Connections

Each authorized EHR environment should have an approved FHIR base URL and corresponding authorization configuration.

Connection settings should be managed securely and associated with the correct healthcare organization.

Step 3: Discover Server Capabilities

A supported FHIR REST server provides metadata through the CapabilityStatement endpoint.

GET [FHIR_BASE_URL]/metadata

The response can help identify supported resource types, interactions and other server capabilities.

Step 4: Discover SMART Authorization Settings

SMART-enabled systems expose authorization configuration through a well-known endpoint.

GET [FHIR_BASE_URL]/.well-known/smart-configuration

The response may include authorization and token endpoint URLs along with supported security capabilities.

Oracle Health specifically advises discovering authorization endpoints rather than permanently hard-coding them.

Step 5: Obtain Authorized Access

Use the SMART authorization flow supported by the vendor and approved for the application.

A user-facing integration may use Authorization Code with PKCE. Approved backend services may use a supported backend authorization profile.

Applications must protect access tokens, refresh tokens and cryptographic keys.

Step 6: Retrieve Permitted Clinical Resources

After successful authorization, the application may request relevant FHIR resources supported by the EHR.

GET /Patient/123
GET /Condition?patient=123
GET /Observation?patient=123
GET /MedicationRequest?patient=123
GET /Encounter?patient=123

These examples are illustrative. An actual request requires the approved FHIR base URL, valid authorization and the appropriate patient context.

Step 7: Validate and Map Returned Information

The integration should validate resource structure, patient identifiers, terminology, clinical status and source information before using the imported data.

Step 8: Present Information in Authorized CCM Workflows

Validated information may be made available to appropriate providers and care coordinators according to application authorization policies.

Example: Integrating an Epic EHR with CCM Workflows

Consider a fictional primary care practice using Epic as its EHR and a separate CCM application for ongoing chronic care coordination.

The practice has patients living with diabetes, hypertension and heart failure.

Possible Integration Workflow

1. The practice approves the required application and vendor arrangements.
2. The integration establishes an authorized connection to the participating Epic FHIR environment.
3. The correct patient is identified using appropriate matching procedures.
4. The application retrieves supported Condition and MedicationRequest resources.
5. Relevant Observation information is obtained where available.
6. The application validates incoming data and associates it with the correct internal patient record.
7. Authorized care coordinators review relevant clinical information during their CCM workflow.

This workflow is an example of a potential implementation. It does not imply that every Epic deployment provides identical APIs or permissions.

Example: Integrating Oracle Health with CCM Workflows

Consider a fictional healthcare organization using Oracle Health Millennium as its EHR platform.

The organization wants an approved CCM application to obtain relevant clinical information for patients enrolled in ongoing care management.

Possible Integration Workflow

1. The integration application is registered according to Oracle Health requirements.
2. Appropriate customer authorization and production access are established.
3. The application discovers the relevant SMART configuration.
4. The approved authorization process provides permitted access.
5. The integration retrieves supported clinical resources.
6. The information is validated and mapped to the correct patient.
7. Authorized care team members use the available information during ongoing care coordination.

Actual implementation details depend on Oracle Health's supported APIs and the organization's deployment environment.

Patient Matching Across EHR and CCM Systems

Patient matching is one of the most important parts of healthcare interoperability.

Epic, Oracle Health and a CCM application may use different identifiers for the same individual.

An integration should not assume that patient identifiers are interchangeable across EHR environments.

Recommended Patient Mapping Information

• Internal CCM patient identifier
• Source EHR organization identifier
• External FHIR Patient resource identifier
• Relevant identifier system and value
• Verified patient relationship
• Last synchronization status
• Relevant source and update timestamps

Appropriate duplicate detection and patient identity review help prevent clinical information from being associated with the wrong patient.

Synchronizing EHR Clinical Data

A CCM application may need to update imported clinical information as source records change.

Developers should establish a clear synchronization strategy based on supported vendor capabilities.

Initial Synchronization

Retrieve the relevant authorized information when the patient is first connected.

Scheduled Synchronization

Where permitted, background jobs may periodically retrieve applicable updates.

Incremental Synchronization

Some servers support search parameters or other mechanisms for detecting updated records.

Error Recovery

Transient failures, expired authorization and incomplete responses should be handled through appropriate retry and recovery procedures.

Duplicate Prevention

Source identifiers, resource identifiers and relevant version information can help prevent repeated imports from creating duplicate clinical records.

Applications should verify the specific server's paging, versioning and update capabilities before relying on a synchronization strategy.

FHIR Integration and CCM Care Planning

Comprehensive care planning is an important requirement for Medicare Chronic Care Management.

FHIR integration may provide relevant clinical information that helps practitioners and care coordinators develop and review patient care plans.

For example, a care team may review available clinical conditions, medication orders and observations when updating care goals.

However, importing a FHIR CarePlan or related clinical resource does not automatically satisfy CMS requirements for a comprehensive CCM care plan.

Healthcare organizations must independently verify that the clinical documentation and care management services meet applicable Medicare requirements.

Can EHR Integration Automatically Track CCM Billing Time?

No. Exchanging clinical records and documenting qualifying care management services are different activities.

FHIR does not automatically establish that the required monthly CCM service time has been completed.

Medicare CCM billing depends on patient eligibility, consent, care management activities, practitioner responsibilities, documentation and applicable time thresholds.

A well-designed CCM platform should keep imported clinical information distinguishable from activities performed by care management staff.

This distinction helps prevent inaccurate billing documentation and duplicate reporting.

HIPAA Security for Epic and Oracle Health Integrations

EHR interoperability introduces important security and privacy responsibilities.

Using SMART on FHIR does not automatically make an application HIPAA compliant.

Healthcare organizations must assess the complete data flow, including source EHR systems, integration services, application storage and authorized user access.

Authentication

Use approved SMART authentication and authorization mechanisms supported by the participating EHR.

Patient-Level Authorization

Ensure that users can access only the patient information permitted by the applicable clinical and organizational policies.

Organization-Level Isolation

In a multi-practice CCM platform, prevent one practice from accessing another practice's patient records through application endpoints, identifiers or integration configurations.

Secure Communication

Protect data exchange with appropriately configured HTTPS and relevant transport security controls.

Token Management

Protect OAuth tokens and application credentials through secure storage, restricted access and appropriate lifecycle management.

Audit Controls

Maintain appropriate records of patient information access, integration activities and relevant security events.

Business Associate Agreements

When a CCM software provider creates, receives, maintains or transmits PHI on behalf of a HIPAA-covered healthcare organization, an appropriate Business Associate Agreement is generally required.

Relevant hosting providers or other subcontractors maintaining ePHI may also require downstream BAAs.

Security Risk Analysis

Organizations should evaluate security risks associated with EHR connectivity, imported clinical information, application access and supporting infrastructure.

HHS explains that cloud hosting and encryption do not independently eliminate business associate responsibilities or other applicable HIPAA requirements.

Common Epic and Oracle Health Integration Challenges

Different API Capabilities

Both vendors provide documented interfaces, but available resources and operations vary by implementation.

Application Approval Requirements

Production deployment may require customer authorization, vendor agreements and technical activation.

Patient Identity Differences

Separate healthcare systems may maintain different identifiers for the same individual.

Limited Write Operations

Read access to a FHIR resource does not guarantee that a third-party application can create or modify that resource.

Clinical Data Inconsistency

Terminology, resource status and source-system differences may require careful normalization and review.

OAuth Token Expiration

Applications must account for token expiration, renewed authorization and revoked permissions.

API Usage Restrictions

Vendor-specific rate limits, security controls, agreements and access restrictions can affect implementation design.

Data Synchronization Conflicts

Changes made in multiple systems can create conflicting information unless source ownership and reconciliation rules are defined.

Best Practices for Production EHR Integration

• Confirm the clinical workflows that require integration.
• Use current official vendor documentation.
• Verify the exact FHIR version supported by each EHR.
• Start with a limited set of high-value clinical resources.
• Register applications through official vendor processes.
• Use approved SMART authorization flows.
• Protect application secrets and OAuth tokens.
• Establish reliable patient matching.
• Separate vendor-specific adapters from CCM business logic.
• Validate clinical information before using it.
• Maintain audit and monitoring mechanisms.
• Implement appropriate retry and recovery procedures.
• Test with approved synthetic patient data.
• Review applicable HIPAA and BAA responsibilities.
• Coordinate production activation with participating healthcare organizations.
• Keep Medicare CCM eligibility and billing verification separate from data imports.

Epic and Oracle Health Integration Checklist for CCM Practices

• Identify the current EHR vendor and deployment environment.
• Determine whether approved third-party FHIR access is available.
• Confirm required vendor registration and organizational approval.
• Identify required clinical resources.
• Verify FHIR server capabilities.
• Confirm authorization methods and approved scopes.
• Document patient matching requirements.
• Review application and infrastructure safeguards.
• Establish required contractual agreements.
• Test integration behavior in an approved sandbox.
• Validate clinical data mappings.
• Test multi-user and multi-practice access restrictions.
• Review synchronization reliability.
• Confirm supported production operations.
• Document integration responsibilities and ongoing support procedures.

How ChronicSync Fits into an EHR Interoperability Strategy

ChronicSync focuses on helping healthcare organizations organize Chronic Care Management workflows, patient information, provider assignments and ongoing care coordination activities.

For practices evaluating a CCM platform, integration with existing EHR systems can be an important factor in reducing fragmented workflows.

Healthcare interoperability standards such as HL7 FHIR and SMART on FHIR provide a technical foundation for exploring compatible EHR connections.

Organizations considering ChronicSync should confirm its currently available integrations, supported EHR systems, vendor authorization requirements and applicable security arrangements before planning production use.

Our goal is to help healthcare organizations explore more organized and connected approaches to chronic care management.

Explore ChronicSync and Request a Demo to learn more about our Chronic Care Management platform.

Frequently Asked Questions

Can CCM software integrate with Epic?

Yes. Compatible CCM software can potentially integrate with Epic through approved FHIR APIs and other supported interfaces, subject to application registration, customer authorization and technical requirements.

Can CCM software integrate with Oracle Health?

Yes. Oracle Health Millennium provides FHIR R4 APIs and SMART application integration capabilities for authorized applications.

What is SMART on FHIR?

SMART on FHIR defines authorization and application-launch patterns that allow approved applications to integrate with FHIR-enabled healthcare systems.

Is Epic integration free?

Epic provides developer resources and sandbox capabilities, but actual production arrangements may involve vendor, customer, contractual or implementation requirements. Organizations should verify current terms directly.

Does Oracle Health support FHIR R4?

Yes. Oracle Health Millennium documents FHIR R4 APIs and directs developers to use R4 rather than its discontinued DSTU2 APIs.

Do Epic and Oracle Health support identical FHIR APIs?

No. Although both use FHIR standards, resource availability, supported interactions and implementation details can differ.

Can FHIR synchronize patient diagnoses?

Yes, when the participating EHR exposes the necessary Condition resources and grants appropriate access. Synchronization logic must be implemented by the receiving application.

Can FHIR retrieve medications?

Yes. Supported medication-related resources may be retrieved through authorized FHIR APIs. The available medication information varies by EHR.

Can FHIR integration update care plans?

Potentially, when the EHR supports the necessary write operations and the application has appropriate authorization. Read access alone does not establish write capability.

Does SMART on FHIR automatically make a platform HIPAA compliant?

No. SMART provides standardized security-related integration mechanisms, but HIPAA compliance requires applicable administrative, physical, technical and contractual safeguards.

Does FHIR integration automatically generate billable CCM services?

No. Medicare CCM billing requirements must be satisfied independently of imported clinical data.

Can a CCM application connect to multiple EHR vendors?

Yes. An application can be designed with separate vendor configurations and integration adapters, provided each connection is authorized and supported.

What is needed before production deployment?

Organizations should confirm vendor onboarding, customer authorization, technical compatibility, security requirements, data mapping, testing and applicable legal agreements.

Final Thoughts

Epic and Oracle Health provide important interoperability capabilities for healthcare organizations exploring modern clinical application integration.

Through FHIR R4 APIs and SMART authorization patterns, compatible CCM applications may exchange relevant clinical information with approved EHR environments.

For Chronic Care Management, these connections can help teams access information needed for medication review, chronic condition management and care planning.

However, successful implementation requires careful attention to vendor requirements, patient identity, authorization, data quality, security and clinical workflow design.

Healthcare organizations should evaluate interoperability capabilities alongside their operational needs and HIPAA responsibilities.

Learn more about ChronicSync: www.chronicsync.com

Official Sources and References

• Epic: Epic on FHIR Developer Platform
• Epic: Developer Documentation and App Registration
• Oracle Health: Millennium Platform APIs
• Oracle Health: Authorization Framework
• Oracle Health: Build and Test SMART on FHIR Applications
• HL7: FHIR R4 Specification
• HL7: SMART App Launch Implementation Guide
• HL7: US Core Implementation Guide
• HHS: HIPAA and Cloud Computing Guidance
• CMS: Care Management Services

Disclaimer: This article is provided for educational and technical purposes only and does not constitute legal, medical, regulatory, security or billing advice. Epic, Oracle Health and HL7 are referenced solely to explain interoperability concepts and vendor documentation. No partnership, certification, endorsement or live ChronicSync integration is implied. Verify current vendor specifications, licensing, customer authorization and applicable HIPAA requirements before processing patient information.