HealthNext
← Briefings
June 2026·7 min read

The clock starts in 2027

CMS-0057-F turns the prior-authorization deadline into law with money attached. We keep meeting payers who have scoped it as a reporting project. It is an architecture project, and the difference shows up the first week the clock is real.

Read the CMS Interoperability and Prior Authorization Final Rule — CMS-0057-F — and the headline looks like a deadline. Affected payers must send prior-auth decisions inside 72 hours for expedited requests and 7 calendar days for standard ones, with the operational requirements phasing in through 2026 and the API requirements landing in 2027. Plain enough. The instinct in most shops is to treat it the way you'd treat any new reporting mandate: stand up a dashboard, wire in the timestamps, watch the SLA, escalate the reds.

That instinct is the mistake. The clock is the visible part. Underneath it, CMS-0057-F is two harder problems wearing a deadline as a costume.

It is an access-control problem first

The rule turns on three new data flows: Patient Access, Provider Access with Da Vinci member attribution, and Payer-to-Payer exchange with member opt-in. Each one is a question about who is allowed to see what, on whose authority, right now. That is not a reporting question. It is an authorization question, and it has to be answered correctly on every single request before any clock is worth tracking.

It gets sharper where the flows collide. A member can opt into payer-to-payer exchange and, separately, carry a 42 CFR Part 2 protection on substance-use records. Now you have a permit and a denial pointing at the same data. A reporting layer has no opinion about this; it just records whatever the underlying system did. An access engine has to decide — and the only safe default is that when a permit and a denial of equal specificity collide, the denial wins. Build that as policy enforced at the egress gate and Part 2 is structurally protected. Build it as a flag someone remembers to check and you have shipped a breach with a countdown.

A deadline you report on is a metric. A deadline the workflow enforces is a property. Only one of them holds up when the volume arrives.

It is an SLA-enforcement problem second

Here is where the reporting framing quietly fails. If the SLA clock is a metric bolted on after the fact, the deadline is something you observe — you watch a request age, and when it goes red, a human notices and scrambles. That works at low volume and breaks exactly when it matters, because the breach and the alert arrive at the same moment.

The clock has to be native to the request. In HealthNext, a prior-auth request starts the CMS-0057-F decision clock natively — 72 hours expedited, 7 days standard — and the deadline is carried on the record itself, not in a side dashboard. The adverse path routes to a licensed reviewer in-window, by construction, because the workflow knows the window. The difference between “we noticed it was late” and “it could not silently go late” is the difference between a compliance finding and a clean audit.

The objection: surely a vendor dashboard is enough

The honest counter is that plenty of UM tooling already tracks SLAs and plenty of vendors will sell you a 0057 module. Why does the architecture have to be different?

Because the rule does not let the pieces stay separate. The same member whose prior auth you are racing the clock on will call about the bill that follows it. Today that is three point tools — prior auth, claims status, member billing — that re-key context and disagree with each other. Under 0057, with the No Surprises Act sitting next to it, the answer a member gets has to be consistent across all three, and the consent state has to be honored in each. You cannot stitch that together with a reporting layer over three systems. You need one governed graph where the prior auth, the claim, and the billing question resolve against the same source of truth, with the same access rules, in one motion.

That is the part the deadline hides. CMS-0057-F is not asking payers to watch a clock. It is asking them to make access control, SLA enforcement, and cross-surface consistency into properties of the workflow — and to be able to prove each one held. The plans treating it as a dashboard will meet the date and fail the first real audit. The plans treating it as architecture will not notice the audit, because the proof is already in the record.

We wrote up the access-control model — the three flows, the deny-override logic, the Part 2 gate — on the payers surface. And the reason every adverse decision routes to a named human is who holds the call.

HealthNext runs the regulated healthcare admin work as governed agents inside your boundary — and proves every action.

Read more briefings