How I Would Build an AI Prior Authorization System That Never Signs the Denial
A teardown of the prior authorization workflow and where an AI-native version would draft, track, and appeal requests while a licensed reviewer keeps the approve-or-deny call.
On this page
Direct Answer
Prior authorization is the approval a payer requires before it will pay for a procedure, drug, or device. Today it runs on fax machines, phone holds, and a person manually matching a chart against a PDF of clinical rules. An AI-native version drafts the request and tracks the case; a licensed reviewer still owns the approve-or-deny call, because two 2025-2026 rules now say so in writing.
Key Takeaways
- Physicians and their staff spend an average of 13 hours a week on prior authorization, and 94% say it contributes to burnout, per the AMA’s 2025 physician survey.
- Starting January 1, 2026, CMS’s interoperability rule (CMS-0057-F) forces impacted payers to decide urgent requests within 72 hours, standard requests within 7 days, and to state a specific denial reason.
- California’s Physicians Make Decisions Act (SB 1120) bans insurers from letting AI be the sole basis for a denial, delay, or modification of care, a licensed clinician has to review it.
- The bottleneck isn’t paperwork speed. It’s that payer criteria live in unstructured PDFs that change without notice, so every request starts with a manual re-read of the rules.
- The AI-native version does not remove the human from the decision. It removes the human from re-typing the same clinical facts into five different formats.
What problem does this system actually own?
A prior authorization system owns the gap between a clinical order and a payer’s rulebook. A physician decides a patient needs an MRI, a biologic, or a procedure. The payer has already published a list of conditions under which it will cover that exact thing but that list is not connected to the chart, the order, or the physician’s software. Someone has to read the payer’s criteria, read the chart, and write a letter proving the patient meets the criteria, in a format the payer will accept.
That gap is not a technology gap. Payers publish criteria on purpose, to control cost. The system’s job is to close the distance between “the rule exists” and “the rule is checked” without changing who is allowed to make the medical call. It’s the same coordination-layer problem I mapped in how I would build a freight booking system that hides the freight, information split across parties who each hold one piece of it.
The existing workflow I would map first
Before designing anything, I would sit with a clinic’s prior auth staff for a week and log every request as it actually happens, not as the payer’s website describes it.
| Step | Today | What breaks |
|---|---|---|
| Determine if PA is required | Staff checks a payer lookup tool or calls, because the requirement changes by plan and by CPT/NDC code | The list goes stale between calls; a missed requirement means a denied claim discovered weeks later |
| Retrieve the clinical criteria | Staff opens a payer PDF, sometimes 30-40 pages, to find the relevant policy | Criteria update without notice; staff work from a cached or printed copy |
| Match chart to criteria | Staff reads the chart and manually maps prior treatments, labs, and diagnoses against the policy’s bullet points | This is the actual clinical-adjacent judgment, done by non-clinical staff under time pressure |
| Assemble and submit | Staff compiles notes, labs, and a justification letter, then submits by fax, portal, or phone, a different method per payer | No shared format; fax loses attachments; portals require separate logins per payer |
| Track status | Staff calls the payer because there’s no reliable status feed | Hold times, inconsistent case IDs, and reps who cannot access the full case |
| Receive determination | Approval, denial, or a request for more information | Before the 2026 CMS rule, denials often arrived without a specific reason to act on |
| Appeal if denied | Staff repeats steps 2-4, now under a clock | Same manual matching, done twice, often for the same clinical facts |
Every step in that table is information moving between people who each hold one piece of it: the clinician holds the clinical facts, the payer holds the rule, and staff hold neither, they’re the translation layer. That translation layer is the coordination problem, not the paperwork.
How the system would run
The AI-native route does not start with “automate the fax.” It starts with making the criteria and the chart legible to the same system at the same time.
When a clinician places an order that historically triggers PA, the system pulls the relevant chart data (diagnosis codes, prior treatments tried, labs, imaging) directly from the EHR. In parallel, it resolves the payer’s current requirement for that CPT or NDC code, either through the payer’s FHIR Prior Authorization API where it exists (required for a large slice of payers by January 1, 2027 under CMS-0057-F) or, until then, from a maintained knowledge base of payer policies that gets re-checked on a schedule instead of at the point of need.
The system then drafts the medical necessity letter as a structured mapping: each criterion the payer lists, paired with the specific chart entry that satisfies it. Where a criterion isn’t met, it says so instead of writing around it. That draft goes to the ordering clinician or their delegate for review before anything is sent: this is not a “human clicks approve on a black box,” it’s a person reviewing a letter that shows its work, criterion by criterion. This is the same review-before-send boundary I used in how I would redesign contract review as an AI-native workflow: draft freely, send only on sign-off.
Once approved for submission, the system files through whichever channel the payer supports and polls for status instead of a person calling. It only surfaces the case to a human again when something needs a decision: an information request, a denial with its stated reason, or approval. On denial, it drafts the appeal the same way: mapped against the specific reason given, which the 2026 rule now requires payers to state.
None of this removes a decision from a person. It removes the requirement that a person re-read a 30-page PDF and re-type the same three lab values into a fourth format this month.
What stays under human control?
Two boundaries here are not design choices: they’re already written into law and regulation, and they land on both sides of the request.
On the payer’s side, California’s Physicians Make Decisions Act amended Health & Safety Code §1367.01 and Insurance Code §10123.135 to say that AI or an algorithmic tool cannot be the sole basis for denying, delaying, or modifying coverage based on medical necessity. A licensed physician or qualified healthcare professional with relevant expertise has to review it. Payers also have to disclose when they use AI in utilization review and submit to periodic audits. Other states are drafting similar language, so a system built to route around this boundary is building on ground that’s shifting under it, the same governance line I mapped for what an AI-native compliance workflow would look like.
On the requesting clinic’s side, the boundary is professional accountability rather than statute: whatever gets submitted under a physician’s name is the physician’s clinical claim. A system that drafts a letter and sends it without review is asking a clinician to stake their license on text they never read. The draft-then-approve step isn’t a compliance checkbox: it’s the difference between a tool that saves a clinician time and one that quietly makes clinical assertions on their behalf.
What’s left for automation is real: pulling the right chart fields, resolving which policy applies, drafting the criterion-by-criterion mapping, filing through the correct channel, and chasing status. What’s not left for automation is deciding that a patient meets a clinical bar, or deciding that they don’t.
When this is the wrong build
This system is a bad fit for a payer that has no digital submission channel at all and genuinely requires a phone call, forcing an API-shaped tool onto a phone-only relationship adds a translation step instead of removing one. It’s also a bad fit for a solo practice or small clinic running a handful of PAs a month; the ongoing cost of keeping a payer-criteria knowledge base current can exceed what a low volume of requests saves, which is an argument for a shared utility across many practices rather than a bespoke build for one, similar to the cold-start problem I flagged in how I would build an AI-native insurance claims system.
And it’s the wrong build if the goal quietly becomes “reduce denials” rather than “reduce translation work.” A system tuned to write more persuasive letters isn’t closing the coordination gap: it’s optimizing against the payer’s review process, which is a different, riskier project with different incentives.
Summary
Prior authorization looks like a paperwork problem, which is why most fixes target the fax machine. The actual bottleneck is that the payer’s rule and the patient’s chart have never lived in the same structured format, so a person has to hold both in their head at once, twice if the request gets denied. An AI-native version closes that gap (matching chart to criteria, drafting the letter, tracking the status) while leaving the medical-necessity call exactly where California and CMS now say it has to stay: with a licensed person who read the case.
Frequently Asked Questions
Can AI legally deny a prior authorization request? No. California’s Physicians Make Decisions Act (SB 1120) prohibits insurers from using AI or an algorithm as the sole basis for denying, delaying, or modifying care based on medical necessity: a licensed physician or qualified healthcare professional has to make the final call, and several other states are drafting similar rules.
How much time does prior authorization actually cost a practice? The AMA’s 2025 physician survey found doctors and their staff spend an average of 13 hours a week on prior authorization and complete about 40 requests weekly, with 94% saying the process contributes to burnout.
What does the 2026 CMS prior authorization rule require? Starting January 1, 2026, CMS-0057-F requires impacted payers (Medicare Advantage, Medicaid and CHIP fee-for-service and managed care, and ACA exchange plans) to decide urgent requests within 72 hours and standard requests within 7 calendar days, and to give a specific reason for every denial.
Will the FHIR Prior Authorization API make PA staff unnecessary? No. The API, required by January 1, 2027 for a large slice of payers, standardizes how a request and its determination move between systems. It removes a transport problem. Someone still has to gather the clinical evidence, judge whether it meets the criteria, and handle denials and appeals.
What’s the riskiest part of automating this workflow? Letting a system submit a justification letter under a physician’s name without their review. The ordering clinician remains legally and professionally accountable for what’s submitted, so approval-to-send stays a human step even after AI drafts the content.
Frequently asked questions
Can AI legally deny a prior authorization request?+
No. California's Physicians Make Decisions Act (SB 1120) prohibits insurers from using AI or an algorithm as the sole basis for denying, delaying, or modifying care based on medical necessity, a licensed physician or qualified healthcare professional has to make the final call, and several other states are drafting similar rules.
How much time does prior authorization actually cost a practice?+
The AMA's 2025 physician survey found doctors and their staff spend an average of 13 hours a week on prior authorization and complete about 40 requests weekly, with 94% saying the process contributes to burnout.
What does the 2026 CMS prior authorization rule require?+
Starting January 1, 2026, CMS-0057-F requires impacted payers to decide urgent requests within 72 hours and standard requests within 7 calendar days, and to give a specific reason for every denial.
Will the FHIR Prior Authorization API make PA staff unnecessary?+
No. The API standardizes how a request and its determination move between systems. Someone still has to gather clinical evidence, judge whether it meets the criteria, and handle denials and appeals.
What's the riskiest part of automating this workflow?+
Letting a system submit a justification letter under a physician's name without their review. The ordering clinician remains accountable for what's submitted, so approval-to-send stays a human step even after AI drafts the content.
