What CMS-0057-F is about
The CMS-0057-F rule, Interoperability and Prior Authorization Final Rule, was finalized in January 2024 to advance health data exchange and modernize prior authorization across the U.S. healthcare system. It builds on CMS’s 2020 interoperability rule by requiring impacted payers (Medicare Advantage, Medicaid/CHIP, and certain Affordable Care Act plans) to implement four FHIR-based APIs that improve how patients, providers, and other payers can access and share data.
These APIs are designed to reduce administrative burden and put timely health information into the hands of those who need it. In summary, CMS-0057-F mandates the following FHIR APIs for payers, with compliance dates generally beginning on January 1, 2027 (depending on payer type):
- Patient Access API: Lets patients use third-party apps to view their health data — claims, encounters, USCDI clinical data, and prior authorization status. This helps members clearly see what was approved or denied and why.
- Provider Access API: Allows in-network providers to retrieve claims, encounters, USCDI data, and prior authorization info for their patients via FHIR, individually or in bulk. Requires accurate attribution lists and patient opt-out support.
- Payer-to-Payer API: Enables payers to exchange up to 5 years of claims, encounters, USCDI data, and prior auth history when a member changes plans. Requires patient opt-in and supports continuity of care.
- Prior Authorization API: Enables a full electronic prior authorization workflow. Providers can check if a service requires PA, see documentation requirements, submit requests electronically, and receive structured responses (approved, denied with reason, or needing more info). Also sets strict decision-time deadlines to speed up processing.
Together, these four APIs create a connected, FHIR-based ecosystem. A prior authorization decision made via the PA API becomes visible to patients, providers, and future payers through the other APIs. The goal of CMS-0057-F is to replace fax-based workflows with integrated digital exchange and keep patients at the center of care.
Who the rule impacts in practice
Formally, CMS-0057-F applies to payers, including Medicare Advantage organizations, Medicaid and CHIP managed care plans, and Qualified Health Plan issuers on the Federally Facilitated Exchanges.
Operationally, however, the rule affects a broader ecosystem of participants involved in payer data exchange, authorization workflows, and patient access to information. These processes rarely operate within a single system. In practice, the rule touches:
- Payers, who remain accountable for compliance even when operational responsibilities are delegated
- Providers, who are expected to retrieve payer data and interact electronically through standardized APIs and workflows
- Delegated administrators and technology vendors, including API and interoperability platforms, EHR vendors, clearinghouses, prior authorization and utilization-management systems, and integration middleware. These parties often participate in executing prior authorization workflows but do not carry regulatory ownership.
- Patients, who gain more access to their data and more control over how it is shared.
Timing constraints and architectural impact
January 1, 2026: operational requirements begin
By 2026, payers must implement measurable operational changes:
- faster prior authorization decision timeframes (72 hours urgent / 7 days standard for most impacted payers),
- specific denial reasons,
- and tracking for public reporting, with the first annual reporting cycle due March 31, 2026.
(Notably: QHP issuers on FFEs are excluded from the decision timeframe requirement, but still must report and provide specific denial reasons.)
January 1, 2027: API requirements go live
By 2027, payers must have:
- the expanded Patient Access API,
- Provider Access API,
- Payer-to-Payer API,
- and Prior Authorization API available and operational.
Architecturally, the effort is significant. Payers must upgrade their existing interoperability stack (for those already running the 2020 Patient Access API) or build new services to meet the expanded requirements. Key technical components include:
- FHIR R4 infrastructure and data mapping
All APIs use HL7 FHIR R4 (v4.0.1), so insurers must represent claims, clinical data, and prior auths as FHIR resources. Most will need to map legacy systems into FHIR and adopt US Core and USCDI for standardized exchange. SMART on FHIR (OAuth2/OpenID Connect) is required for secure, app-based authentication and consent.
- Bulk data and provider matching
Provider Access and Payer-to-Payer APIs require large data transfers, so CMS expects use of FHIR Bulk Data (Flat FHIR) and asynchronous exports. Payers must maintain accurate provider attribution lists and manage consent (opt-out for Provider Access, opt-in for Payer-to-Payer), which requires updated systems for tracking patient–provider relationships.
- Integration of prior auth systems
The PA API is the most complex because many payers still rely on batch systems or X12 278. CMS allows FHIR-only, X12-only, or hybrid models. Most will expose a FHIR API and translate requests into existing UM systems. Others may modernize to native FHIR. Either approach requires reliable real-time integration, workflow redesign, and feeding PA decisions back into member records used by other APIs.
- Use of Implementation Guides (IGs)
CMS recommends HL7 IGs to ensure interoperability. CARIN Blue Button supports claims for Patient Access; PDex and Plan-Net cover payer data and provider directories. For prior auth, Da Vinci CRD, DTR, and PAS define the ePA workflow. Aligning with these IGs reduces custom development and improves EHR integration.
How We Can Help
Health Samurai helps payers and their partners build CMS-0057-F readiness with minimal reinvention. Our Aidbox-based solution provides:
- FHIR R4-native platform infrastructure aligned with CMS-0057-F requirements
- Pre-built support for Da Vinci implementation guides (CRD, DTR, PAS, PDex)
- Consent management and provider attribution tooling for Provider Access and Payer-to-Payer APIs
- Bulk Data (Flat FHIR) export for payer and provider-facing data exchange
- FHIR/X12 integration frameworks for hybrid prior authorization workflows
- SMART on FHIR support (OAuth 2.0 / OpenID Connect) for secure app authorization
Aidbox handles the complex FHIR implementation details so your team can focus on workflows, governance, and meeting compliance deadlines. Reach out to review your CMS-0057-F readiness and define an implementation strategy that won’t require rebuilding under load.
