CMS-0057-F: Interoperability and Prior Authorization Final Rule - Firely

\n\n# CMS-0057-F Interoperability and Prior Authorization Final Rule\n\n---\n\nPrepare for the 2026 operational requirements and the 2027 FHIR API deadlines—without turning compliance into a multi-year platform rebuild.\n\nLet’s chat\n\nExplore our ePA use case\n\n\n\n## What CMS-0057-F requires\n\nCMS-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.\n\nKey takeaway: This is not only an IT project. It impacts member experience, provider network operations, UM/CM workflows, reporting, and compliance governance.\n\n## Who is impacted\n\nCMS 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: \n### Medicare Advantage (MA) organizations\nMA plans must implement and maintain the required APIs and related operational provisions.\n\n### Medicaid & CHIP (FFS and managed care)\nIncludes Medicaid/CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities. \n\n### QHP issuers on the Federally Facilitated Exchanges (FFEs)\nQHP issuers on FFEs are included in the API requirements; note that some operational provisions differ by payer type.\n\nRequirements and exact compliance dates can vary by payer type—this page summarizes the general timeline and major capabilities.\n\n## Compliance timeline: 2026 – 2027\n\n### 2026: Operational provisions begin\n- Prior authorization decision timeframes (urgent vs. standard)\n- Denial reason requirements (specific reasons)\n- Public reporting of prior authorization metrics (initial publication due March 31, 2026)\n- Annual reporting on Patient Access API usage metrics to CMS\n\n### 2027: API requirements go live\nBy 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).\n\n## What you need to deliver (CMS-0057-F capabilities)\n\nThe CMS-0057-F consists of several important interoperability impacts, including: \n\n### Patient Access API (expanded)\nPayers 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. \nRead More..\n\n### Provider Access API\nCMS-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.\n\nThis must include: \n- Claims and encounter data (excluding remittances and member cost-sharing details)\n- USCDI data classes/elements\n- Specified prior authorization information (excluding drugs) \nRead more..\n\n### Payer-to-Payer API\nCMS-0057-F requires a Payer-to-Payer API to support data transfer when members change coverage, including: \n- Claims and encounter data (excluding remittances and member cost-sharing details)\n- USCDI data classes/elements\n- Prior authorization information (excluding drugs)\n- Data sharing limited to a 5-year lookback for date of service \nRead more..\n\n### Prior Authorization API (PARDD)\nCMS-0057-F requires impacted payers to implement and maintain a Prior Authorization API that: \n- Is populated with covered items/services\n- Can identify documentation requirements\n- Supports request + response\n- Communicates approval (including end date/circumstance), denial (with specific reason), or request for more information \nRead more..\n\n### Provider Directory API\nThe 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. \nRead more..\n\n## Prior authorization process requirements\n\nCMS-0057-F is not just “build APIs.” It also sets process expectations. \n\n### Decision timeframes\nImpacted payers (excluding certain payer types) must meet decision timeframes of: \n- 72 hours for expedited/urgent requests\n- 7 calendar days for standard/non-urgent requests\n\n### Denial reasons\nBeginning 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.\n\n### Public metrics reporting\nImpacted payers must publicly report certain prior authorization metrics annually by posting them on their website. Initial reporting is due March 31, 2026.\n\n## Conclusion\n\nAs 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.