CMS-0057-F is the CMS Interoperability and Prior Authorization final rule. It requires certain payers — Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid and CHIP managed care plans, and qualified health plan issuers on the federally facilitated exchanges — to implement standards-based APIs and publish prior authorization decision data. Most API requirements begin in 2027.
For referral leaders, the practical question is not whether payers will comply. It is whether your own referral workflow can consume what those payers are about to expose. An API you cannot query changes nothing about the patient's wait.
What the Rule Actually Requires
CMS finalized the rule in January 2024. The requirements fall into two groups, described in the CMS Interoperability and Prior Authorization final rule fact sheet.
Operational requirements
Impacted payers must send prior authorization decisions within 72 hours for expedited requests and seven calendar days for standard requests, provide a specific reason for any denial, and publicly report aggregate prior authorization metrics.
API requirements
Impacted payers must implement, generally beginning January 1, 2027:
- A Prior Authorization API that identifies items and services requiring authorization, communicates documentation requirements, and supports submission and status checks.
- An expanded Patient Access API that includes prior authorization information.
- A Provider Access API that makes claims, encounter, and prior authorization data available to in-network providers.
- A Payer-to-Payer API for data exchange when members change plans.
The APIs are built on HL7 Fast Healthcare Interoperability Resources (FHIR), the same standard family already used by the ONC-defined United States Core Data for Interoperability. CMS aligned the rule with HL7 Da Vinci implementation guides — Coverage Requirements Discovery, Documentation Templates and Rules, and Prior Authorization Support.
Note on scope: CMS-0057-F obligates payers, not providers. There is no provider penalty for being unprepared. The cost of being unprepared is operational — you keep working the old way while competitors do not.
Why This Is a Referral Problem, Not an IT Problem
Prior authorization is embedded inside the referral pathway. A referral that requires authorization is not actionable until authorization exists, and the authorization cycle is frequently the largest single block of delay between the order and the appointment. That relationship is examined in time to appointment: the referral metric that predicts everything else.
When payers expose documentation requirements programmatically, three things become possible that are not possible today:
- Requirement discovery at the point of order. The referring clinician learns that authorization is needed, and what evidence supports it, during the visit rather than days later.
- Structured submission without portal work. Staff stop logging into plan portals to retype data the EHR already holds.
- Status without phone calls. Pending, approved, and denied states arrive as data instead of as fax or hold music.
None of that happens automatically. Each depends on your referral system being able to call the API, map the response into the workflow, and act on it.
A Readiness Framework
Use five workstreams. They can run in parallel; they should not run sequentially.
1. Inventory your payer mix against the rule
List every payer by volume of authorization-requiring referrals, then mark whether that payer is in scope for CMS-0057-F. Commercial group plans outside the exchanges are not covered. Your readiness ceiling is the share of volume that is in scope — know that number before you plan.
2. Baseline your current authorization performance
You cannot show improvement against a number you never captured. Measure, by payer and service line: authorization cycle time, first-pass approval rate, touches per authorization, denial rate with reasons, and share of referrals where authorization was the binding delay. Related measurement discipline is covered in the 12 referral KPIs every healthcare executive should track.
3. Confirm your data is API-ready
FHIR submission fails on data quality more often than on connectivity. Audit whether the elements payers ask for — diagnosis coding specificity, clinical notes, imaging results, prior therapy history — exist as structured data in your EHR or only as scanned attachments. Structured beats scanned every time.
4. Redesign the workflow, not just the interface
If a coordinator still manually decides whether authorization is needed, an API only shortens one step in a process that remains manual. Decide now what should be automatic: requirement checks, submission assembly, status polling, escalation on approaching deadline. Auto PriorAUTH submits through payer APIs rather than portal logins, which is the operating model the rule assumes.
5. Fix governance and accountability
Name an owner for authorization performance who is not also the owner of scheduling. Define escalation thresholds. Establish a monthly review that reads authorization metrics next to leakage and time to appointment. Structural guidance is in referral governance for clinically integrated networks.
Readiness Checklist
| Question | Evidence you are ready |
|---|---|
| Do you know your in-scope payer share? | A payer-by-payer list with authorization volume |
| Do you have a cycle-time baseline? | Median and 90th percentile by payer, last two quarters |
| Is required clinical evidence structured? | Field-level audit, not a general impression |
| Can your referral platform call a payer FHIR API? | Vendor confirmation with an implementation date |
| Is authorization run in parallel with scheduling? | Workflow diagram showing concurrent paths |
| Is denial-reason data captured and trended? | Denial reasons categorized and reviewed monthly |
| Does a named executive own the metric? | Owner, cadence, and threshold documented |
Sequencing the Work
Order matters more than speed.
First, measure. A baseline established before any change is the only way to attribute improvement later.
Second, clean the data. Structured clinical data is the prerequisite for every downstream automation. Do this before selecting technology, because it is your work regardless of vendor.
Third, decouple authorization from scheduling. Running them in parallel produces immediate benefit with no dependency on payer readiness at all.
Fourth, integrate. Connect to payer APIs as they come online, prioritizing your highest-volume in-scope payers. Interface and security posture is described in integration and security.
Fifth, govern. Fold new metrics into the existing operating review rather than creating a parallel compliance report nobody reads.
What Good Looks Like in 2027
A referring clinician places a referral. The system checks coverage and authorization requirements while the patient is still in the room. Required documentation is assembled from structured data. Submission happens without a portal. Scheduling proceeds in parallel, so the patient leaves with a date rather than a promise of a call. Status changes arrive as data and trigger action only when human judgment is required.
That workflow is achievable today for a meaningful share of volume. The rule expands how much of your volume it can cover. Organizations that treat 2026 as build time rather than wait time will enter 2027 with the workflow already in production.
Key Takeaways
- CMS-0057-F obligates payers, but the operational benefit accrues only to providers whose workflow can consume the new APIs.
- Most API requirements begin January 1, 2027; operational requirements including decision timeframes and denial reasons come with the rule.
- Not all payers are in scope — quantify your in-scope share before planning.
- Structured clinical data, not connectivity, is the usual blocker for FHIR-based submission.
- Running authorization in parallel with scheduling delivers value now and does not depend on payer readiness.
- Baseline cycle time and denial reasons first, or you will never be able to prove improvement.
Frequently Asked Questions
Q: What is CMS-0057-F? A: CMS-0057-F is the CMS Interoperability and Prior Authorization final rule, finalized in January 2024. It requires impacted payers to implement FHIR-based APIs for prior authorization, patient access, provider access, and payer-to-payer exchange, and to meet operational standards for decision timeframes, denial reasons, and public metric reporting.
Q: Which payers are covered by the rule? A: Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid and CHIP managed care plans, and qualified health plan issuers on the federally facilitated exchanges. Commercial group plans outside the exchanges are not covered, so your authorization mix will remain mixed after 2027.
Q: When do the requirements take effect? A: The API requirements generally begin January 1, 2027. Operational requirements — including expedited decisions within 72 hours, standard decisions within seven calendar days, specific denial reasons, and public reporting of aggregate prior authorization metrics — are part of the same rule with earlier applicability.
Q: Do provider organizations have obligations under CMS-0057-F? A: No. The rule places requirements on payers. Providers face no penalty for being unprepared, which is precisely why readiness is easy to defer and expensive to defer. The consequence of inaction is a slower referral pathway than peers who built for the new interfaces.
Q: What should we do first if we have not started? A: Baseline authorization cycle time and denial reasons by payer, and audit whether the clinical evidence payers require exists as structured data in your EHR. Both are prerequisites for any automation and neither depends on a vendor decision.
Q: Will the rule eliminate prior authorization delays? A: No. It standardizes and accelerates the exchange of authorization data for covered payers. Delay caused by internal queues, unclear ownership, or scheduling processes that wait on authorization instead of running alongside it is unaffected by the rule and remains a provider-side design problem.
Q: How does this connect to referral leakage? A: Authorization delay lengthens time to appointment, and longer waits push patients to self-solve out of network. Reducing authorization cycle time therefore reduces leakage without any separate steerage intervention, as discussed in our analysis of what referral leakage costs a health system.
If you want a concrete view of where authorization delay sits inside your referral pathway, request a workflow walkthrough.
