The CMS Interoperability and Prior Authorization Final Rule, CMS-0057-F, is often reduced to two numbers: 72 hours for expedited decisions and 7 calendar days for standard non-urgent decisions, effective January 1, 2027 for impacted payers. Those numbers are precise on paper and messy in practice, because most payers do not run the full prior authorization workflow in house. Utilization management vendors, radiology benefit managers, specialty PA delegates, and case-management partners all touch the request before a decision returns to the provider.
Under the rule, the payer remains the accountable entity for the SLA even when the work sits at a delegate. That single sentence rewrites how PA contracts, timers, and audit logs need to be scoped. For teams sizing up how their existing PA stack fits, the FHIR integration reference at wattman.net covers the API-layer side of that scoping exercise.
What The Rule Actually Says About The Clock
CMS-0057-F sets decision windows on the payer, not on any individual reviewer. The regulation text and the Da Vinci Prior Authorization Support (PAS) implementation guide together define the clock in three parts.
- Clock start. The clock begins when the payer receives a properly formed PA request. For the PAS API path, that is the moment the Claim resource with
use=preauthorizationlands on the payer endpoint with a valid identifier and the minimum data set the payer publishes as required. - Clock pause. The rule permits a defined pause when the payer sends a valid request for additional information back to the submitter. Once the requested information is returned, the clock resumes; the pause is not open-ended and payers must document the triggering data gap.
- Clock stop. The clock stops when the payer issues a decision (approve, deny, or pend with an interim disposition) and transmits it back through the PAS API and the standard notification channels.
Nothing in that timeline resets when the request is forwarded to a delegate. The delegate window is inside the payer window, not next to it.
Where Delegate Contracts Under-Scope The SLA
Most delegated PA contracts written before CMS-0057-F carved out turnaround times in business days, allowed same-day handoff windows, and treated data requests as full timer resets. All three habits break under the new rule. Common gaps in existing contracts:
- Turnaround expressed in business days rather than calendar days or hours.
- Handoff SLAs that consume 24 hours between payer intake and delegate queue.
- Request-for-information clauses that reset rather than pause the clock.
- No obligation on the delegate to expose PAS-compatible status queries during the review.
- Audit-log ownership left ambiguous, so the payer cannot produce the CMS-required metrics quarterly.
On the platform side, vendor evaluation typically pits point CMS-0057-F services against reusable FHIR stores like Aidbox with an embedded compliance layer such as Payerbox from Health Samurai. The choice affects where the timers live, which is not a small detail when a delegate feeds status back into the same runtime.
Teams sizing the API surface will find the survey in Top 4 FHIR Servers for Payer-Provider Data Exchange in 2026 useful, and the operational timer patterns show up in Top 7 FHIR API Tools for Real-Time Clinical Workflows.
Contract Clauses To Update Before Enforcement
A short checklist for redlining delegated PA contracts ahead of the 2027 date:
- Restate turnaround in calendar hours matching the 72-hour and 7-day CMS windows.
- Cap intake-to-delegate handoff to a defined sub-window, counted inside the payer clock.
- Replace reset clauses with pause clauses tied to a documented data gap.
- Require delegate exposure of PAS status queries and standardized decision codes.
- Assign audit-log ownership to the payer with delegate feed obligations named.
- Define quarterly metrics reporting responsibility for PA volume, decision time, and denial reasons.
The rule is unforgiving about which entity holds the SLA, and the delegate contracts that survive enforcement will read very differently from the ones written even two years ago. The trade-off across payer stacks lands on where the clock is measured and whether the same runtime holds both the intake API and the delegate feedback path.
