Table of contents
In this article
Industry guide
Payer prior-authorization APIs from January 2027
CMS-0057-F decision times, metrics and APIs
- Published
- 8 November 2026
- Last reviewed
- 8 November 2026
- Re-checked every
- 90 days
- Reviewed by
- Ales Analytics engineering
- Used in
- Supervised agents
- Relevant for
- Healthcare
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 (opens in a new tab)
- CMS: final rule overview presentation (PDF) (opens in a new tab)
- WEDI and CMS spotlight (opens in a new tab)
How this connects to our work
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.
Should you have any questions regarding this page, please contact us at solutions@alesanalytics.com.