Medicare Shipped an AI Prior-Auth System Before It Worked. Here Are the Receipts.
FOIA records show Medicare's WISeR AI prior-auth pilot launched before it worked. A vendor warned them. Patients waited 83 days. This is what rushing costs.

Photo by Kindel Media on Pexels
Newly released FOIA documents show that WISeR, the Medicare Wasteful and Inappropriate Service Reduction model, a six-state AI prior-authorization pilot running through 2031, launched in January 2026 before it was ready. A vendor had warned CMS that a working product by the launch date was unrealistic, and once live, a contractor said auto-affirming requests was the only path available because CMS would not delay. The human cost is documented: one request went 83 days unanswered against a 72-hour target, two vendors denied more than 20,000 requests in three months, and providers reported patients crying in pain while waiting. The lesson for patient access is blunt: a launch date is a safety parameter, and shipping an unready prior-auth system industrializes delay and denial.
I try to give big programs the benefit of the doubt. Prior authorization is a mess, Medicare does spend on services that do not help anyone, and using AI to sort that out is not a crazy idea on paper. But then you read the documents, and the benefit of the doubt evaporates. A vendor told CMS the thing was not ready. CMS launched it anyway. And the people who paid for that decision were patients sitting at home in pain, waiting for a yes that took months. This one is worth walking through slowly, because the mistakes are the instructive kind.
What WISeR was supposed to do
Let me steelman it first, because the goal is defensible. WISeR, the Wasteful and Inappropriate Service Reduction model, is meant to put an AI screen in front of certain Medicare services, flag the ones that are genuinely wasteful or inappropriate, and wave the rest through fast. Done well, that is less rubber-stamping of low-value care and no extra friction for care that patients actually need. The intended flow is clean and even a little appealing. The problem was never the diagram. It was shipping the diagram before the software behind it existed.
The receipts: a vendor said it was not ready
This is not me speculating. Documents obtained through a FOIA lawsuit show the rollout was hasty and error-ridden, including a vendor cautioning CMS that it was unrealistic to expect a working product by the time the agency wanted to launch. They launched in January 2026 anyway, about six months after announcing it, with untested features live. By April, status reports showed a contractor still without a complete solution. When the people building the thing tell you it is not ready and you go live regardless, you have made the timeline more important than the outcome.
What half-built looks like for a patient
Abstract failures become concrete fast. The released records describe one request that went 83 days unanswered against a 72-hour target, and providers reporting that patients were calling their offices crying in pain because procedures were being delayed. Two vendors denied more than 20,000 requests in the first three months, and one denied more requests than it approved. When one contractor concluded that auto-affirming was the only path available, that was not efficiency. That was a system waving things through because it could not actually evaluate them, which is the exact opposite of the point.
This is the prior-auth problem, industrialized
Here is the part that worries me most as someone who works on patient access. Prior authorization is already a friction machine. A human reviewer is slow, but at least there is someone to call, someone who notices when a case has been sitting for weeks. Point unready AI at that same process and you do not remove the friction, you scale it. You get denials faster and fixes slower, a backlog that grows to 83 days with no human feeling the weight of it. The technology did not create the prior-auth problem, but deployed like this, it industrializes it.
How you actually do this responsibly
I am not arguing against ever using AI in prior authorization. I am arguing against this way of doing it. Treat the launch date as a safety limit: if the product is not ready, the date is not a deadline, it is a hazard. Make the fallback route to a human who can approve, not an auto-response that stalls. Start narrow, a few services with clear criteria, not skin substitutes and epidural injections on day one. And measure the one number that actually matters to a patient, time to care. Do those four things and you can pursue the real goal, less waste, without the part where someone waits 83 days in pain.
- WISeR, the Medicare Wasteful and Inappropriate Service Reduction model, is a six-state AI prior-authorization pilot launched January 2026 and running through 2031.
- FOIA documents show it launched before it was ready: a vendor warned CMS that a working product by the deadline was unrealistic, and CMS launched anyway.
- Once live, a contractor said auto-affirming was the only path available because CMS refused to delay, and by April 2026 a vendor still lacked a complete solution.
- The harm is documented: one request went 83 days unanswered against a 72-hour target, two vendors denied over 20,000 requests in three months, and providers reported patients crying in pain.
- For patient access, the launch date is a safety parameter: an unready prior-auth system does not reduce waste, it industrializes delay and denial.
Frequently asked
What is the WISeR model?
WISeR, the Wasteful and Inappropriate Service Reduction model, is a Medicare pilot that uses AI to run prior authorization on selected services in six states, launched in January 2026 and scheduled to run through 2031.
What did the FOIA documents reveal?
That the rollout was hasty and error-ridden. A vendor had warned CMS that a working product by the launch date was unrealistic, untested features went live anyway, and by April 2026 a contractor still lacked a complete solution.
What does auto-affirming mean here?
A vendor told CMS that auto-affirming requests, approving them automatically, was the only path available because the agency would not delay the launch. It is a sign the system could not actually do the job it was built to do.
How were patients affected?
Documented harm includes one request left unanswered for 83 days against a 72-hour target, two vendors denying more than 20,000 requests in three months, and providers reporting patients crying in pain while waiting for approvals.
What is the lesson for patient access?
Treat the launch date as a safety limit, not a deadline. Make the fallback route to a human who can approve rather than an auto-response that stalls, start with a narrow set of clearly defined services, and measure time-to-care, not just savings.