CMS Interoperability: Empowering Providers with Seamless Access to Patient Data

Introduction

The Provider Access API enables seamless access to patient health data for providers who have both a contractual relationship with the payer and a treatment relationship with the patient. Under the CMS-0057-F Final Rule, impacted payers are required to make the following data available through this API: claims, encounters, and prior authorization information similar to what is shared via the Patient Access API.

To comply, payers must implement and expose a set of FHIR R4-based APIs that allow authorized providers to retrieve this information securely and efficiently. Additionally, payers must clearly communicate to patients how their data is being shared through the Provider Access API, the benefits of such sharing (e.g., improved care coordination), and inform them of their right to opt-out, including instructions on how to do so in plain, understandable language. These requirements must be implemented by January 1, 2027.

Scenario

Dr. James Smith, a primary care physician at Grace Hospital, has recently begun treating a new patient, Jack Shaw, who is currently covered by the UnitedCare Health Plan.

Jack has a complex medical history and has received care from multiple clinicians and hospitals over time. To make informed clinical decisions, Dr. Smith needs access to Jack's complete encounter history, including past hospital visits, provider interactions, and treatments. This information is retrieved through Jack's current insurer, UnitedCare, to ensure continuity of care and avoid unnecessary duplication of services.

Provider: Grace Hospital
Practitioner: Dr. James Smith
Patient: Jack Shaw
Insurer: UnitedCare Health

Workflow

Using the Provider Access API, as mandated by CMS-0057-F, Dr. Smith logs in to the EHR system at Grace Hospital and initiates a request to view Jack's historical encounter data.

Since Dr. Smith has both a contractual relationship with UnitedCare and a treatment relationship with Jack, access is permitted. The data retrieved includes encounters from multiple providers and facilities where Jack was previously treated. This information allows Dr. Smith to understand the patient's medical journey and make safe, informed clinical decisions without duplicating previous care efforts.

Figure 1: Sequence diagram of the Provider Access API workflow

Initiate Bulk Data Export

• Dr. James Smith logs into the EHR App to review patient Jack Shaw's clinical history.
• The EHR App triggers a request to the Bulk Data Client to initiate the retrieval of encounter data for the attributed patient.
• The Bulk Data Client sends an FHIR $export request to the UnitedCare FHIR Server, specifying the resource type (Encounter) and the patient (Jack Shaw).
• The FHIR Server processes the request, generates the corresponding NDJSON files containing encounter data, and stores them in the Output File Server.
• The FHIR Server responds with a Content-Location URL (status URL), which the client can use to poll for export completion.

Status Polling and Data Retrieval

• The Bulk Data Client periodically polls the status URL to check if the export is complete via the FHIR Server.
• Once processing is complete, the FHIR Server responds with a list of file URLs hosted on the Output File Server. These URLs point to the Encounter data files in NDJSON format.
• The Bulk Data Client downloads the Encounter data files from the Output File Server.

Sync to Local FHIR Server

• After retrieving the NDJSON files from the Output File Server, the Bulk Data Client sends them to the local FHIR Server deployed within the provider's environment. The FHIR Server then processes the files and transforms them into structured FHIR resources, such as Encounter records, making them available for querying by client applications.

Display Updated Encounter Data

• The EHR App fetches and displays Encounter data by querying the local FHIR server.
• The EHR presents Jack Shaw's updated Encounter history to Dr. James Smith, enabling him to make informed decisions based on the patient's previous hospital visits, treatments, and provider interactions.

Reference Implementation

Figure 2: Architecture diagram of the reference implementation

Dr. Smith logs into the EHR application, EHealth, to view the patient's historical Encounter data. He selects the patient, Jack Shaw, and requests access to their previous Encounter records. Behind the scenes, the Bulk Data Export Client, implemented using the WSO2 Accelerator for Healthcare, initiates a FHIR Bulk Data $export request to the FHIR Server of the payer, UnitedCare Health. This FHIR Server is connected to various systems of record, including databases, FHIR repositories, and claims systems.

The FHIR Server processes the request asynchronously and begins exporting the patient's Encounter data. The resulting data is stored in NDJSON format on an Output File Server. In response to the initial request, the FHIR Server returns a Content-Location (status URL) to the Bulk Data Client, which is used to monitor the status of the export operation.

The Bulk Data Client periodically polls the status URL. Once the export is complete, it receives the file URLs hosted on the Output File Server, downloads the NDJSON files, and syncs the data with the local FHIR Server deployed on the provider side. The EMR App can then query the local FHIR Server to retrieve and display John Smith's Encounter data within the EHealth application.

Core Components

The core components required for the above scenario are outlined below.

Provider side

Payer side

A complete reference implementation for the Provider Access API scenario has been built using the WSO2 Accelerator for Healthcare. This implementation demonstrates key components of the Provider Access API, including FHIR Bulk Data Export using the Bulk Data Export Client and the secure retrieval of historical patient data from the payer. It is publicly available on GitHub and includes a hosted demo setup, allowing users to experience the complete end-to-end workflow. The demo features an EMR App for provider access and a frontend application for patient-driven data sharing, offering a comprehensive view of how the system supports CMS-0057-F compliance.

The video below will provide a walkthrough of the demo setup.