What CMS-0057-F Actually Requires
The CMS Interoperability and Prior Authorization Final Rule, designated CMS-0057-F, establishes specific FHIR API requirements for impacted payers including Medicare Advantage organizations, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan issuers on the Federally Facilitated Exchanges. The rule builds on the foundation established by the 2020 CMS Interoperability and Patient Access rule and extends its scope to prior authorization data, provider directory access, and payer-to-payer data exchange.
The rule mandates four distinct API implementations, each with its own FHIR profiles, data elements, and operational requirements. Understanding what each API must deliver — and the compliance timeline for each — is the prerequisite for any payer compliance program. Organizations that conflate these requirements or plan a single unified implementation without understanding the differences will encounter compliance gaps.
Non-compliance carries significant consequences. CMS has established a civil monetary penalty framework for payers that fail to meet the API requirements by the applicable deadlines. More significantly, failure to implement the Prior Authorization API affects star ratings for Medicare Advantage plans beginning in the measurement periods following the compliance deadline.
Patient Access API: Expanding the Mandate
The Patient Access API was established by the 2020 rule and required payers to expose a FHIR R4 API providing members access to their claims, clinical data, and formulary information. CMS-0057-F extends this requirement by mandating that payers also include prior authorization information in the Patient Access API, specifically prior authorization status, approval and denial records, and the clinical rationale for denied authorizations.
The authorization data must be accessible in a structured FHIR format using the appropriate resource profiles. Payers that implemented the original Patient Access API without planning for authorization data will need to extend their FHIR server capability statements, update their data pipelines from utilization management systems, and ensure that member-facing applications can surface this new data category in a clinically meaningful way.
The Patient Access API must also support SMART on FHIR authentication to allow third-party applications authorized by the member to access their data. Payers must maintain an application registration process and honor member authorizations for third-party data access, which introduces additional security and governance requirements around OAuth 2.0 scopes and token management.
Provider Access API and Payer-to-Payer Exchange
The Provider Access API is a new requirement under CMS-0057-F. It mandates that payers expose a FHIR bulk data API that allows in-network providers to retrieve claims, clinical, and prior authorization data for attributed patients without requiring individual member authorization for each request. This API uses the FHIR Bulk Data Access specification and must support Group-level export with appropriate attribution logic.
The Payer-to-Payer API requires that payers exchange member data when a member transitions between payer plans. When a new member enrolls and requests that their prior payer send data to the new payer, both payers must support a FHIR-based exchange that transfers five years of claims data, clinical data, and prior authorization information. This is operationally complex because it requires payers to implement both a data-sending capability and a data-receiving capability, with member consent verification and data normalization at the receiving end.
Implementing both APIs requires payers to resolve significant data governance questions. Which clinical data elements from the utilization management system are included in the Provider Access API response? How is attribution defined and updated? How does the payer-to-payer exchange handle data quality issues in the incoming feed from the prior payer? These questions require cross-functional governance that involves clinical, legal, privacy, and technology stakeholders.
Prior Authorization API and Timeline Requirements
The Prior Authorization API is the most operationally significant new requirement in CMS-0057-F. It mandates that payers support FHIR-based electronic prior authorization using the Da Vinci Prior Authorization Support (PAS) Implementation Guide. Providers submit authorization requests as FHIR bundles, and payers must respond with an authorization decision or a pending status within defined timeframes.
The rule also establishes specific decision timeframe requirements that are now statutory. Payers must provide decisions on urgent prior authorization requests within 72 hours and decisions on non-urgent requests within seven calendar days. These timeframes apply to all prior authorization requests regardless of the submission channel, but the FHIR API implementation must support automated decision logic capable of meeting these windows at scale.
The compliance timeline for the Prior Authorization API has specific effective dates that vary by payer type and API component. Implementation teams should verify current ONC and CMS guidance for precise milestone dates, as enforcement timelines have been subject to update. Building the implementation plan with regulatory deadlines as hard constraints — rather than aspirational targets — is essential for payer compliance programs that face star rating and penalty exposure.
Implementation Sequencing for Payer Organizations
Payer organizations that have not yet assessed their current FHIR infrastructure against CMS-0057-F requirements should begin with a gap analysis that maps each API requirement to existing system capabilities. Most payers find that their Patient Access API implementation requires extension, that the Provider Access API requires new bulk data infrastructure, and that the Prior Authorization API requires deep integration with their utilization management platform.
The sequencing of implementation work matters. Prior Authorization API work typically has the longest lead time because it requires UM platform integration, medical policy logic updates, and provider-facing testing with multiple EHR systems. Starting this workstream early, even while other API work is underway, reduces the risk of timeline compression as compliance deadlines approach.
Vendor selection for FHIR server infrastructure, terminology services, and UM integration middleware should account for the ongoing compliance trajectory beyond CMS-0057-F. ONC and CMS continue to expand FHIR-based interoperability requirements. Infrastructure built for CMS-0057-F compliance should be architected to accommodate future mandates without requiring a full platform replacement.