CMS-0057-F: Complete 2026-2027 Compliance Guide for US Health Plans

CMS-0057-F’s operating deadline on January 1, 2026, has passed. If your health plan hasn’t already implemented speedier prior authorization turnaround times, specific refusal notices, and Patient Access API metric reporting, you are currently out of compliance. 

And the January 1, 2027, API deadline is moving faster than most compliance teams planned for. CMS-0057-F, the Interoperability and Prior Authorization Final Rule, isn’t another administrative checkbox.  It’s the most significant structural change to payer data exchange and utilization management since HIPAA’s Administrative Simplification provisions were established. 

The rule touches every part of your organization: IT infrastructure, utilization management, member services, provider relations, legal, and compliance.

And while most compliance officers know the headline deadlines, very few have mapped the full operational and technical scope of what’s actually required, layer by layer, by each deadline.

This guide does that. After reading, your team will know:

• Exactly which health plans are affected (and which aren’t)
• The full breakdown of what was due January 1, 2026, versus January 1, 2027
• The four mandated FHIR APIs and what each one must actually do
• The March 31, 2026, public reporting requirements that your plan may have already missed
• The CMS-0062-P proposed rule that extends everything to drugs by October 2027
• The non-compliance consequences that your legal and compliance team need to understand

What Is CMS-0057-F?

The Interoperability and Prior Authorization Final Rule, formally known as CMS-0057-F, was released on January 17, 2024, by the Centers for Medicare and Medicaid Services.

The regulation supplements CMS’s fundamental 2020 Interoperability and Patient Access rule (CMS-9115-F) by considerably expanding data sharing and prior permission requirements for federally regulated health plans. At its core, CMS-0057-F does two things:

1. It mandates four new FHIR-based APIs that health plans must build, operate, and maintain to enable data exchange with patients, providers, and other payers.
2. It overhauls prior authorization by requiring faster decision timelines, mandatory denial specificity, full electronic PA submission capability, and public reporting of PA metrics.

CMS projects this rule will generate $15 billion in savings over 10 years as prior authorization moves from fax machines and phone queues to standardized electronic workflows.

The data validates that urgency.

Physicians currently handle approximately 43 prior authorization requests per week and spend roughly 12 hours on them, time pulled directly from patient care. CAQH data shows electronic standards save approximately 14 minutes per authorization and could deliver $515 million in annual industry savings.

And yet: 89% of Medicaid enrollees do not appeal prior authorization denials, according to a 2023 OIG report, often because denial notices are too unclear to act on.

CMS-0057-F directly targets all of this.

Which Health Plans Are Impacted (and Which Are Exempt)

Before your compliance team can create an implementation plan, they must first validate that your organization is a covered impacted payer.

Impacted Payers, Subject to All CMS-0057-F Requirements

Plan Type	Coverage
Medicare Advantage (MA) Organizations	Part C health plans, including MAPD and SNPs
State Medicaid Fee-for-Service Programs	Direct Medicaid FFS is administered by states
CHIP Fee-for-Service Programs	Direct CHIP FFS administered by states
Medicaid Managed Care Organizations (MCOs)	Medicaid MCOs under contract with states
CHIP Managed Care Entities	CHIP MCOs under state contract
QHP Issuers on Federally-Facilitated Exchanges (FFEs)	ACA Marketplace plans on healthcare.gov

QHP issuers on FFEs are excluded from the prior authorization decision timeframe requirements (72-hour expedited / 7-day standard). However, they are required to provide specific denial reasons and comply with public PA metrics reporting.

NOT Impacted, Exempt from CMS-0057-F

• Traditional Medicare (Part A/B fee-for-service)
• Commercial and employer-sponsored group health plans (unless they offer QHPs on an FFE)
• Medigap/Medicare Supplement plans
• Medicare Part D standalone prescription drug plans (PDPs)
• ERISA-governed self-funded employer plans

Critical Nuance: Delegated Risk Arrangements

If your Medicare Advantage plan delegated risk management to a downstream entity, such as a delegated utilization management vendor, capitated risk partner, or third-party administrator, CMS holds the primary plan responsible for ensuring compliance.

Why this matters:

The primary plan cannot omit data held by the delegated entity from its Patient Access, Provider Access, or Payer-to-Payer APIs. If Entity B paid claims on behalf of Plan A, that data must be accessible through Plan A’s API ecosystem.

Handoff protocols between primary plans and risk-bearing delegates must be auditable, time-stamped, and structured to support CMS’s prior authorization decision timeframes, even when the delegate performs the actual utilization review.

The January 1, 2026, Operational Compliance Requirements

The January 1, 2026, deadline covered the operational process requirements of CMS-0057-F, not the API infrastructure. These are live, enforceable obligations now. If your plan has not implemented them, this chapter is your immediate compliance remediation guide.

Requirement 1: Accelerated Prior Authorization Decision Timelines

Starting January 1, 2026, impacted payers must render prior authorization decisions within:

Request Type	Maximum Decision Timeframe
Standard (non-urgent) requests	7 calendar days
Expedited (urgent) requests	72 hours

Before CMS-0057-F: The Medicaid managed care standard was 14 calendar days for non-expedited requests. This rule cut that in half.

Note: KFF analysis confirmed that at least 18 states needed to update their standard timeframe requirements in state MCO contracts to align with the new 7-day federal ceiling.

These timelines apply regardless of the submission method, fax, portal, phone, or mail. A plan cannot claim a slower turnaround for non-electronic submissions.

For delegated utilization management arrangements, the plan must ensure that handoff protocols between the plan and its delegates operate within these timeframes. If a delegate fails to respond in time, escalation protocols, including potential auto-approval mechanisms, must be in place.

Requirement 2: Specific Denial Notices to Providers

Beginning January 1, 2026, impacted payers must provide a specific, detailed clinical reason for every prior authorization denial, regardless of how the request was submitted.

Vague denials are no longer acceptable.

Why does this matter operationally?

A 2024 MACPAC report found that plan members experience significant barriers to care due to unclear and difficult-to-understand denial notice language, and that plans themselves acknowledged this as a challenge.

CMS’s intent: reduce unnecessary resubmissions, decrease appeals volume from legitimate clinical mismatches, and build a record trail that supports compliance audits.

Your denial notice templates, clinical criteria language, and denial communication workflows all need to meet this standard.

Practical requirement: Your denial notices must convey the specific clinical criteria that were not met, not just a policy code or a category-level description.

Requirement 3: Patient Access API Metrics Reporting to CMS

Beginning January 1, 2026, impacted payers must annually report to CMS the following Patient Access API usage metrics:

• Number of unique users of the API in the reporting period
• Number of repeat users
• Frequency of API usage

The first report, covering calendar year 2025, was due March 31, 2026.

Annual reports covering the prior calendar year are due by March 31 of each subsequent year.

Are you already out of compliance?

If your organization did not submit the Patient Access API usage metrics report to CMS by March 31, 2026, covering CY 2025 data, you missed the first reportable deadline under CMS-0057-F.

Contact CMS’s Office of Burden Reduction and Health Informatics (OBRHI) immediately. Document your remediation steps and the timeline you have implemented to prevent recurrence.

Requirement 4: Public Reporting of Prior Authorization Metrics

Beginning March 31, 2026 (covering CY 2025 data), impacted payers must publicly post prior authorization performance metrics on their websites.

Required metrics include:

Metric Category	What Must Be Reported
Volume	Total PA requests received, by service category
Approvals	Number and percentage approved
Denials	Number and percentage denied, by reason
Appeal outcomes	Number of appeals filed and percentage overturned
Decision timeliness	Average and median decision time for standard and expedited requests
Extended reviews	Instances where the review extended beyond standard timeframes

This is a transparency mandate with public accountability built in.

Any patient, provider, regulator, employer, or advocacy organization can now benchmark your plan’s prior authorization performance against publicly available data.

Bottom line: Your PA metrics are now public record. If your approval turnaround times, denial rates, or appeal overturn rates are outliers, expect regulatory scrutiny and provider network friction.

The January 1, 2027 FHIR API Requirements — All Four Explained 

By January 1, 2027, impacted payers must have four FHIR-based APIs fully built, tested, and operational in production. This is not a sandbox requirement. It’s a live production mandate.

Here is exactly what each API must do, and why the implementation complexity is significant.

API 1: Patient Access API

CMS-0057-F expands the existing Patient Access API requirement from the 2020 rule to include prior authorization information.

What it must include by January 1, 2027:

• Adjudicated claims and encounter data (excluding provider remittances and enrollee cost-sharing).
• All USCDI v3 data elements (USCDI v1 expired January 1, 2026).
• New: Active and historical prior authorization status, decision dates, decision rationale, and associated details, for non-drug items and services.

Prior authorization data must be available to patients through third-party apps of their choosing, not only through your member portal. This requires a SMART on FHIR app authorization framework. 

CMS finalized a direct reference to 45 CFR 170.213, meaning the Patient Access API data content requirements automatically update as ONC adopts new USCDI versions, without requiring a new CMS rulemaking cycle. Payors must track unique users and repeat users and report these metrics to CMS annually by March 31.

API 2: Provider Access API

The Provider Access API is an entirely new requirement, there is no 2020 analog.

It enables in-network providers with an active treatment relationship to retrieve their patients’ data directly from the payer, without requiring the patient to initiate the request. What it must make available:

• Individual claims and encounter data (excluding provider remittances and cost-sharing).
• All USCDI v3 data elements.
• Prior authorization information for non-drug items and services (excluding denied PAs).

The operational complexity is in the governance requirements:

Payers must build and maintain a provider attribution process, a mechanism to verify that a treatment relationship exists between a requesting provider and a specific member before sharing data.

Attribution lists must be updated within one business day of a request or status change.

Members must have the ability to opt out of having their data shared via the Provider Access API. This opt-out process must be clearly communicated and operationalized.

Payers must deliver educational resources to both patients (explaining opt-out rights) and providers (explaining how to use the API) before go-live.

Unlike the Patient Access API, there is no patient-facing app involved. The burden is entirely on the payer to verify treatment relationships, manage opt-outs, and deliver timely updates. This is the most operationally complex of the four APIs.

API 3: Payer-to-Payer API

The Payer-to-Payer API enables data continuity when members switch plans.

When a member enrolls with a new plan, that plan must request the member’s data from their previous payer within one week of coverage start, if the member has opted in. The previous payer must:

• Provide all maintained patient data with dates of service within the prior five years.
• Deliver the data within one business day of receiving the request.
• Include claims, encounter data, USCDI data elements, and prior authorization history (excluding denied PAs and drug PAs).

For members with concurrent coverage (enrolled in two or more plans simultaneously), payers must exchange member data within one week of coverage start and at least quarterly thereafter.

The opt-in architecture:

Unlike the Provider Access API (which uses an opt-out model), the Payer-to-Payer API requires member opt-in consent. Payers must:

• Establish a process for gathering previous/concurrent payer information from members
• Implement a verified member consent mechanism
• Maintain auditable consent records
• Deliver educational resources explaining data sharing rights before enrollment

The delegation complexity:

If your plan delegates risk to a downstream entity, and that entity holds clinical or claims data for your members, your Payer-to-Payer API cannot omit that delegated data. The primary plan remains responsible for ensuring complete data exchange.

API 4: Prior Authorization API

The Prior Authorization API is the centerpiece of CMS-0057-F.

It replaces, or at a minimum electronically augments, the fax and phone-based prior authorization workflows that currently consume thousands of provider and payer staff hours annually.

What it must support:

1. Coverage requirement check: Does this item or service require prior authorization?
2. Documentation requirements discovery: What clinical documentation is needed for this request?
3. Electronic PA submission: Submit PA requests directly from EHR or practice management systems.
4. Electronic decision delivery: Receive approval decisions, denial reasons, or requests for additional information, digitally and within required timeframes.

Decision timeframes apply through this API:

• Standard requests: 7 calendar days
• Expedited requests: 72 hours

CMS has confirmed enforcement discretion for HIPAA-covered entities that implement FHIR-based PA workflows, meaning plans are not required to continue using the X12 278 standard as the back-end transmission mechanism for FHIR-based PA processes. All-FHIR PA workflows are permitted.

CMS has added a new “Electronic Prior Authorization” attestation measure to the Medicare Promoting Interoperability Program and the MIPS Health Information Exchange objective. Eligible clinicians and hospitals must attest to using the Prior Authorization API for at least one request beginning with the CY 2027 reporting period.

This directly ties provider payment incentives to the adoption of your Prior Authorization API.

Technical Standards and Implementation Guides — What’s Mandatory vs. Recommended

This is the section where many compliance teams get tripped up.

CMS mandates certain technical standards. It recommends specific implementation guides (IGs). Understanding the difference between mandatory and recommended prevents both over-engineering and non-compliance.

Mandatory Technical Standards

All four APIs must be built on these required foundations:

Standard	Requirement
HL7 FHIR R4 (v4.0.1)	Base interoperability standard for all APIs — 45 CFR 170.215(a)(1)
US Core IG STU 3.1.1	FHIR profiling for U.S. healthcare data — 45 CFR 170.215(b)(1)(i)
SMART App Launch IG 1.0.0	OAuth 2.0-based app authorization — 45 CFR 170.215(c)(1)
OpenID Connect Core 1.0	Identity layer for patient authentication — 45 CFR 170.215(e)(1)
USCDI v3	Content standard for all data elements (USCDI v1 expired January 1, 2026)
Bulk Data Access	Required for Provider Access panel-level (population) data exchange

USCDI v1 Expiration — Act Now:

USCDI Version 1 expired as an available content standard on January 1, 2026. If your Patient Access API is still mapping to USCDI v1 data elements only, your content standard is no longer compliant. You must upgrade to USCDI v3.

Recommended Implementation Guides

CMS strongly recommends the following HL7 Da Vinci and CARIN implementation guides. They are not yet required by CMS-0057-F, but CMS has explicitly stated it may require them through future rulemaking.

Update: CMS-0062-P (April 2026) proposes to make most of these required by October 1, 2027.

Implementation Guide	API Application
CARIN Blue Button IG 2.0.0/2.1.0	Patient Access
Da Vinci PDex IG STU 2.0.0/2.1.0	Patient, Provider, and Payer-to-Payer data exchange
Da Vinci Plan-Net IG	Provider Directory
Da Vinci CRD (Coverage Requirements Discovery)	Prior Authorization
Da Vinci DTR (Documentation Templates and Rules)	Prior Authorization
Da Vinci PAS (Prior Authorization Support)	Prior Authorization

Building to Da Vinci specs now, even though they’re currently recommended, not required, means your interoperability stack will be forward-compliant when CMS-0062-P finalizes requirements. Building to the minimum required standards today may require a costly rebuild in 2027.

CMS references ONC’s Inferno testing tool as the conformance testing mechanism for FHIR APIs against CMS-0057-F implementation guides. Your QA and API testing protocols should incorporate Inferno validation before go-live.

The Phased CMS-0057-F Compliance Roadmap for Health Plans

Here is the compliance implementation roadmap built around your actual deadlines, not a vendor’s generic timeline. This roadmap assumes your organization is working through the January 1, 2027, API compliance deadline.

Phase 1: Immediate Remediation — Operational Compliance Audit (Complete Now)

If you haven’t already confirmed the following as operationalized, stop and address these first.

Confirm January 1, 2026, operational requirements are live:

• PA turnaround times meet 7-day standard / 72-hour expedited thresholds for all submission methods
• Specific denial notices are issued to providers for all PA denials (not just coded policy references)
• Patient Access API usage metrics were captured for CY 2025 and reported to CMS by March 31, 2026
• CY 2025 PA performance metrics were published on your plan website by March 31, 2026

If any of these are not confirmed:

Document the gap, implement remediation, and contact your CMS regional office. Proactive disclosure and documented corrective action typically produce more favorable regulatory outcomes than discovered non-compliance.

Phase 2: API Architecture and Vendor Selection (Q2–Q3 2026)

The clock for January 1, 2027, API compliance requires production-ready systems, not proofs of concept, by year-end.

Immediate priorities:

FHIR Infrastructure Assessment

Audit your current interoperability stack:

• Is your existing Patient Access API running on FHIR R4 (v4.0.1)?
• Have you upgraded from USCDI v1 to USCDI v3 as your content standard?
• Do you have SMART on FHIR (OAuth 2.0) app authorization operational?

If you built a CMS-9115-F (2020 rule) compliant API, you likely have a starting point. But the expansion to include prior authorization data, the new Provider Access architecture, the consent management requirements, and the Payer-to-Payer data exchange are all net-new builds.

Vendor Selection Criteria

When evaluating FHIR API platforms and implementation partners, confirm:

• Native FHIR R4 infrastructure (not a FHIR translation layer over legacy systems)
• Validated support for all four mandated APIs
• Support for recommended Da Vinci IGs (CRD, DTR, PAS, PDex)
• SMART on FHIR and OAuth 2.0 app authorization framework
• Bulk Data Access capability for Provider Access population-level exchange
• Built-in consent management and patient opt-out workflows
• Provider attribution logic and 1-business-day update SLA capability
• Uptime monitoring, security audit logging, and scalable API performance
• ONC Inferno testing tool conformance validation

Data Strategy Decision

How will your plan aggregate member data from delegated entities for Payer-to-Payer responses?

Choose your architecture early:

• Centralized data lake: Consolidate all claims, clinical, and PA data from delegates into a single FHIR-native store. Highest upfront investment, cleanest API response architecture.
• Dynamic federation: Primary plan API queries delegate systems in real-time on member requests. Lower upfront cost, higher latency risk, and more complex failure management.
• Streaming FHIR subscriptions: Delegates publish finalized claim and clinical events to the plan’s FHIR store using subscription triggers. Balanced approach with real-time-ish data freshness.

Phase 3: Build, Test, and Provider Enablement (Q3–Q4 2026)

Build priority sequence:

1. Patient Access API enhancement: Add prior authorization data to the existing FHIR API. Test with ONC Inferno. Validate USCDI v3 data completeness.
2. Provider Directory API (if not already live from the 2020 rule), Confirm 30-day update cadence is operational.
3. Prior Authorization API: Build CRD (coverage check), DTR (documentation requirements), PAS (submission and response) workflow. Integrate with your UM/utilization management platform. Validate 72-hour expedited / 7-day standard decision routing.
4. Provider Access API: Build attribution process. Implement opt-out consent capture and member notification workflow. Test bulk data access for panel-level provider queries.
5. Payer-to-Payer API: Build opt-in consent capture. Implement the previous/concurrent payer data request workflow. Test 1-business-day response SLA. Validate 5-year data lookback completeness.

Provider enablement, don’t leave this to the last quarter:

Many providers are still adjusting to electronic submission workflows. Your Prior Authorization API only delivers ROI if providers actually adopt it.

Segment your provider network by:

• PA request volume (high-volume specialties first: oncology, orthopedics, behavioral health, imaging).
• EHR system (identify which EHR vendors are building CRD/DTR/PAS integrations, and align your rollout with their readiness).
• Current submission method (fax-heavy providers need more onboarding support).

Launch provider education, sandbox access, and API registration documentation by Q3 2026, not Q4. 

Phase 4: Pre-Compliance Testing and Go-Live (November–December 2026)

Pre-production testing requirements:

• All five APIs must complete ONC Inferno conformance testing against the recommended IGs.
• Load testing: simulate open enrollment volume on Payer-to-Payer API (most stress-intensive period).
• Security penetration testing on all API endpoints.
• Consent management audit: verify all opt-in/opt-out workflows produce auditable records.
• Member notification delivery audit: verify educational resource delivery for Patient Access, Provider Access, and Payer-to-Payer APIs.

January 1, 2027, go-live readiness:

• All four FHIR APIs are live in production (not staging or sandbox).
• API uptime monitoring is operational with alerting.
• PA metrics tracking is confirmed live for 2026 full-year data (due March 31, 2027).
• Compliance reporting infrastructure is in place for annual CMS submissions.
• Provider help desk and API support resources are published.

Related: Healthcare Security & Compliance: HIPAA, Risk Management & Audit Readiness

CapMinds: Your End-to-End CMS-0057-F Compliance Service Partner

Navigating CMS-0057-F alone is complex, costly, and time-sensitive. 

CapMinds delivers the complete digital health technology services your health plan needs to meet every deadline, from operational remediation to full FHIR API production readiness.

Our compliance-focused services include:

• FHIR R4 API Development Service: Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs built to production-ready standards
• Prior Authorization Workflow Modernization Service: Electronic PA submission, denial notice redesign, and 72-hour/7-day decision routing
• USCDI v3 Data Migration Service: Seamless upgrade from legacy v1 content standards with full data integrity validation
• Da Vinci IG Implementation Service: CRD, DTR, PAS, and PDex implementation guide build-out for forward compliance
• Consent & Attribution Management Service: Opt-in/opt-out workflows, provider attribution logic, and auditable consent recordkeeping
• CMS Public Reporting & Metrics Service: PA performance dashboards, annual reporting infrastructure, and CMS submission support
• And More: EHR integration, ONC Inferno testing, provider enablement, and interoperability consulting

Don’t let compliance gaps become regulatory risk. Partner with CapMinds to modernize your health plan infrastructure with confidence, on time, every time.

Book a 1:1 Consultation Call with our Expert Team

Frequently Asked Questions

Which health plans must comply with CMS-0057-F?

CMS-0057-F applies only to health plans regulated by CMS under Medicare, Medicaid, or CHIP authority. The final rule defines the following “impacted payers”: The Federally Facilitated Exchanges include Medicare Advantage businesses, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan issuers. Other health insurance issuers and workplace health plans are not subject to these regulations. The only commercial payers affected are QHPs offered on the FFEs. 

What are the major compliance deadlines under CMS-0057-F?

There are two main dates:

• Prior authorization turnaround time requirements and explicit denial reasons will take effect on January 1, 2026. Payers have also begun providing Patient Access API results to CMS on a yearly basis.
• March 31, 2026: Impacted payers must publish prior authorization metrics for calendar year 2025 on their public-facing websites, including approval/denial rates, appeal outcomes, and average decision timeframes.
• January 1, 2027: All four FHIR APIs must be fully built and operational.

What APIs are required under CMS-0057-F?

CMS-0057-F requires impacted payers to implement three new FHIR APIs, the Provider Access API, Payer-to-Payer API, and Prior Authorization API, and also requires updates to the existing Patient Access API to include prior authorization data. All four must be live by January 1, 2027. 

How does CMS-0057-F change prior authorization?

It makes three key changes: payers must adhere to rigorous decision turnaround times, publish explicit information regarding prior authorization denials regardless of how the request was submitted, and publicly report yearly PA metrics on their websites.

The rule also mandates payers to use an FHIR-based Prior Authorization API to facilitate fully electronic PA submissions, which will replace phone and fax operations. Drugs are excluded from both the PA API and the process requirements because the standards and decision timeframes for drug prior authorizations differ from those for medical items and services. 

What are the new prior authorization turnaround time requirements?

Impacted payers, excluding QHP issuers on the FFEs, must send decisions within 72 hours for expedited (urgent) requests and seven calendar days for standard (non-urgent) requests. These timeframes apply regardless of how the request is submitted, payers cannot claim slower timelines for faxed requests. These requirements took effect January 1, 2026.