CMS-0057-F: what payers need live by January 1, 2027

The CMS Interoperability and Prior Authorization final rule (CMS-0057-F) was released in January 2024. Parts of it already apply, and the main API requirements arrive on January 1, 2027 for most impacted payers. This checklist summarises what the rule asks for and where teams usually get stuck.

Who the rule applies to

CMS calls them "impacted payers":

• Medicare Advantage organisations
• Medicaid and CHIP fee-for-service programs
• Medicaid managed care plans and CHIP managed care entities
• Qualified Health Plan issuers on the federally facilitated exchanges

Exact compliance dates vary by plan type. Medicaid and CHIP managed care dates, for example, follow rating periods, and Marketplace plans follow plan years. Confirm your own dates against the CMS rule page.

Already in force since January 2026

• Decision timeframes. Most impacted payers must decide expedited prior-auth requests within 72 hours and standard requests within 7 calendar days. CMS did not change these timeframes for Marketplace QHP issuers.
• Specific denial reasons. A denial must state a specific reason.
• Public metrics. Payers must publish prior-authorization metrics such as approval rates and decision times.

Due from January 1, 2027: four APIs

1. Patient Access API. Already required since 2021, now expanded to include prior-authorization information.
2. Provider Access API. Gives in-network providers access to their patients' claims, encounter and clinical data, plus prior-auth information.
3. Payer-to-Payer API. Moves a member's data when they change payers or have concurrent coverage.
4. Prior Authorization API. Lets providers find out whether authorization is needed, see documentation requirements, submit requests and get decisions electronically.

All four are FHIR-based. CMS recommends implementation guides including US Core, CARIN Blue Button and the Da Vinci guides: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) and Prior Authorization Support (PAS). HHS has also said it will not enforce the X12 278 requirement against covered entities that use an all-FHIR prior-auth API.

Where teams get stuck

• Data mapping. Prior-auth data often lives in a utilisation management system, claims data in another and clinical data somewhere else. Mapping them to consistent FHIR resources is most of the work.
• Member matching. Payer-to-Payer exchange depends on matching members reliably across organisations.
• Provider attribution. The Provider Access API needs to know which patients belong to which provider.
• Rules as data. CRD and DTR expect coverage rules and documentation templates in machine-readable form, which usually means turning policy PDFs into structured rules.
• Testing. Conformance testing against reference implementations takes longer than teams plan for.

A realistic plan for the next 80 days

1. Weeks 1–2: gap assessment. Inventory existing APIs, data sources and plan types. Decide what can be live by the deadline and what needs a documented plan.
2. Weeks 3–4: design. Choose the FHIR server approach, finalise mappings and write the test plan.
3. Weeks 5–12: build and test. Deliver APIs in priority order, starting with the expanded Patient Access API and the Prior Authorization API.

If you are a provider group, the same APIs are an opportunity: once payers expose them, much of the phone and fax work around prior authorization can be automated.

Need a second opinion on your readiness? Our CMS-0057-F readiness service starts with a two-week gap report.

This article is general guidance, not legal advice. Check requirements against the CMS rule and your counsel.