In January 2027 prior authorisation gets an API. Almost nobody is ready.
What does CMS-0057-F actually change for us?
Figures and rules on this page apply to
United States
Working somewhere else? The shape of the problem usually travels. The deadlines do not.
What this looks like
Today a prior authorisation means a portal, a fax, a hold queue, and someone on your staff who knows which plan needs which form. None of that is written down. It lives in one person's head, and when they are on leave the approvals slow to a crawl.
The numbers
Every figure here is someone else’s. Check them.
- 1 Jan 2027deadline for all four mandated FHIR R4 APIs to be live and operational
- 72 hoursmandated turnaround for urgent decisions
- 7 daysmandated turnaround for standard decisions
- $15Bsavings CMS estimates over ten years, mostly from removing this friction
- 1 Jan 2026when the first provisions already took effect
Why it happens
It is not a people problem.
Prior authorisation was never designed. It accumulated. Every payer built its own portal, its own form and its own rules, and the provider absorbed the difference. The cost of that sits entirely on your side of the conversation, which is why it has never been anyone else's problem to fix.
Why your current software has not fixed it
Because it was never built to.
Until now there was nothing to build against. You cannot automate a fax queue or a portal that changes without notice. The rule changes that: from 2027 the payer side is legally obliged to expose a working API. The compliance burden falls on payers, but the benefit only reaches you if something on your side is ready to talk to it.
Intelligence, plumbed in
A payer fax is unstructured text with a deadline attached to it.
The build is the submission service, plus the fallback that still works by fax. And the front-desk screen showing what is waiting on whom. Underneath it: a connector, one agreed meaning per field, and a test set scored on your own records.
How we make AI survive real data-
Connectors -
A semantic layer -
Evals you can check
However hard, whatever it is
This deadline is one example. Bring the rest of the list.
One deadline, researched properly. If your problem is a payer nobody can predict, or a front desk nobody can staff, that is the same method.
-
01 We sit with you
Days where the work happens, not a workshop in a meeting room. We watch the job get done and write down the shortcuts nobody wrote down.
-
02 We read everything
Your data, your rules, your vendors and their documentation, and the published research on your sector. We report what is actually in there.
-
03 We break it to first principles
Not which tool fixes this. What is actually causing it, taken apart until we reach the piece that cannot be divided further.
-
04 Then we build
Weeks, not quarters. By this point we are not guessing what to build, and guessing is the thing that makes projects long.
What we build
Specific enough to argue with.
Four mechanisms, not four features. Each one is a thing that happens on its own, every day, whether or not anyone remembers to run it.
-
The decision workflow first, against the portals and forms you use today, so it earns its keep before 2027.
-
Every request tracked with its clock running, against the 72-hour and 7-day limits.
-
The payer rules written down as data instead of living in one person's memory.
-
A clean switch to the FHIR endpoints as each payer brings them up, without re-training anybody.
How you would know it worked
Numbers in your own reporting, not ours.
- Time from request to decision, by payer.
- Share of requests that need a second submission because something was missing.
- Staff hours per approval, which is the number that funds this.
Straight answers
Where a model is involved, it is scored against your own records first. Accuracy per source, not one flattering average.
The questions this raises
-
Why start now if the deadline is 2027?
Because the workflow takes months and the API is only the last mile. If you start when the endpoints appear, you spend 2027 building while your competitors spend it benefiting.
-
What if our payers are late?
Then you still have the workflow, running against portals as it does today. We build it so the source can change without the process changing.
-
Does this apply to every payer we deal with?
It covers Medicare Advantage, Medicaid and CHIP managed care, and plans on the federal exchanges. Commercial plans outside that are not bound by it, so we treat them as they are.
Where the figures come from
We did not make these up, and you should not take our word for them.
Unstructured text with a clock already running
It arrived as prose, and the countdown started on arrival.
A fax, an email, a filing. Nothing about it is structured, and something expensive happens if it is not acted on in time. The clock starts whether or not anybody has read it yet.
- LegalSeven months to a ruling, thirty-five months to a trial
- Real estateFive minutes against thirty is a twenty-one times difference
A fax, a portal email, a filing. The medium changes and the clock does not. If something expensive happens when you are late, this is yours.Tell us what you are racing.
An API arrives in 2027. Everything before then still needs building.
The build is the submission service, plus the fallback that still works by fax. And the front-desk screen showing what is waiting on whom.
See everything we build-
Software -
Hardware -
Ways of working -
Whole ventures
Is this happening to you? Tell us the size of it.
Twenty minutes. We will tell you honestly whether the numbers justify doing anything about it.