The Patient Access API is mandated in the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F). It expands previous data sharing policies (CMS-9115-F, 2020) and requires payers to make claim details and encounters, clinical and laboratory data, and prior-authorization data accessible through a secure FHIR-based API for patients in real-time via health applications of their choice. Impacted organizations include Medicare Advantage organizations, Medicaid managed care plans, Children’s Health Insurance Program managed care entities, State Medicaid and CHIP Fee-for-Service programs, and Qualified Health Plan issuers on the Federally Facilitated Exchanges. By January 1, 2026, they must report to CMS on metrics related to Patient Access API usage like the total number of unique patients who access their data and the frequency. Starting January 1, 2027, the Patient Access API must include prior authorization data (e.g., status, approval/denial dates, denial reasons) for patients to view.
We build APIs for EHR systems, patient portals, and mobile applications. Need help with API development or testing?
Let’s talk
Patient Access API
The patient access API was originally required to establish an API that allows members to access the following health information via a third-party application of their choice:
- claims and encounters
- provider remittances and enrollee cost-sharing information
- clinical data, including lab results, if maintained by the health plan
- formularies and preferred drug lists, and covered drugs in any tiered formulary structure or utilization management procedures (for Medicare Part C plans).
This Final Rule expands the required API data to include:
- information about prior authorizations (excluding drugs)
- it must be available via the API no later than one business day after data is received by the payer
- Patient historical data from January 1st, 2016, onwards must be made available
Now health plans must begin reporting annual metrics to CMS about patient access API usage in its current state. These metrics should be in the form of aggregated, de-identified data, summarizing patient use of the API.
Provider Access API
The Final Rule requires health plans to adopt a Provider Access API, which allows In-network providers to request patient information from the payer.
Patient data (claims and encounters, excluding provider remittances and enrollee cost-sharing information, USCDI data classes and elements, and prior authorization information, excluding drugs) must be available to the provider via the API.
The sharing of patient information requires health plans to maintain a provider attribution process, to associate patients with in-network or enrolled providers with whom they have a treatment relationship.
Additional requirements are as follows:
- Payers must allow patients to opt-out of having their data made available to providers.
- Payers are required to provide plain language to patients about the benefits of API data exchange and their ability to opt-out.
- Payers are required to provide plain language to providers about the attribution process and how to request patient data.
Payer-to-Payer data exchange
Health plans are required to implement and maintain an API to support the exchange of clinical data between health plans at the patient’s request. The result is an improved continuity of care when a patient changes health plans and continued access to their health records.
Health plans must establish and maintain processes for identifying previous and concurrent health plans and allow patients to opt into the data exchange.
The final rule requires health plans to comply with the following:
- Claims and encounters, excluding provider remittances and enrollee-cost sharing information, USCDI data classes and elements, and information about prior authorizations, excluding drugs, must be made available via the API within one business day after receiving a request from a health plan.
- Only historical data with a date of service within five years of the request for data is required.
- For members with multiple health plans, data must be exchanged within one week of the start of coverage and at least quarterly thereafter.
- Current members must be allowed to opt-in by January 1st, 2027; and new members within one week of coverage.
- Information received by other health plans must be integrated into the Patient and Provider Access APIs.
- Health plans must provide plain language information to patients that explains the benefits of the API and their ability to opt-in.
Prior Authorization process improvement and reporting
Alongside the API implementation described above, health plans will need to make changes to prior authorization processes beginning in January 2026.
First, payers must send prior authorization decisions within 72 hours for expedited (urgent) requests and 7 calendar days for standard (nonurgent) requests. Approvals must state the date approved or circumstances under which the authorization ends and denials must cite a specific reason for being denied. For items or services that are not subject to prior authorization rules, integrated health plans must send notice of its determination within 14 calendar days.
Second, health plans are required to report annual metrics about prior authorizations to CMS, beginning on March 31st, 2026, for the prior calendar year. These metrics include 4 standard prior authorization metrics, 2 expedited prior authorization metrics and turnaround time metrics for both standard and expedited requests. Further, an annual report must be made public, listing all services that require prior authorization.
Third, Merit-based Incentive Payment System (MIPS ) eligible clinicians, hospitals, or critical access hospitals (CAHs) are required to report a new attestation measure, the Electronic Prior Authorization measure, beginning in the CY 2027 performance period to be paid in the MIPS payment year, two years later (e.g., first payment in CY 2029).
How to Comply With the CMS Final Rule
Implement or Modernize your Health Data Management Platform
The CMS Interoperability and Prior Authorization Final Rule does not explicitly mandate a "Health Data Management Platform" by name, but it clearly requires payers to achieve the core functions such platforms provide to comply with the rule’s data consolidation and interoperability requirements.
Payers must aggregate and maintain five years of patient data (claims/encounters, clinical/laboratory data (via FHIR standards like US Core), prior authorization decisions (excluding drugs), and documentation supporting prior authorizations). This necessitates consolidating data from fragmented sources (EHRs, labs, pharmacies) into a single, FHIR-compliant repository—a core function of Health Data Management Platforms (HDMPs).
As payers must implement a Patient Access API that includes prior authorization data (approvals, denials, reasons), a Prior Authorization API that enables providers to submit/receive decisions directly from EHRs, and a Payer-to-Payer API to share historical data with other payers (with patient consent), HDMPs are also a helpful option here because they simplify API development by normalizing data into FHIR formats and automating exchanges.
As payers must report annual metrics on Patient Access API usage (unique users, demographics) and publicly disclose prior authorization approval/denial rates and appeal outcomes, HDMPs also support automated metric tracking and audit-ready reporting.
While CMS doesn’t prescribe specific tools, HDMPs address three gaps traditional systems cannot.
How Belitsoft Can Help
Belitsoft specializes in building custom, interoperable solutions, including health data management platforms tailored to healthcare data governance and compliance.
Let’s talk
We can collaborate with clients to support their implementation needs and long-term strategy, including the following:
- Analyze current data infrastructure. Understand current system capabilities, technology and business requirements.
- Implement the transformation. Provide end-to-end technical support for the implementation and managed services.
- Healthcare IT. Implementing HL7 & FHIR and prior final rules.
We rely on the following resources and standards:
- United States Core Data for Interoperability (USCDI)
- HL7® Fast Healthcare Interoperability Resources (FHIR®) Release 4.0.1
- HL7 FHIR US Core Implementation Guide (IG) Standard for Trial Use (STU) 3.1.1
- HL7 SMART Application Launch Framework Implementation Guide Release 1.0.0
- FHIR Bulk Data Access (Flat FHIR) (v1.0.0: STU 1)
- OpenID Connect Core 1.0
Interoperability compliance with the policies outlined in the Final Rule requires investment. However, health plans also have an opportunity to use the technology needed for compliance to align with value-based care goals. The industry is increasingly adopting value-based care payment models, and this growth is expected to continue in the coming years.
Rate this article
Recommended posts
Portfolio

Our Clients' Feedback













We have been working for over 10 years and they have become our long-term technology partner. Any software development, programming, or design needs we have had, Belitsoft company has always been able to handle this for us.
СEO at ElearningForce International (Currently Zensai) (United States/Denmark)