Custom Software

CMS Interoperability & Patient Access Rule Explained

CMS has issued a series of interoperability rules that fundamentally change how health plans share data with patients, providers, and each other. For payers — Medicare Advantage, Medicaid managed care, CHIP, and Qualified Health Plan issuers — these rules mandate FHIR-based APIs for patient data access, provider data sharing, payer-to-payer exchange, and electronic prior authorization. This guide covers every requirement, deadline, and technical implementation detail.

Calculate My Project Cost Connect With Experts

Tell Us Your Requirements

Our experts are ready to understand your business goals.

Trusted Partners

Trusted by Industry Leaders Worldwide

Recognition

Awards & Recognitions

Executive Summary

The CMS interoperability rules implement the 21st Century Cures Act vision for payer data access. The core principle: patients own their health data, and payers must make it accessible through modern, standardized APIs — not locked behind proprietary portals or inaccessible claims systems.

The rules span two major rulemaking actions:

CMS-9115-F (Interoperability and Patient Access Final Rule, 2020) — Established Patient Access API and Provider Directory API requirements for CMS-regulated payers.

CMS-0057-F (Interoperability and Prior Authorization Final Rule, 2024) — Expanded requirements to include Provider Access API, Payer-to-Payer Data Exchange API, and electronic Prior Authorization API with response time mandates.

Together, these rules require payers to build and maintain five distinct FHIR-based API capabilities — each with specific data content, technical standards, and compliance timelines.

Key Requirements and Deadlines

Patient Access API

CMS-regulated payers must maintain a FHIR R4 Patient Access API that allows members to access their data through third-party applications of their choice. Required data includes:

Claims and encounter data — Adjudicated claims for all covered services, including professional, institutional, pharmacy, and dental claims. Formatted as FHIR ExplanationOfBenefit resources conforming to the CARIN Alliance Blue Button implementation guide.

Clinical data — Any clinical data the payer maintains, formatted as USCDI-compliant FHIR resources. This includes diagnoses, medications, lab results, and clinical notes received from providers.

Coverage information — Plan enrollment, benefit details, and cost-sharing information formatted as FHIR Coverage resources.

Provider directory — Network provider information accessible through the FHIR endpoint.

The Patient Access API uses OAuth 2.0 authorization — members authenticate through the payer’s identity system and authorize third-party apps to access their data. This follows the same SMART on FHIR patterns used for EHR patient access.

Provider Access API

Payers must share patient clinical and claims data with in-network providers treating the patient — via a FHIR API. This supports care coordination by giving treating providers visibility into a patient’s complete claims history, medications, and coverage — not just the data from their own encounters.

The Provider Access API requires an attribution or treatment relationship verification mechanism — payers must have reasonable confidence the requesting provider has a treatment relationship with the patient before sharing data.

Payer-to-Payer Data Exchange

When a patient switches health plans, the new payer can request the patient’s data from the previous payer via FHIR API — with patient authorization. This prevents the “data cliff” that occurs when patients change plans and their claims history, prior authorization approvals, and clinical data become inaccessible.

Payer-to-Payer exchange includes claims, encounters, clinical data, and prior authorization decisions — ensuring continuity of coverage determinations across plan transitions.

Electronic Prior Authorization API

CMS-regulated payers must implement a FHIR-based electronic prior authorization API conforming to the Da Vinci PAS implementation guide. Requirements include:

Response time mandates — 72 hours for urgent requests, 7 calendar days for standard requests. These timelines are dramatically shorter than current industry averages.

Reason codes for denials — Payers must provide specific, coded reasons when denying prior authorization requests — enabling providers to understand why a request was denied and what additional information might support approval.

Public reporting — Payers must publicly report prior authorization metrics: approval rates, denial rates, average processing times, and appeal overturn rates by service category. This transparency is designed to discourage inappropriate denial practices.

Compliance Timelines

CMS has defined phased implementation timelines. Patient Access API requirements took effect in 2021 (CMS-9115-F). Provider Access API, Payer-to-Payer exchange, and Prior Authorization API timelines are defined in CMS-0057-F — with most requirements becoming effective in 2026–2027. Check the specific effective dates for your payer category (MA, Medicaid, CHIP, QHP).

Technical Implementation Details

FHIR Implementation Guides

CMS references specific FHIR implementation guides for each API:

CARIN IG for Blue Button — Defines FHIR profiles for ExplanationOfBenefit, Coverage, and Patient resources for Patient Access API.

Da Vinci PDex (Payer Data Exchange) — Defines profiles and operations for Provider Access and Payer-to-Payer data exchange.

Da Vinci PAS (Prior Authorization Support) — Defines the FHIR-based prior authorization request/response workflow.

Da Vinci CRD (Coverage Requirements Discovery) — Defines CDS Hooks services for surfacing coverage requirements at the point of ordering.

Da Vinci DTR (Documentation Templates and Rules) — Defines FHIR Questionnaire-based documentation collection for prior authorization.

API Infrastructure

Implementing CMS interoperability APIs requires:

FHIR server — A production-grade FHIR R4 server capable of serving claims, clinical, and coverage data at scale. Options include purpose-built FHIR servers (Smile CDR, HAPI FHIR, InterSystems) or FHIR facade layers over existing data stores.

API gateway — Managing authentication, authorization, rate limiting, audit logging, and traffic management for all API endpoints.

Authorization server — OAuth 2.0 / SMART on FHIR authorization for patient-facing APIs and provider-facing APIs with different authorization models (patient consent for Patient Access, treatment relationship for Provider Access).

Data transformation layer — Most payer systems store claims in proprietary formats (X12 837/835 data, internal claims databases). A transformation layer converts internal data representations into FHIR-compliant resources conforming to CARIN and Da Vinci profiles.

Consent management — Managing patient authorization for third-party app access (Patient Access), patient consent for payer-to-payer sharing, and treatment relationship verification for provider access.

Data Quality and Completeness

CMS APIs must provide complete and accurate data. Common challenges:

Claims data latency — Claims must be available via API within one business day of adjudication. Build near-real-time data pipelines from adjudication systems to the FHIR server.

Clinical data availability — Any clinical data the payer receives (from providers, HIEs, or other sources) must be available through the Patient Access API. Don’t limit the API to claims-only data.

Historical data — Patient Access APIs should provide meaningful historical depth — CMS has referenced the Blue Button 2.0 model of four years of claims history as a benchmark.

Compliance Checklist

Patient Access API:

FHIR R4 server operational with CARIN IG profiles

ExplanationOfBenefit, Coverage, Patient resources available

Claims data available within one business day of adjudication

OAuth 2.0 patient authorization implemented

Third-party app registration process documented and public

API documentation publicly accessible

How Taction Ensures Compliance

At Taction, our team builds CMS-compliant interoperability APIs for health plans, payer technology vendors, and managed care organizations.

What we do:

Patient Access API development — We build FHIR-based Patient Access APIs conforming to CARIN IG — transforming claims data, clinical data, and coverage information into compliant FHIR resources served through production-grade APIs.

Provider Access and Payer-to-Payer APIs — We implement Da Vinci PDex-compliant APIs for provider data sharing and payer-to-payer exchange — including treatment relationship verification and patient consent workflows.

Prior Authorization API — We build Da Vinci PAS-compliant prior authorization APIs with CRD and DTR integration — meeting CMS response time mandates and denial reason code requirements.

Data transformation pipelines — We build transformation layers that convert X12 claims data, internal adjudication records, and clinical data into CARIN and Da Vinci FHIR profiles at scale.

API infrastructure — We design and deploy the complete API stack — FHIR server, authorization server, API gateway, consent management, and monitoring — purpose-built for CMS interoperability compliance.