CMS Interoperability Rules Overview
CMS Interoperability Rules Overview
The Centers for Medicare and Medicaid Services (CMS) has issued two major interoperability rules that collectively define how covered payers must share health data using FHIR-based APIs. This article is the index and overview for those rules. Dedicated articles cover each API in depth.
- CMS-9115-F (2020 rule, 2021 compliance) — Interoperability and Patient Access Final Rule
- CMS-0057-F (2024 rule, 2026–2027 compliance) — Interoperability and Prior Authorization Final Rule
These rules are additive: CMS-0057-F built on CMS-9115-F rather than replacing it. Payers in scope must comply with all obligations under both rules.
CMS’s regulatory scope
CMS regulates federal healthcare programs and the insurance products offered through them. The interoperability rules apply to payers participating in:
- Medicare Advantage (MA) — private health plans approved to offer Medicare benefits
- State Medicaid fee-for-service (FFS) programs — state agencies operating Medicaid directly
- Children’s Health Insurance Program (CHIP) — FFS programs
- Qualified Health Plans (QHPs) on Federally Facilitated Exchanges (FFEs) — Marketplace plans under the ACA
Not covered:
- Fee-for-service Medicare (Traditional Medicare) — CMS operates its own data access programs (Blue Button 2.0) for this population
- Commercial/employer-sponsored group health plans — regulated under ERISA, not CMS interoperability rules
- Medicaid managed care organizations — subject to separate CMS regulations on managed care with different timelines
This scope is essential context. A payer offering both commercial employer-sponsored plans and MA plans is subject to these rules for the MA line, but not for the commercial line.
CMS-9115-F: Interoperability and Patient Access Final Rule (2020)
Published: March 9, 2020 (85 FR 25510) Compliance deadline: July 1, 2021
CMS-9115-F established the first generation of FHIR-based API mandates for covered payers. Its three primary requirements are:
Patient Access API
Covered payers must implement a FHIR R4 API that allows patients to authorize a third-party application (of the patient’s choosing) to retrieve their health data. The API uses SMART App Launch (authorization code grant) for patient authentication and consent.
Data required:
- Adjudicated claims and encounter data (CARIN Blue Button profiles on ExplanationOfBenefit)
- Clinical data in the payer’s possession (US Core profiles)
- Coverage information (FHIR Coverage resource)
See Patient Access API for complete technical detail.
Provider Directory API
Covered payers must implement a public-facing FHIR API exposing their network directory — which providers participate in each plan. The technical standard is the Da Vinci PDex Plan Net Implementation Guide.
The Provider Directory API is unauthenticated (no patient login required). It enables patients, other plans, and provider systems to query for in-network providers without prior arrangement.
Payer-to-Payer Data Exchange (initial version)
CMS-9115-F included an initial payer-to-payer data exchange requirement: when a patient switches plans, the new plan must request and the old plan must provide the patient’s data, upon patient request. This requirement used a different technical approach than the FHIR API mandates and was superseded by the v2 approach in CMS-0057-F.
CMS-0057-F: Interoperability and Prior Authorization Final Rule (2024)
Published: February 8, 2024 (89 FR 8758) Compliance: Staggered — January 1, 2026 and January 1, 2027
CMS-0057-F addressed three areas that were not covered or inadequately covered by CMS-9115-F: prior authorization, provider access to payer data, and longitudinal patient data portability across plans.
Prior Authorization API
Covered payers must implement a FHIR-based Prior Authorization API that allows providers to:
- Submit PA requests electronically via FHIR
- Query the status of pending PA requests
- Receive structured denial reasons (not just free-text)
The technical standard is the Da Vinci Prior Authorization Support (PAS) Implementation Guide, which uses FHIR Claim resources (with use: preauthorization) and ClaimResponse for decisions.
Compliance deadline: January 1, 2026
Separately from the API, CMS-0057-F also requires faster PA decision turnaround times:
- Urgent requests: within 72 hours
- Non-urgent requests: within 7 calendar days
- Post-service: within 30 calendar days
These turnaround requirements are not API mandates — they apply to the PA process regardless of submission channel.
Provider Access API
Covered payers must implement a FHIR-based API that allows a treating provider to request their attributed patients’ data from the payer — without requiring the patient to initiate the request. The treating relationship is the authorization basis.
The technical standard is the Da Vinci PDex (Payer Data Exchange) Implementation Guide with HREX (Health Record Exchange). Authorization uses SMART Backend Services (client credentials), not the patient-facing SMART authorization code flow.
Data required:
- Claims and encounter data (ExplanationOfBenefit)
- Clinical data (US Core profiles)
- Prior authorization data (Claim/ClaimResponse for active and pending PAs)
Compliance deadline: January 1, 2027
See Provider Access API for complete technical detail.
Payer-to-Payer Data Exchange v2
When a patient transitions from one covered plan to another, the new plan must request — and the old plan must provide — the patient’s longitudinal health data. This creates a portable data record that follows patients across plans, reducing the need to rebuild clinical and coverage history with each plan change.
The v2 approach uses FHIR and PDex, replacing the less technically specific initial requirement from CMS-9115-F. SMART Backend Services handles authorization between plans.
Compliance deadline: January 1, 2027
PA data in Patient Access API
CMS-0057-F required that prior authorization data (pending, approved, and denied — with structured denial reasons) be added to the existing Patient Access API. Patients can now retrieve their PA data through the patient-initiated SMART App Launch flow.
Compliance deadline: January 1, 2026
Public reporting of PA metrics
Beginning in 2026, covered payers must publicly report metrics on:
- Prior authorization volume (by service type)
- Approval and denial rates
- Average decision time
- Proportion of requests meeting the new turnaround requirements
This is a transparency mechanism, not an API requirement, but it creates accountability pressure that reinforces the other mandates.
Who is subject to both rules
| Payer type | CMS-9115-F | CMS-0057-F |
|---|---|---|
| Medicare Advantage | Yes | Yes |
| Medicaid FFS (state agencies) | Yes | Yes |
| CHIP FFS | Yes | Yes |
| QHP issuers on FFEs | Yes | Yes |
| Commercial/employer plans | No | No |
| FFS Medicare (Traditional) | No (CMS-operated separately) | No |
Compliance timeline
| Requirement | Rule | Deadline | Technical standard |
|---|---|---|---|
| Patient Access API | CMS-9115-F | July 1, 2021 | FHIR R4, SMART App Launch, CARIN Blue Button, US Core |
| Provider Directory API | CMS-9115-F | July 1, 2021 | FHIR R4, Da Vinci Plan Net IG |
| Payer-to-Payer v1 | CMS-9115-F | January 1, 2022 | Initial (superseded) |
| PA decision turnaround times | CMS-0057-F | January 1, 2026 | Process requirement (no API standard) |
| Prior Authorization API | CMS-0057-F | January 1, 2026 | FHIR R4, Da Vinci PAS IG |
| PA data in Patient Access API | CMS-0057-F | January 1, 2026 | FHIR R4, CARIN Blue Button + PAS |
| PA public reporting | CMS-0057-F | March 31, 2026 (first report) | CMS reporting portal |
| Provider Access API | CMS-0057-F | January 1, 2027 | FHIR R4, Da Vinci PDex + HREX |
| Payer-to-Payer v2 | CMS-0057-F | January 1, 2027 | FHIR R4, Da Vinci PDex |
Technical standards across both rules
CMS interoperability rules mandate a consistent technology stack built on FHIR R4 and the Da Vinci suite of Implementation Guides.
| Standard | Role |
|---|---|
| FHIR R4 | Base data exchange standard |
| US Core | Clinical data profiles (Condition, Observation, Procedure, etc.) |
| CARIN Blue Button | Claims data profiles (ExplanationOfBenefit, four types) |
| Da Vinci PDex | Payer-held data exchange (claims + clinical to providers/plans) |
| Da Vinci HREX | Base Da Vinci profiles and member match operation |
| Da Vinci PAS | Prior authorization request/response (Claim/ClaimResponse) |
| Da Vinci CRD | Coverage Requirements Discovery (payer coverage rules in EHR) |
| Da Vinci DTR | Documentation Templates and Rules (PA documentation in EHR) |
| Da Vinci Plan Net | Provider directory (payer network data) |
| SMART App Launch | Patient-facing OAuth2 (authorization code grant) |
| SMART Backend Services | System-to-system OAuth2 (client credentials) |
Da Vinci CRD and DTR are not directly mandated by CMS rules but are the natural complement to the PAS IG for end-to-end prior authorization automation. Many payers are implementing all three as a suite.
Penalties and enforcement
CMS-9115-F enforcement
CMS’s primary enforcement mechanism is public reporting of non-compliant payers. CMS publishes findings on payer compliance status, which creates reputational and market pressure. Civil monetary penalties are available under the statute but have been used sparingly for CMS-9115-F.
CMS has acknowledged that CMS-9115-F compliance quality has been uneven across the industry — particularly for Medicaid FFS programs, which faced implementation challenges. This experience informed a more enforcement-focused approach in CMS-0057-F.
CMS-0057-F enforcement
CMS has signaled a more active enforcement posture for CMS-0057-F, in part because the prior authorization context creates greater patient and provider visibility into non-compliance. Providers who encounter payers failing to meet the 72-hour urgent PA turnaround or failing to provide structured denial reasons have concrete, documentable grounds for a complaint.
Enforcement mechanisms:
- Public reporting — CMS publishes compliance findings
- Referral to relevant agency — CMS can refer non-compliance to HHS OIG or state regulators
- Civil monetary penalties — available under statute; CMPs are being more actively considered for CMS-0057-F
Relationship to ONC rules
CMS interoperability rules and ONC’s 21st Century Cures Act rules address the same underlying goal — open, standardized health data exchange — but through different regulatory levers targeting different entities.
| Dimension | CMS rules | ONC rules |
|---|---|---|
| Primary target | Payers (MA, Medicaid, CHIP, QHP) | Health IT developers (EHR vendors) and providers |
| Mechanism | Mandate specific APIs that payers must implement | Certification requirements + information blocking prohibition |
| Enforcement | CMS (public reporting, CMPs) | OIG (CMPs for IT developers), CMS (disincentives for providers) |
| Technical lever | FHIR API obligations | ONC Health IT Certification Program |
Payers subject to CMS rules use EHR and health IT vendor products that are themselves subject to ONC rules. A payer building a FHIR API typically uses certified health IT or interfaces with certified health IT. Both sets of rules apply in parallel.
See ONC 21st Century Cures Act Final Rule and Information Blocking Rule for the ONC side of the regulatory landscape.
Dedicated articles by topic
| Topic | Article |
|---|---|
| Patient Access API (patient-initiated data access) | Patient Access API |
| Provider Access API (provider-initiated data access) | Provider Access API |
| Prior authorization workflow (technical) | Prior Authorization Workflow |
| Payer-to-Payer data exchange | Payer-to-Payer Data Exchange |
| Information blocking rule | Information Blocking Rule |
| ONC 21st Century Cures Act Final Rule | ONC Cures Act Final Rule |