How to Integrate HL7 FHIR APIs in Chronic Care Management Software: ASP.NET Core 8 Guide for 2026

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

However, disconnected healthcare systems can create significant challenges. Care coordinators may need to manually enter patient demographics, review diagnoses across separate applications, reconcile medications, and maintain care plans in multiple locations.

HL7 Fast Healthcare Interoperability Resources (FHIR) provides a standardized approach to exchanging healthcare information through modern APIs.

By integrating supported FHIR APIs, CCM software can retrieve relevant clinical information from connected EHR systems and make that information available within authorized care management workflows.

This technical guide explains how to design and implement HL7 FHIR integration for Chronic Care Management using ASP.NET Core 8, including architecture, FHIR resources, API requests, SMART on FHIR authentication, patient synchronization, security, and production deployment considerations.

What Is HL7 FHIR API Integration?

HL7 FHIR is a healthcare interoperability standard developed by Health Level Seven International.

FHIR defines structured healthcare resources and standardized interactions that enable compatible applications to exchange clinical information.

FHIR REST APIs typically communicate over HTTPS and support JSON or XML representations.

Common FHIR resources include:

• Patient
• Condition
• Observation
• MedicationRequest
• AllergyIntolerance
• CarePlan
• Goal
• Encounter
• Practitioner
• CareTeam
• DiagnosticReport
• DocumentReference

Each resource has a defined structure and may support interactions such as reading, searching, creating or updating information, depending on the capabilities of the FHIR server.

Why Integrate FHIR APIs with CCM Software?

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

Healthcare teams may need information from different clinical systems to manage medications, update treatment goals, coordinate specialist visits, and document ongoing care activities.

1. Reduce Manual Patient Data Entry

An authorized FHIR integration may allow a CCM application to import patient demographics and supported clinical information from an EHR.

2. Improve Access to Chronic Conditions

FHIR Condition resources can provide structured information about recorded diagnoses and chronic medical problems.

3. Support Medication Review

Medication-related FHIR resources may help care coordinators review prescriptions and other medication information during care management.

4. Support Comprehensive Care Plans

FHIR CarePlan and Goal resources can represent information relevant to care planning and patient treatment objectives.

5. Improve Clinical Coordination

Healthcare professionals may benefit from access to relevant clinical records across connected systems.

6. Reduce Fragmented Workflows

Integrating EHR and CCM systems can reduce repetitive information handling when the appropriate data, permissions and workflows are available.

HL7 FHIR Integration Architecture for CCM

A practical architecture separates the CCM application, integration service, authorization process and connected EHR or FHIR server.

Example Architecture

Healthcare EHR System → Authorized FHIR API → ASP.NET Core Integration Service → Clinical Data Validation and Mapping → CCM Database → Provider and Care Coordinator Workflows.

The integration service should communicate with the FHIR server through approved authentication and authorization mechanisms.

The application should not directly trust incoming clinical records without appropriate validation and patient matching.

Recommended Architecture Components

Step 1: Identify the EHR and FHIR Server

Before writing integration code, identify the EHR system that will provide clinical information.

Different EHR vendors expose different FHIR endpoints and integration capabilities.

Examples of healthcare platforms with FHIR-related integration offerings include Epic, Oracle Health, and other EHR vendors.

Integration availability may depend on application registration, customer agreements, vendor onboarding and the EHR's supported functionality.

Information Required Before Development

• FHIR base URL
• FHIR version
• Supported implementation guides
• SMART authorization configuration
• Application registration information
• Supported OAuth scopes
• Available FHIR resources
• Supported search parameters
• API limits and pagination behavior
• Sandbox or test environment

Do not assume every EHR exposes the same clinical information or supports identical API operations.

Step 2: Check FHIR Server Capabilities

FHIR servers expose a CapabilityStatement describing supported functionality.

A standard endpoint is:

GET https://example-ehr.test/fhir/R4/metadata

The response can describe supported resource types, interactions, search parameters and other implementation capabilities.

Developers should inspect the CapabilityStatement before relying on an API endpoint.

A resource type supported by one EHR may not be exposed by another EHR, and write operations may be restricted even when read operations are available.

Step 3: Discover SMART on FHIR Authentication

Many modern EHR integrations use SMART on FHIR authorization patterns based on OAuth 2.0.

SMART defines a discovery endpoint relative to the FHIR base URL:

GET https://example-ehr.test/fhir/R4/.well-known/smart-configuration

This endpoint can identify supported authorization and token endpoints, capabilities and security configuration.

Two Common Authorization Approaches

SMART App Launch: A user-facing application obtains delegated authorization, potentially using context from an EHR session or an approved standalone launch.

SMART Backend Services: An approved system-to-system application obtains access without an interactive user, subject to granted backend permissions.

For user-facing applications, Authorization Code with Proof Key for Code Exchange (PKCE) is an important security pattern.

Backend services may use asymmetric private-key JWT client authentication under supported SMART profiles.

The appropriate model depends on the EHR, authorized integration scenario and available vendor capabilities.

Step 4: Define FHIR API Permissions

SMART on FHIR uses OAuth scopes to specify requested permissions for FHIR resources and operations.

For example, SMART v2 scope expressions may include:

patient/Patient.rs
patient/Condition.rs
patient/Observation.rs
patient/MedicationRequest.rs

The rs suffix represents read and search permissions in the SMART v2 scope model.

Some integrations may instead use user-level or system-level scopes based on the authorization context.

Applications should request only the permissions appropriate to their intended purpose, and the EHR must support and grant the requested scopes.

Actual access remains subject to server authorization rules, patient context and other restrictions.

Step 5: Create an ASP.NET Core 8 FHIR Integration Service

ASP.NET Core 8 provides useful features for implementing healthcare integration services, including dependency injection, HTTP clients, configuration management and background processing.

A simple integration service can use HttpClient to request FHIR JSON resources from an authorized server.

Configure the FHIR Base URL

Store the approved FHIR endpoint in application configuration.

{
  "Fhir": {
    "BaseUrl": "https://example-ehr.test/fhir/R4/"
  }
}

This example uses a fictional endpoint. Replace it with the actual approved EHR FHIR base URL.

OAuth credentials, private keys and sensitive tokens should be stored through appropriate secret management rather than committed to source control.

Register the HTTP Client

ASP.NET Core supports typed HttpClient registration through dependency injection.

builder.Services.AddHttpClient<FhirCcmClient>(client =>
{
    var baseUrl = builder.Configuration["Fhir:BaseUrl"]
        ?? throw new InvalidOperationException("FHIR base URL missing");

    client.BaseAddress = new Uri(baseUrl);
    client.Timeout = TimeSpan.FromSeconds(30);
});

The configured base address should be an approved HTTPS URL and should end with a slash so relative FHIR paths resolve correctly.

Production implementations should validate configuration at startup and avoid accepting arbitrary FHIR server URLs from untrusted users.

Step 6: Build a FHIR Resource Retrieval Service

The following illustrative C# service retrieves Condition resources for a specified patient using an already authorized bearer token.

using System.Net.Http.Headers;
using System.Text.Json;

public sealed class FhirCcmClient(HttpClient http)
{
    public async Task<JsonDocument> GetConditionsAsync(
        string patientId,
        string accessToken,
        CancellationToken cancellationToken = default)
    {
        var path = $"Condition?patient={Uri.EscapeDataString(patientId)}&_count=50";

        using var request = new HttpRequestMessage(HttpMethod.Get, path);

        request.Headers.Authorization =
            new AuthenticationHeaderValue("Bearer", accessToken);

        request.Headers.Accept.ParseAdd("application/fhir+json");

        using var response = await http.SendAsync(
            request, cancellationToken);

        response.EnsureSuccessStatusCode();

        await using var stream = await response.Content.ReadAsStreamAsync(
            cancellationToken);

        return await JsonDocument.ParseAsync(
            stream, cancellationToken: cancellationToken);
    }
}

This example assumes that an authorized SMART OAuth workflow has already obtained a valid access token. The patient ID must also be validated against the authenticated user's permitted context.

Do not create an unauthenticated endpoint that accepts arbitrary patient identifiers or client-supplied bearer tokens.

A successful Condition search normally returns a FHIR searchset Bundle rather than a single Condition object. Applications must process its entries and any additional pages.

Step 7: Retrieve CCM-Relevant FHIR Resources

Once authorization is established, the integration may request supported clinical resources.

Patient Demographics

GET /Patient/123

The Patient resource may include identifiers, demographic information and contact details.

Chronic Conditions

GET /Condition?patient=123

Condition resources may contain recorded diagnoses and chronic medical problems.

Clinical Observations

GET /Observation?patient=123

Observation resources may include laboratory values, blood pressure measurements and other clinical findings.

Medication Orders

GET /MedicationRequest?patient=123

MedicationRequest resources describe medication orders or prescriptions. They do not independently establish medication adherence.

Care Plans

GET /CarePlan?patient=123

CarePlan resources may describe planned clinical activities and care coordination goals.

Clinical Encounters

GET /Encounter?patient=123

Encounter resources can provide relevant information about clinical interactions.

These examples use FHIR R4-style endpoints. Availability and behavior must be confirmed through the participating server's published capabilities and documentation.

Step 8: Map FHIR Resources to CCM Data Models

Most CCM platforms maintain application-specific database structures for patients, providers, care coordinators, diagnoses and care plans.

FHIR data should be mapped carefully into these structures rather than stored blindly.

Clinical terminology, dates, references, status values and identifiers should be validated during mapping.

Imported data may not be clinically complete or current. Appropriate review workflows remain important.

Step 9: Implement Reliable Patient Matching

Correctly matching an external EHR patient to an internal CCM patient is critical.

A common design maintains a mapping between the internal patient identifier, source system and external FHIR patient identifier.

Example Mapping Fields

• Internal CCM patient ID
• External FHIR patient ID
• EHR source identifier
• External identifier system and value
• Last successful synchronization
• Integration status

FHIR resource IDs are scoped to their respective servers. An identifier such as Patient/123 from one EHR does not necessarily refer to the same person on another FHIR server.

Patient matching should consider authoritative identifiers, duplicate detection and appropriate clinical review when ambiguity exists.

Never assume that a matching name or date of birth alone establishes patient identity.

Step 10: Design Patient Data Synchronization

Healthcare information can change frequently as clinicians update diagnoses, medications, observations and treatment plans.

A CCM integration should define when information is retrieved and how updates are processed.

Initial Synchronization

When an authorized patient is connected, the integration may retrieve relevant supported clinical resources and create appropriate internal associations.

Scheduled Synchronization

Where permitted, background processing may retrieve changes according to an approved schedule and applicable API limitations.

Event-Driven Synchronization

Some FHIR implementations support Subscription-based event notifications. Availability depends on server support, FHIR version and implementation requirements.

Synchronization Conflict Handling

Applications should define which system is authoritative for each data category and how conflicting changes will be reconciled.

Duplicate Prevention

Use source-system identifiers, resource identifiers and appropriate version information to avoid repeatedly creating duplicate clinical records.

Step 11: Handle FHIR Search Bundles and Pagination

FHIR search results are generally returned as Bundle resources.

Search responses can contain multiple matching resources and may be divided across pages.

The Bundle may provide a next link identifying another page of results.

Integration services should:

• Process resource entries by type.
• Validate the returned Bundle structure.
• Follow supported pagination links safely.
• Verify pagination URLs against trusted server configuration.
• Handle empty results.
• Handle access-denied responses.
• Support cancellation and reasonable request timeouts.
• Respect API limits and retry guidance.
• Prevent unbounded synchronization loops.

A single request using a count parameter does not guarantee retrieval of all available patient records.

Step 12: Handle FHIR API Errors

FHIR integrations should account for both standard HTTP errors and FHIR-specific error information.

FHIR servers may provide an OperationOutcome resource containing structured issue information.

Error handling should avoid exposing sensitive patient information, access tokens or unnecessary technical details in user-facing messages and application logs.

Step 13: Secure FHIR Integration Under HIPAA

FHIR standardizes information exchange, but it does not automatically make an application HIPAA compliant.

Healthcare organizations and business associates must evaluate applicable privacy, security and contractual requirements.

Authentication and Authorization

Use supported authorization flows and validate permissions for the actual patient and clinical workflow.

Protected Communications

Use appropriately configured HTTPS connections and evaluate applicable transmission security requirements.

Secure Token Management

Protect access tokens, refresh tokens and private keys. Avoid placing sensitive authentication material in logs or publicly accessible application configuration.

Access Controls

Enforce patient-level and organization-level authorization on the server, including appropriate practice, provider and care coordinator permissions.

Audit Controls

Maintain appropriate records of integration activity and access to electronic protected health information.

Data Storage Protection

Evaluate encryption, database access, backup protection and retention requirements.

Business Associate Agreements

Establish appropriate BAAs when a technology provider or subcontractor handles PHI on behalf of a covered entity or another business associate.

Risk Analysis

Conduct a HIPAA security risk analysis covering the integration architecture, involved systems, data storage and relevant operating procedures.

Important: Successfully connecting to a FHIR server does not independently demonstrate HIPAA compliance.

Step 14: Integrate FHIR Data into CCM Care Plans

Care planning is a central element of Medicare Chronic Care Management.

CMS describes requirements involving comprehensive care planning, ongoing care coordination and appropriate documentation.

FHIR can provide structured clinical information that may help support those workflows.

Example CCM Care Plan Workflow

1. Retrieve the authorized patient's recorded chronic conditions.
2. Retrieve relevant medication information.
3. Retrieve recent clinical observations when supported.
4. Review existing care planning information.
5. Present validated information to authorized care team members.
6. Allow qualified staff to develop or update the CCM care plan.
7. Maintain appropriate documentation and audit history.
8. Coordinate care plan information with other providers when permitted.

A FHIR CarePlan resource does not automatically satisfy all Medicare CCM care plan requirements. The actual clinical documentation and service delivery must meet applicable CMS rules.

Step 15: Connect FHIR Data with CCM Provider and Care Coordinator Workflows

Different healthcare roles may require different views and permissions within a care management application.

Practice-Level Administration

Authorized practice administrators may manage appropriate organizational settings, provider assignments and user permissions.

Provider Workflows

Healthcare providers may review relevant patient diagnoses, medication information, care plans and clinical observations.

Care Coordinator Workflows

Care coordinators may use appropriate clinical information to support patient outreach, medication review and ongoing care planning.

Permissions should be enforced by backend authorization policies. Hiding a patient from a dropdown does not by itself prevent unauthorized API access.

Practices should evaluate their role structure against HIPAA requirements, organizational policies and clinical responsibilities.

Step 16: Keep FHIR Integration Separate from CCM Billing Logic

FHIR integration and Medicare CCM billing serve different purposes.

FHIR supports the exchange of healthcare information. CCM billing requires the delivery and documentation of qualifying care management services.

Importing FHIR data does not automatically establish:

• Patient CCM eligibility
• Required CCM patient consent
• Completion of qualifying service time
• Required practitioner involvement
• Care plan completeness
• Billing readiness

These elements must be assessed using the actual clinical activities and current Medicare requirements.

Integration should improve the availability of clinical information without automatically converting imported records into billable care management activity.

Step 17: Test the FHIR Integration

Before deployment, evaluate the integration using an approved testing environment and synthetic patient information.

Functional Testing

• FHIR server connectivity
• CapabilityStatement retrieval
• SMART authorization workflows
• Patient resource retrieval
• Condition resource searches
• Medication information retrieval
• Observation handling
• CarePlan retrieval where supported

Data Quality Testing

• Patient identifier matching
• Terminology mapping
• Missing or incomplete resource fields
• Duplicate records
• Conflicting clinical information
• Timezone and date interpretation

Security Testing

• Invalid and expired tokens
• Insufficient OAuth scopes
• Cross-patient authorization attempts
• Cross-practice access restrictions
• Credential exposure prevention
• Audit logging

Reliability Testing

• Pagination
• Rate limiting
• Temporary server failures
• Retry behavior
• Synchronization recovery
• Duplicate prevention

Use authorized test servers and appropriate test data rather than exposing real patient records during development.

Common FHIR Integration Challenges

Different EHR Implementations

EHR vendors may support different FHIR versions, profiles, search parameters and API operations.

Missing Clinical Information

An EHR may not expose every clinical field required by the CCM application.

Complex Patient Matching

Multiple healthcare organizations may maintain separate identifiers for the same patient.

Terminology Differences

Clinical coding systems and local terminology may require careful mapping.

Limited Write Access

Some EHR APIs support reading data but do not permit third-party applications to create or update particular resources.

Authentication Complexity

Application registration, delegated authorization and backend service credentials may differ between vendors.

Synchronization and Data Quality

Organizations must handle stale information, duplicates, conflicting updates and partial synchronization failures.

Best Practices for Production FHIR Integration

• Begin with a small set of CCM-relevant FHIR resources.
• Verify each EHR's FHIR version and supported profiles.
• Use approved SMART authorization workflows.
• Request appropriate minimum permissions.
• Separate integration logic from clinical business logic.
• Maintain reliable internal and external patient mappings.
• Validate incoming resource data.
• Track the source and update history of clinical information.
• Process paginated responses correctly.
• Implement bounded retries and failure recovery.
• Maintain appropriate audit controls.
• Protect credentials and sensitive patient information.
• Use approved synthetic data for development testing.
• Review relevant HIPAA and BAA obligations.
• Verify all CMS CCM requirements independently of imported data.

FHIR R4 and US Core in 2026

FHIR R4 remains a widely implemented foundation for healthcare interoperability in the United States.

The published US Core Implementation Guide version 9.0.0 is based on FHIR R4 and defines U.S.-specific profiles and interactions for accessing important patient information.

SMART App Launch 2.2.0 provides published authorization guidance for integrating applications with FHIR-enabled systems.

Developers should use the exact implementation guide versions supported by their connected EHRs and distinguish published specifications from ballot or continuous-build materials.

How ChronicSync Can Fit into an Interoperable CCM Environment

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

As healthcare organizations evaluate interoperability, HL7 FHIR provides a standardized foundation for connecting compatible clinical systems.

FHIR-based integration can be considered when planning how a CCM application might retrieve supported EHR information, maintain appropriate patient associations and present clinical data to authorized care team members.

Practices evaluating ChronicSync should confirm which EHR integrations, FHIR capabilities and security arrangements are currently available before planning production use.

Explore ChronicSync and Request a Demo to learn more about digital Chronic Care Management workflows.

Frequently Asked Questions

What is HL7 FHIR API integration?

FHIR API integration connects compatible healthcare information systems using standardized FHIR resources and supported exchange operations.

How can FHIR APIs support Chronic Care Management?

FHIR can support authorized access to patient demographics, chronic conditions, medication information, clinical observations and care plans that may be relevant to CCM activities.

Can ASP.NET Core 8 integrate with FHIR servers?

Yes. ASP.NET Core 8 applications can connect to supported FHIR REST APIs using HttpClient, appropriate authentication mechanisms and healthcare data processing logic.

What is SMART on FHIR?

SMART on FHIR defines authorization and application integration patterns that allow approved clients to access FHIR-enabled healthcare systems.

Do all EHR systems support the same FHIR APIs?

No. Supported resources, FHIR versions, API operations and security requirements vary between EHR implementations.

Can FHIR retrieve patient diagnoses?

Yes. The Condition resource can represent diagnoses and clinical problems when supported by the connected system and permitted by authorization policies.

Can FHIR retrieve medications?

Yes. Medication-related resources such as MedicationRequest may provide relevant information when the EHR supports them.

Can FHIR retrieve care plans?

Yes, when the connected server supports the relevant CarePlan operations and appropriate access is authorized.

Does FHIR automatically synchronize patient records?

No. Synchronization requires application-specific logic for retrieving, validating, matching and updating information.

Does FHIR integration automatically make software HIPAA compliant?

No. HIPAA compliance requires separate administrative, physical, technical and contractual safeguards as applicable.

Can FHIR automatically calculate CCM billing time?

No. FHIR data exchange does not establish that qualifying CCM services or required time have been completed.

What is a FHIR CapabilityStatement?

A CapabilityStatement describes functionality supported by a FHIR server, including available resources, interactions and search capabilities.

Which FHIR version should CCM developers use?

Developers should select the version supported by their participating EHRs. FHIR R4 remains important for U.S. interoperability, including published US Core profiles.

Final Thoughts

Integrating HL7 FHIR APIs into Chronic Care Management software can create opportunities for more connected healthcare workflows.

For development teams using ASP.NET Core 8, FHIR REST APIs provide a standardized mechanism for exchanging clinical resources with compatible EHR systems.

Successful integration requires more than HTTP connectivity. Developers must address patient identity, clinical data quality, authorization, synchronization, vendor-specific requirements and applicable privacy safeguards.

FHIR integration should support clinical workflows while keeping Medicare CCM billing and compliance requirements independently satisfied.

Explore ChronicSync: www.chronicsync.com

Official Sources and References

• HL7: FHIR R4 Specification
• HL7: FHIR RESTful API
• HL7: US Core Implementation Guide
• HL7: SMART App Launch
• HL7: FHIR Patient Resource
• HL7: FHIR Condition Resource
• HL7: FHIR CarePlan Resource
• CMS: Chronic Care Management
• HHS: HIPAA Security Rule

Disclaimer: This article is for educational and technical information only. Code examples are illustrative building blocks and are not complete production integrations. EHR APIs, FHIR specifications, security obligations, and Medicare rules may change. Healthcare organizations should verify applicable requirements and obtain appropriate technical, clinical and compliance reviews before using patient information.