Key Takeaways:
- WISeR’s documented problems were mostly operational. Vendor readiness, handoffs between organizations, portal access design, downtime, and review capacity caused more trouble than any single model error.
- Automate the front of the workflow first. Eligibility, coverage checks, and documentation assembly are rule-based and auditable. Keep a clinician accountable for medical necessity, which federal guidance and California law already expect.
- Payment design shapes behavior. WISeR vendors are paid from a share of averted spending, which critics say rewards denials, so pay your own vendors and teams for accuracy, turnaround, and low appeal overturn rates.
- Build to the FHIR Prior Authorization API now. Impacted payers must offer it by January 1, 2027.
If you’re a health system CTO or innovation director weighing whether to automate prior authorization, the decision in front of you is narrower than “should we use AI.” It’s what to automate first, and what to keep in human hands. CMS’s WISeR model, now in its first year, gives you a rare public look at what happens when a launch date outruns system readiness.
One note on framing before we start. WISeR hasn’t been shut down. The Senate voted 46 to 50 on July 16, 2026 against taking up a resolution to overturn it, and the model is still running in six states. What the public record shows is a rollout with serious operational problems, and those problems are the lessons worth taking.
What Is the WISeR Model?
WISeR, the Wasteful and Inappropriate Service Reduction model, is a CMS Innovation Center test of whether technology vendors using AI, combined with clinical review, can make prior authorization in traditional Medicare faster and more accurate for services CMS considers prone to waste. It runs for six performance years, from January 1, 2026 through December 31, 2031, in Arizona, New Jersey, Ohio, Oklahoma, Texas, and Washington, with one technology vendor assigned to each state. The covered services include skin and tissue substitutes, electrical nerve stimulator implants, and knee arthroscopy for knee osteoarthritis, and CMS excludes emergency services, inpatient-only services, and services that would put patients at substantial risk if delayed.
A few design choices matter for anyone building in this space. Providers can request prior authorization or skip it and face pre-payment medical review instead. CMS says a qualified clinician must review every denial, and its stated standard is a response within 72 hours. And providers who reach at least a 90% approval rate on at least 10 requests can earn gold-card status, which exempts them from prior authorization.
The program’s legal footing is contested. In May 2026, the Government Accountability Office concluded that the WISeR notice is a rule under the Congressional Review Act, which opened the door to the Senate vote. The House Appropriations Committee separately approved a rider in June 2026 that would bar fiscal 2027 funding for WISeR and similar models, and whether it survives the full appropriations process remains unsettled.
What Went Wrong in the First Year
The best evidence comes from roughly 1,000 pages of CMS records the Electronic Frontier Foundation obtained through a Freedom of Information Act lawsuit and published in September 2026, along with hospital data and reporting from the pilot states.
Vendor Readiness Was the First Crack
Not every vendor was ready on day one. One vendor warned CMS before launch that its software hadn’t been fully tested. Innovaccer, the Ohio vendor, told CMS its model wouldn’t be fully operational at launch, and when the program went live anyway, it auto-approved every request to avoid a backlog. Within the first three months, CMS sent requests for information or corrective action to at least four of the six vendors.
A fixed go-live date with a vendor that has told you it needs more time is a risk you’re choosing. Innovaccer’s fallback at least protected patients from delays, which is worth noting: if a system isn’t ready, the safe failure mode is a manual or permissive path, never a silent queue.
Backlogs Blew Past the Standard
The records show vendors missed the 72-hour response goal for a significant number of requests, and one status report cites a request that went unanswered for 83 days. Reporting on the documents describes technical failures and limited communication between the parties involved. None of that is a model accuracy problem. It’s integration and operations, which is where most automation projects stall.
Access Design Created Its Own Bottleneck
In Washington, the vendor’s portal let only the employee who submitted a request see its updates and documents, so requests stalled whenever that person was out of the office. It’s a small design decision with a large effect, and it’s easy to avoid with team queues and role-based access.
Patients Absorbed the Delays
Senator Maria Cantwell’s April 2026 report, built on Washington State Hospital Association survey data from three health systems with 16 hospital locations, found that procedures previously approved in about two weeks were taking four to eight weeks, two to four times as long. At UW Medicine, urgent and standard authorizations that used to take one to three days stretched to 15 to 20 days, and nearly 100 patients were waiting for epidural steroid injections. Hospitals also reported that denials often lacked clear rationales and that they’d added staff to keep up. It’s a lawmaker’s report drawn from survey data, so treat it as early and contested evidence. The direction still matters: automation that adds queue time is worse than the manual process it replaced.
Human Review Didn’t Catch Everything
Even with clinician review of denials, errors got through. The records show two vendors alone denied more than 20,000 requests in the first three months. In one case reported by KFF Health News and CBS News, an Oklahoma radiologist documented four times that a patient didn’t have numbness, and the request was denied anyway, citing numbness. EFF has also argued that AI recommendations can shape the judgment of the clinicians reviewing them. A person in the loop is necessary, and the quality and capacity of that review matter just as much.
[IMAGE: Timeline graphic comparing prior authorization turnaround before and after an automation launch, with the pilot’s 72-hour goal marked]
Where Prior Authorization Automation Typically Breaks
It breaks at the handoffs, and at the point where software starts making judgment calls. Treat the workflow in stages, and give each one a different level of automation.
Eligibility, Coverage, and Documentation: Automate These First
Determining whether a service needs authorization, verifying eligibility, confirming benefit limits, and assembling the right documentation are rule-based tasks, and they’re where most of the manual work still sits. The 2025 CAQH Index found medical prior authorization only 40% electronic, far behind other administrative transactions. Deterministic checks are also the easiest to audit, which makes them the right place to build trust in automation.
Medical Necessity: Keep a Clinician Accountable
This is where judgment lives, and where WISeR drew its sharpest criticism. The rules already point the same way. CMS has told Medicare Advantage plans that algorithms may assist coverage decisions but that determinations must rest on the individual patient’s circumstances, not on large data sets alone. California’s SB 1120, in effect since January 2025, goes further: AI tools can’t deny, delay, or modify care based on medical necessity, and only a licensed physician or health care professional can make that determination.
If you’re building for a health system or a payer, design the model to approve clear cases and route everything else to a person. That approve-or-escalate pattern gives you speed where the answer is obvious and keeps a clinician accountable where it isn’t.
Denials and Appeals: Where Transparency Pays Off
When a request is denied or pended, the provider needs a specific reason and a clear path to appeal. CMS’s interoperability rule now requires impacted payers to give a specific reason for every denial. WISeR’s critics have pressed on this point, and EFF says there’s little public information about how the WISeR algorithms work, including what data trained them. Opaque decisions make appeals slower and more expensive for everyone.
Does Payment Design Affect How AI Prior Authorization Behaves?
Yes, and WISeR is the clearest recent example. CMS’s payment methodology pays vendors from averted spending, meaning the Medicare payment that would have gone to denied services, adjusted by a quality score for accuracy and timeliness. The American Hospital Association said CMS indicated vendors would receive 10% to 20% of the savings and called the structure a perverse incentive to deny appropriate care. Humata Health’s CEO said vendors had no say in the payment model and that it differs from how commercial payers pay the company.
CMS built in counterweights. It withholds or recoups payment when a denial is overturned on appeal, audits vendors’ determinations, and can reduce payments for inaccurate or late decisions. Whether those offsets are strong enough is part of what the model is testing.
You don’t need to take a side in that debate to learn from it. If your automation project pays a vendor or an internal team based on denials or avoided spending, you’ve built an incentive your clinicians, auditors, and patients will question. Pay for accuracy, turnaround time, and low appeal overturn rates, and attach a clawback to any decision that’s reversed.
What Does the Evidence Say About Integrating Prior Authorization Into Clinical Workflow?
The strongest positive evidence comes from automation that sits inside the clinical workflow. A December 2025 JAMA Network Open study of 6,551 radiation oncology cases at Northwell Health, spanning seven practice settings and 86 insurance plans, found that clinically integrated prior authorization software was associated with a 65.4% reduction in denials, from 7.6% to 2.6%, and a 33.9% drop in median authorization time. The software starts the authorization workflow automatically when a treatment order is entered, pulls the clinical data elements payers typically require, and notifies the care team as the status changes. Some of the authors reported payments from the software’s maker, and it’s one practice in one specialty with an observational design, so treat it as a strong signal rather than a guarantee.
The study also carries a caution. An accompanying commentary notes that even after implementation, authorization at the 90th percentile still took up to 15.2 business days. Software narrows the gap, and the slowest cases still need attention.
Keep vendor claims in perspective too. A 2022 McKinsey analysis estimated that AI-enabled prior authorization could automate 50 to 75 percent of the manual tasks involved, using a triage design in which the most complex cases, such as organ transplants, always go to manual review. That’s a task-automation estimate. It doesn’t promise faster approvals, and WISeR shows how far apart those two things can be.
The Regulatory Runway: FHIR APIs and Faster Decisions
Prior authorization is moving onto standard electronic rails, and any build should be designed for where it’s heading. CMS’s Interoperability and Prior Authorization final rule applies to Medicare Advantage organizations, Medicaid and CHIP programs and their managed care plans, and qualified health plan issuers on the federal exchanges. Since January 1, 2026, most impacted payers must decide standard requests within seven calendar days and expedited requests within 72 hours, with a specific reason for each denial. By January 1, 2027, they must offer a FHIR-based Prior Authorization API, and CMS is adding an electronic prior authorization measure to its quality programs for hospitals and clinicians starting with the 2027 performance period.
Commercial plans are moving too. More than 50 insurers pledged in June 2025 to standardize electronic prior authorization by January 2027 and to answer at least 80% of electronic approvals in real time that year. For provider-side builders, that means designing to the FHIR API while keeping portal and fax paths alive for payers that aren’t there yet. Dogtown’s guide to FHIR API integration covers the architecture.
What Design Patterns Work Better?
Approve Automatically, Escalate Everything Else
Use the model for clear approvals, and route ambiguous cases to a clinician with the relevant record already assembled. Humata Health, the Oklahoma WISeR vendor, describes this shape: according to a HIT Consultant report, its AI can only approve requests, and anything that isn’t an instant yes goes to a human clinician. Humata’s CEO has also made the case for this design in a MedCity News opinion piece, so weigh it as a vendor’s argument, but the logic holds.
Staff the Escalation Queue
Approve-or-escalate shifts every hard case to people, and Oklahoma still saw delays and errors under that design. Before launch, estimate how many requests the model will escalate, how long a clinical review takes, and how many reviewers you need to hold your turnaround target at peak volume. Then audit a sample of human decisions, since reviewers working through a backlog of difficult cases are where errors like the numbness denial happen.
Here’s What the Flow Can Look Like
| Step | What happens | Who decides | What to log |
|---|---|---|---|
| Order entered | The system detects a new order and checks whether the payer requires authorization | Rules engine | Order, payer, rule version |
| Eligibility | Coverage and benefits are verified in real time | Rules engine | Eligibility response |
| Documentation | Required clinical elements are pulled from the record for this order only | Automation | Documents attached |
| Submission | The request goes out through the payer’s API, portal, or fax | Automation | Channel, submission ID, timestamp |
| Clear case | Criteria are met, and the request is approved or auto-approved by the payer | Payer or model | Decision and time to decision |
| Unclear case | The request goes to a clinician with the record assembled | Clinician | Reviewer, rationale, time in queue |
| Denial | The specific reason is captured, and an appeal is prepared if warranted | Clinician | Reason, appeal decision, outcome |
Instrument the Workflow Before You Scale It
WISeR’s problems surfaced in logs and status reports, which means someone was measuring. Make sure you are too, from week one:
| Metric | Why it matters |
|---|---|
| Turnaround by stage, at the median and 90th percentile | Averages hide the slow tail the JAMA commentary flagged |
| Pended requests by age | Catches a growing backlog before it becomes an 83-day request |
| Auto-approval and escalation rates | Shows whether the model is doing its job and whether reviewers can keep up |
| Denial and appeal overturn rates, by payer and service | High overturn rates signal bad denials, whatever produced them |
| System downtime and handoff failures | The operational failures that drove WISeR’s delays |
| Time from order to procedure | The measure patients actually feel |
Design for Teams, Not Individuals
Route requests to shared work queues with role-based access, so updates and documents are visible to everyone covering the work. The Washington portal problem is a reminder that access rules are part of the workflow design.
Stage the Rollout and Vet Vendors
Set go/no-go criteria before launch, run new automation in shadow mode alongside your current process, and keep a manual fallback ready. Ask every vendor to demonstrate live integration with your EHR and the payer endpoints you depend on, and get its own readiness assessment in writing. Gartner’s Market Guide for Intelligent Prior Authorization, published in February 2026 and available to Gartner clients, is a reasonable starting point for a shortlist. Dogtown’s guide to building automated prior authorization tracking apps covers the provider-side build in more detail.
If You’re a Provider in a WISeR State
WISeR doesn’t change what Medicare covers. CMS says the model enforces existing coverage and payment criteria, so vendors review requests against the national and local coverage policies that already apply. The practical work is getting documentation right the first time and keeping a record of what happens.
- Build submission checklists from the coverage policy for each covered service, so everything a reviewer needs is attached before the request goes out.
- Track your approval rate by service. Providers who reach a 90% approval rate on at least 10 requests can qualify for the gold-card exemption, and the same data shows where documentation is falling short.
- Preserve the record. Polsinelli recommends documenting every non-affirmation, appeal outcome, and operational burden, which supports appeals and any future policy debate over the model.
- Watch the queue. Track how long each request sits with the vendor, and escalate through the vendor and your Medicare Administrative Contractor when the 72-hour standard slips.
A Prior Authorization Automation Readiness Checklist
- Scope set. You know which steps you’re automating and which stay with people.
- Clinician accountability defined. No automated system can deny, delay, or modify care on medical necessity grounds.
- Vendor readiness confirmed. Live integration is demonstrated, and the vendor’s readiness assessment is in writing.
- Go-live criteria agreed. The launch depends on readiness, with a manual fallback ready if a component isn’t.
- Escalation capacity planned. Reviewer staffing matches projected escalation volume at peak.
- Access designed for teams. Shared queues and role-based permissions replace individual-bound submissions.
- Metrics live. Turnaround by stage, backlog age, escalation, denial, overturn, and downtime are tracked from day one.
- Incentives aligned. Vendor and team compensation rewards accuracy and speed, with clawbacks for reversed decisions.
- Standards targeted. The build supports the FHIR Prior Authorization API while keeping portal and fax paths for payers that aren’t ready.
- Denial reasons captured. Every denial carries a specific reason and a tracked appeal path.
Why Partner With Dogtown Media
Dogtown Media builds AI-powered healthcare applications that connect to the EHR, payer, and clearinghouse systems prior authorization depends on, including FHIR-based integrations designed for CMS’s 2027 requirements. Our AI compliance and risk mitigation practice designs the escalation, audit logging, and human-review controls that keep clinicians accountable, and our HIPAA-compliant development work protects the clinical data moving through every step.
If you’d like to talk through your own prior authorization build, request a free consultation with our team.
Frequently Asked Questions
Did the CMS WISeR pilot fail?
Not in the sense of being cancelled. The Senate voted 46 to 50 in July 2026 against taking up a resolution to overturn it, and CMS plans to run the model through 2031, though a House appropriations rider that would cut off fiscal 2027 funding hasn’t been resolved. The documented failures are operational: vendor readiness gaps, missed turnaround standards, a request left unanswered for 83 days, portal access problems, and denials that hospitals say lacked clear rationales.
Which prior authorization tasks should you automate first?
Start with determining whether authorization is required, eligibility and coverage checks, and documentation assembly. These are rule-based, high-volume, and easy to audit. Keep medical necessity decisions with a clinician, and use the model to approve clear cases and route the rest with the record assembled.
Can AI deny a prior authorization request on its own?
It shouldn’t, and in many contexts it can’t. CMS has told Medicare Advantage plans that algorithms can assist coverage decisions but that determinations must reflect the individual patient’s circumstances. California’s SB 1120 bars AI tools from denying, delaying, or modifying care based on medical necessity and requires a licensed professional to make that call. WISeR itself requires a clinician to review every denial. An approve-only model with clinician review of everything else fits all of those rules.
What is the CMS FHIR Prior Authorization API requirement?
It’s part of CMS’s 2024 Interoperability and Prior Authorization final rule. Impacted payers, including Medicare Advantage organizations, Medicaid and CHIP programs and their managed care plans, and qualified health plans on the federal exchanges, must implement a FHIR-based Prior Authorization API by January 1, 2027. The same rule has required faster decisions, seven calendar days for standard requests and 72 hours for expedited ones, since January 1, 2026. It applies to payers, so provider-side builders should design to be compatible with it.
Can AI reduce prior authorization denials and delays?
There’s evidence it can when it’s integrated into the clinical workflow. A JAMA Network Open study of 6,551 radiation oncology cases found a 65.4% reduction in denials and a 33.9% drop in median authorization time after a clinically integrated system went live, though the slowest cases still took up to 15.2 business days. WISeR shows the reverse can happen when implementation is rushed and review capacity falls short.
The Bottom Line
If you’re deciding what to automate first, start at the front of the workflow: authorization requirements, eligibility, coverage, and documentation, built on FHIR standards. Keep a clinician accountable for medical necessity, staff the escalation queue for real volume, measure every stage from day one, and don’t let a launch date override what your vendor tells you about readiness. WISeR’s public record is a stress test of the opposite approach.
