CMS-0057-F Interoperability and Prior Authorization Final Rule
Prepare for the 2026 operational requirements and the 2027 FHIR API deadlines—without turning compliance into a multi-year platform rebuild.
What CMS-0057-F requires
CMS-0057-F pushes the U.S. market to standardize data exchange and modernize prior authorization using FHIR-based APIs. The goal is to improve access to patient data for patients, providers, and payers, and to reduce the administrative burden of prior authorization with measurable process requirements.
Key takeaway: This is not only an IT project. It impacts member experience, provider network operations, UM/CM workflows, reporting, and compliance governance.
Who is impacted
CMS defines “impacted payers” broadly. If you operate any of the following, you should assume CMS-0057-F applies and confirm scope with your compliance team:
Medicare Advantage (MA) organizations
MA plans must implement and maintain the required APIs and related operational provisions.
Medicaid & CHIP (FFS and managed care)
Includes Medicaid/CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities.
QHP issuers on the Federally Facilitated Exchanges (FFEs)
QHP issuers on FFEs are included in the API requirements; note that some operational provisions differ by payer type.
Requirements and exact compliance dates can vary by payer type—this page summarizes the general timeline and major capabilities.
Compliance timeline: 2026 – 2027
2026: Operational provisions begin
- Prior authorization decision timeframes (urgent vs. standard)
- Denial reason requirements (specific reasons)
- Public reporting of prior authorization metrics (initial publication due March 31, 2026)
- Annual reporting on Patient Access API usage metrics to CMS
2027: API requirements go live
By January 1, 2027, impacted payers must implement the required API development and enhancements, including updates to Patient Access and new APIs (Provider Access, Payer-to-Payer, Prior Authorization).
What you need to deliver (CMS-0057-F capabilities)
The CMS-0057-F consists of several important interoperability impacts, including:
Patient Access API (expanded)
Payers organizations already expose claims/encounters via Patient Access. CMS-0057-F expands this by requiring impacted payers to add prior authorization information (excluding drugs) to the data available through that API.
Read More..
Provider Access API
CMS-0057-F requires impacted payers to implement a Provider Access API to share data with in-network providers who have a treatment relationship with the patient.
This must include:
- Claims and encounter data (excluding remittances and member cost-sharing details)
- USCDI data classes/elements
- Specified prior authorization information (excluding drugs)
Payer-to-Payer API
CMS-0057-F requires a Payer-to-Payer API to support data transfer when members change coverage, including:
- Claims and encounter data (excluding remittances and member cost-sharing details)
- USCDI data classes/elements
- Prior authorization information (excluding drugs)
- Data sharing limited to a 5-year lookback for date of service
Prio Authorization API (PARDD)
MS-0057-F requires impacted payers to implement and maintain a Prior Authorization API that:
- Is populated with covered items/services
- Can identify documentation requirements
- Supports request + response
- Communicates approval (including end date/circumstance), denial (with specific reason), or request for more information
Provider Directory API
The Provider Directory API is a policy that requires Medicare Advantage, Medicaid, and CHIP plans to make provider directory information available through a standards-based API. The API enables beneficiaries to find and select healthcare providers based on location, specialty, and other criteria.
Read more..
Prior authorization process requirements
CMS-0057-F is not just “build APIs.” It also sets process expectations.
Decision timeframes
Impacted payers (excluding certain payer types) must meet decision timeframes of:
- 72 hours for expedited/urgent requests
- 7 calendar days for standard/non-urgent requests
Denial reasons
Beginning in 2026, impacted payers must provide specific reasons for denied prior authorizations (non-drug), regardless of whether the request came in via API, portal, fax, etc.
Public metrics reporting
Impacted payers must publicly report certain prior authorization metrics annually by posting them on their website. Initial reporting is due March 31, 2026.
Interesting reads
If you would like to learn more about CMS-0057-F, or Prior Authorization specifically, take a look at our publications on these topics.
EBOOK
A Payers Guide to CMS-0057-F
To help you on your journey to CMS-0057 compliance, we have created this guide to provide you with a clear breakdown of required APIs, key deadlines and technical requirements, platform guidance, and a practical roadmap to achieve compliance.
Still want to read more? Visit our Knowledge Hub for more content.
How Firely Server helps—without rebuilding everything
- Enables incremental FHIR adoption (avoiding “rip and replace”)
Firely Server supports modular integration, allowing payers to gradually embed FHIR capabilities into their existing systems—reducing disruption, preserving prior investments, and aligning with phased CMS-0057-F compliance timelines.
- Streamlining compliance with CMS-0057-F
Firely Server helps payers meet CMS-0057-F requirements with a scalable FHIR platform that enables real-time data exchange and seamless integration into existing systems. With built-in support for US Core and Da Vinci guides, it accelerates compliance, reduces the need for deep FHIR expertise, and improves efficiency across prior authorization and other key workflows.
- Supports dual workflows across business lines
With flexible data modeling and API-driven architecture, Firely Server enables simultaneous support for both legacy processes and FHIR-based workflows, helping payers meet federal mandates without compromising commercial operations.
- Improves operational efficiency with scalable FHIR infrastructure
Firely Server reduces manual overhead through automation-ready FHIR APIs, high-performance data access, and seamless integration with existing clinical and administrative systems—streamlining prior auth and other workflows.
- Bridges FHIR expertise gaps with built-In compliance and tooling
Out-of-the-box support for US Core and Da Vinci implementation guides helps smaller payers accelerate adoption without needing deep in-house FHIR expertise, minimizing regulatory risk and shortening implementation timelines.
- Meets provider expectations for real-time data exchange
Firely Server’s robust FHIR APIs support fast, standards-based data sharing—empowering payers to offer timely responses for prior authorization and other transactions, improving provider collaboration and patient care outcomes.
Conclusion
As the healthcare landscape continues to evolve, payers must move beyond viewing FHIR as a regulatory checkbox and embrace it as a foundation for long-term transformation. Firely empowers health plans to adopt FHIR in a way that is scalable, secure, and aligned with business goals – without the need for disruptive overhauls. Whether you’re streamlining prior authorizations, enabling payer-to-payer data exchange, or meeting CMS mandates, Firely provides the trusted infrastructure and expert support to accelerate your interoperability journey with confidence.
Find out more about the Firely’s products and services for Payers
Connect with our team to discuss by filling out the following form.