Executive Summary
CMS-0057-F, "Advancing Interoperability and Improving Prior Authorization Processes," requires impacted payers to implement four standards-based FHIR APIs and to streamline prior authorization. The four APIs — Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization — share a common HL7 FHIR R4 foundation but serve different audiences. Prior authorization process reforms (response timeframes, specific denial reasons, and public metrics) have applied since January 1, 2026; the four API requirements are due January 1, 2027. The rest of this page summarizes who is covered, the APIs, the standards, and the deadlines, and links onward to detailed guidance.
Effective & Compliance Dates
In effect — Jan 1, 2026
Prior authorization process requirements: 72-hour (urgent) / 7-day (standard) decision timeframes, specific denial reasons, and public PA metrics reporting (except QHP timeframe exemptions). See what's in effect in 2026.
Due — Jan 1, 2027
The four FHIR APIs must be live: Patient Access (with PA data), Provider Access, Payer-to-Payer, and Prior Authorization. Managed care and QHP issuers phase in by rating/plan year on or after this date. See the compliance timeline.
CY 2027 performance period
New "Electronic Prior Authorization" measures begin under MIPS Promoting Interoperability and the Medicare Promoting Interoperability Program (yes/no attestation).
The Four Interoperability Areas at a Glance
All four required APIs are FHIR APIs served by a shared payer interoperability capability. This is the mental model to hold before diving into any one API.
What Is CMS-0057-F?
CMS-0057-F is a federal final rule published by the Centers for Medicare & Medicaid Services (CMS) in January 2024. Its full title is "Advancing Interoperability and Improving Prior Authorization Processes" and it amends 42 CFR Parts 422, 431, 435, 438, 440, 457, and 45 CFR Part 156 (RIN 0938-AU87).
The rule builds on the 2020 CMS Interoperability and Patient Access final rule (85 FR 25510) by establishing new API mandates, accelerating prior authorization decision timelines, and requiring public transparency reporting. CMS received nearly 900 public comments on the proposed rule and finalized with modifications in response.
Who Must Comply?
CMS identifies 365 parent payer organizations spanning six categories of "impacted payers":
Excluded: Stand-alone dental plan (SADP) issuers, FF-SHOP-only issuers, and State-based Exchange (SBE/SBE-FP) issuers. Medicare FFS is not directly mandated but CMS has stated its intent to voluntarily comply.
The Four Mandated APIs
| API | Purpose | Key Data | Deadline |
|---|---|---|---|
| Patient Access API | Patient-facing data access via third-party apps | Claims, USCDI clinical data, prior auth info, lab results, cost-sharing | Jan 2027 (PA data enhancement) |
| Provider Access API | Provider access to patient data held by payers | Claims & encounters (no remittances), USCDI, prior auth info | Jan 2027 |
| Payer-to-Payer API | Automated data exchange when patients change plans | 5 years of claims, USCDI, prior auth info; quarterly concurrent exchange | Jan 2027 |
| Prior Authorization API | Electronic PA requirements discovery, docs, and submission | PA requirement check, documentation rules, request submission & decision | Jan 2027 |
Prior Authorization Process Reforms (2026)
Mandated Response Times
72 hours for urgent/expedited PA requests and 7 calendar days for standard requests. Applies to all impacted payers except QHP issuers on the FFEs.
Specific Denial Reasons
Payers must include a specific reason in every PA denial notice sent to providers. Generic or boilerplate denial language is no longer compliant.
Public Metrics Reporting
All impacted payers must publicly report PA approval/denial rates, response times, and related metrics — creating unprecedented transparency in the PA process.
API Usage Reporting to CMS
Payers must report Patient Access API utilization metrics to CMS annually, including the number of unique patients accessing data through third-party apps.
Technical Standards Required
HL7 FHIR R4.0.1
Base interoperability standard for all four APIs. Codified at 45 CFR 170.215(a)(1).
US Core IG STU 3.1.1
FHIR profiling for US healthcare data. Expires Jan 1, 2026. 45 CFR 170.215(b)(1)(i).
SMART App Launch 1.0.0
OAuth 2.0-based authorization framework for patient-facing apps. 45 CFR 170.215(c)(1).
Bulk Data Access v1.0.0
FHIR Bulk Data (Flat FHIR) for large-scale data retrieval. 45 CFR 170.215(d)(1).
OpenID Connect Core 1.0
Identity layer for patient authentication. 45 CFR 170.215(e)(1).
USCDI v1 → v3
Content standard at 45 CFR 170.213. USCDI v1 expires Jan 2026; auto-updates as ONC adopts new versions.
Projected Impact
$16 Billion+ in Savings
CMS estimates provider burden will be reduced by at least $16 billion over 10 years through streamlined PA processes and automated data exchange. Savings accrue to clerical, nursing, and clinical provider staff.
220 Million Hours Saved
Total provider burden reduction of at least 220 million hours over 10 years — time currently spent on phone-based PA submissions, fax chasing, and manual data retrieval from payer portals.
EHR Adoption Baseline
The rule leverages existing EHR infrastructure: as of 2021, 78% of office-based physicians and 96% of non-federal acute care hospitals had adopted certified EHR technology, and over $38 billion in incentives had been paid through Promoting Interoperability programs.
Significant Regulatory Action
OMB/OIRA determined the rule has an annual effect exceeding $200 million, classifying it as a significant regulatory action and a major rule under the Congressional Review Act.
What's Excluded?
Key Regulatory References
This Rule
CMS-0057-F (RIN 0938-AU87). Amends 42 CFR Parts 422, 431, 435, 438, 440, 457 and 45 CFR Part 156.
Proposed Rule
Published December 13, 2022 in the Federal Register (87 FR 76238).
2020 Foundation Rule
CMS Interoperability and Patient Access final rule (85 FR 25510, May 1, 2020). Established the original Patient Access API mandate.
ONC HTI-1 Final Rule
Published January 9, 2024 (89 FR 1192). Reorganized 45 CFR 170.215 technical standards structure referenced by CMS-0057-F.
Implementation Implications for Payers
The rule mandates API outcomes and standards, not a specific internal architecture. In practice, most impacted payers converge on a layered approach: a FHIR API gateway with OAuth (SMART App Launch for patients, SMART Backend Services for systems), an interoperability layer for mapping, terminology, consent, and provenance, and adapters into existing core administration platforms. A few implications follow directly from the rule:
- One data layer, several audiences. The same member data must be projected into FHIR for patients, providers, and other payers — build it once, authorize it differently.
- Don't expose the core database directly. Conformant profiles, terminology, consent, and scoping require a governed projection, not a raw database façade.
- Adapters are an integration concern. Core platforms such as QNXT, Facets, or HealthEdge typically need an adapter layer to bridge to Da Vinci FHIR profiles.
- Process rules apply regardless of channel. The 2026 timeframes and specific-denial-reason requirements are satisfied by workflow, not just by shipping an API.
For depth, start with FHIR for CMS-0057-F, then CRD, DTR and PAS and CMS-0057-F with QNXT.