# Payer prior-authorization APIs from January 2027

> What the CMS Interoperability and Prior Authorization Final Rule requires of payers, its 2026 and 2027 dates, and what it means for practices.

- Web page: https://www.alesanalytics.com/docs/payer-prior-authorization-apis-2027
- Markdown: https://www.alesanalytics.com/docs/payer-prior-authorization-apis-2027.md
- Last updated: 2026-11-08
- Publisher: Ales Analytics

Industry guide. CMS-0057-F decision times, metrics and APIs. Published 2026-11-08. Last reviewed 2026-11-08. Reviewed by Ales Analytics engineering.

## Who it applies to

The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) applies directly to "impacted payers": Medicare Advantage organisations, state Medicaid and CHIP programmes, Medicaid managed care plans, CHIP managed care entities, and issuers of qualified health plans on the federally facilitated exchanges. It does not regulate providers directly, but it changes how practices and hospitals will exchange prior-authorization information with those payers.

## What it requires, in plain terms

- **Decision timeframes.** Most impacted payers must decide expedited prior-authorization requests within 72 hours and standard requests within 7 calendar days, and give a specific reason when they deny one.
- **Public metrics.** Payers publish prior-authorization statistics each year, such as approval and denial rates and average decision times.
- **APIs.** Payers must build FHIR-based APIs: a Prior Authorization API that lets a provider's system find out whether authorization is needed, what documentation is required, and submit the request; a Provider Access API; a Payer-to-Payer API; and improvements to the existing Patient Access API.
- **A related incentive for providers.** Eligible hospitals and clinicians in Medicare's quality programmes gain a measure for requesting prior authorization electronically through a payer's API.

## Key dates

As of November 2026:

| What                                                         | When                                                               |
| ------------------------------------------------------------ | ------------------------------------------------------------------ |
| Final rule published                                         | January 2024                                                       |
| Decision timeframes and specific denial reasons              | From 1 January 2026                                                |
| First public prior-authorization metrics                     | By 31 March 2026, covering 2025                                    |
| Prior Authorization, Provider Access and Payer-to-Payer APIs | From 1 January 2027 (generally; dates vary slightly by payer type) |

## What it means for your systems

- A prior-authorization packet assembled from the chart can be submitted through a payer API instead of a portal or fax, for payers that have built one. Many requests will still go through portals and fax for some time, so a practice will run both.
- Specific denial reasons make denials easier to group, which makes appeals and the root-cause view more useful.
- Requests, decisions and their timing should be recorded in one place, so the practice can see where authorizations stall.
- Patient data used to build a packet should stay in the practice's own environment, and every submission should be reviewed by staff.

## Official sources

- [CMS: Interoperability and Prior Authorization Final Rule (CMS-0057-F) fact sheet](https://www.cms.gov/newsroom/fact-sheets/cms-interoperability-and-prior-authorization-final-rule-cms-0057-f)
- [CMS: final rule overview presentation (PDF)](https://www.cms.gov/files/document/cms-interoperability-and-prior-authorization-final-rule-presentation-3-26-24.pdf)
- [WEDI and CMS spotlight](https://www.wedi.org/assets/pdf/CMS+HIIG_WEDI+Spotlight)

## How this connects to our work

[Supervised agents](https://www.alesanalytics.com/capabilities/supervised-agents) can assemble a packet from the chart, submit it by API or portal, and track it to a decision, stopping for staff review before anything is sent. Systems we build are designed to support your obligations; they do not make an organisation compliant on their own. See also [Healthcare](https://www.alesanalytics.com/industries/healthcare).

## Contact

solutions@alesanalytics.com, or https://www.alesanalytics.com/contact.

- Every page as Markdown: https://www.alesanalytics.com/llms.txt