An AI Mission for Healthcare: Prior Authorization

Prior authorization is not a form. It is a negotiation conducted entirely in documents between two organizations that each hold half of what the exchange requires — and the waiting it produces is not a neutral administrative interval.

In the back office of almost any specialty practice there is a desk with three windows open at once: the electronic record, a payer portal that logs itself out every few minutes, and a document queue that still, in the year of our lord, involves a fax cover sheet. The person at that desk is assembling a request for authorization. They are not deciding anything, and they would be alarmed if anyone suggested otherwise; they are gathering what a reviewer at another organization will need in order to decide. The hardest part of their morning is not the gathering itself. It is knowing, before they send it, exactly what that particular payer under that particular plan will expect to see attached — a body of knowledge that exists partly in a binder, partly in a shared drive that is three revisions out of date, and mostly in the scar tissue of the last dozen requests that came back asking for something the practice could have sent the first time.

Nobody in this loop is behaving unreasonably. The practice is trying to move care forward for someone who is waiting. The payer is applying coverage policy that it is obligated to apply consistently across an enormous population. Both sides are staffed by people doing careful work under volume pressure. And yet the process reliably produces an outcome neither of them wants, which is delay — not because anyone chose delay, but because the structure of the exchange makes it almost inevitable.

Each side holds half the file, and the wall between them is crossed one letter at a time

The provider holds the clinical half. It has the record, the history, the notes, the imaging, the reasoning of the clinician who believes a given course of care is appropriate. The payer holds the policy half. It has the coverage criteria, the plan design, the documentation standards, the list of what constitutes sufficient evidence for a given request under a given contract, and the internal conventions about how those standards are read. Neither party can see the other's half directly. So the request travels across the wall as a package of documents, a response travels back as another package, and the whole exchange is an attempt to reconstruct by correspondence a shared picture that neither organization can assemble on its own.

Seen that way, the round trips stop looking like obstruction and start looking like what they mostly are: the predictable cost of a conversation held in one direction at a time. A request goes out missing an element the provider had no reliable way to know was expected. It comes back with a question. Someone re-opens the file, finds the missing piece, and sends it again. Each of those crossings costs days, and the days are not the only cost. The more expensive loss is the thread — the context the coordinator held in their head when they first assembled the package, which has to be rebuilt from scratch a week later, usually by a different person, alongside forty other open requests in the same condition.

This is why the reflex to fix prior authorization by making the forms shorter has never worked particularly well. The form is a symptom of the information asymmetry, not its cause. You can compress the paperwork and the same conversation will still require the same number of crossings, because the provider still does not know in advance what completeness looks like from the other side of the wall, and no one on either side is tracking the aggregate state of everything currently in flight.

The interval is not administrative overhead; it is part of what the person waiting experiences

It is comfortable, especially inside a health system's finance function, to file all of this under administrative burden and measure it in staff hours and rework cost. That framing is true and badly incomplete. From the position of the person whose care is pending, the interval is not overhead at all. It is the period in which a decision has been made by their clinician and has not yet become anything, in which they are holding uncertainty and rearranging their life around a date that does not exist yet. Whatever else prior authorization is, the delay it generates is not a back-office metric. It shows up in the experience of care, and it deserves to be counted there.

That reframing changes what automation in this area is actually for. If the delay is merely an expense, then the goal is to make the same process cheaper, and you get the familiar outcome: a slightly faster version of the same number of round trips. If the delay is part of the outcome, then the goal is different and more demanding — to reduce the number of crossings the conversation requires, and to make sure that nothing sits in a queue for a week because no human had the bandwidth to notice it was sitting there. Those are engineering targets, and they are reachable ones. They are also, importantly, not the same target as deciding whether care is authorized.

Assembly and tracking are the honest target; the determination is not

This distinction carries the entire argument, so it is worth stating without hedging. A system that helps a practice assemble a complete, accurate request and keep track of it is one kind of thing. A system that decides whether care is authorized is a categorically different and far more consequential thing, and the two should not be allowed to blur into each other because they happen to share a workflow. A medical-necessity determination is a judgment about a specific person's health with direct consequences for that person, and it belongs to accountable humans — the clinician making the request on one side, and reviewers with clinical accountability on the other — people who can be identified, questioned, appealed to, and held responsible for what they concluded. The objection is not that software could not emit an output shaped like a determination. It is that such an output would be a determination without an author, and an unauthored decision about someone's care is not a decision at all. Nothing in this essay argues for building one, and the surest way to discredit every legitimate use of automation in this domain is to build one anyway.

What remains once you draw that line is still substantial. There is knowing, before a request is sent, what a given payer under a given plan expects to see — an enterprise knowledge problem, not a judgment problem, and one that practices currently solve with memory and folklore. There is checking that what has been assembled is complete against that expectation, and flagging what is missing back to the clinical team rather than discovering it a week later through a returned request. There is submitting to the right destination in the right format, which sounds trivial and consumes a startling share of the day. And there is the part almost nobody builds: maintaining a live, accurate picture of every pending request — what went out, when, what has been acknowledged, what is aging past the point where someone should be picking up the phone, what came back needing a response. Open loops at volume are precisely what human attention is worst at holding, and a practice with hundreds of them in flight is running on the diligence of a few people who are one sick day away from losing the thread.

It matters how this is framed internally, because the same capability can be pointed somewhere corrosive. The aim is a request that is complete and faithful to the record — not one engineered to satisfy criteria the record does not actually support. A package that overstates is worse than one that is merely incomplete, because it corrupts the only thing the exchange has going for it, which is that both sides are reading the same evidence. Any system built here should be measured on accuracy and completeness, and should be visibly indifferent to whether the answer that comes back is yes.

This is where a lot of what is currently sold into healthcare operations falls down, and the skepticism is well earned. Gartner has predicted that over forty percent of agentic AI projects will be canceled by the end of 2027, citing unclear business value and inadequate risk controls alongside what it calls "agent washing" — older tools relabeled without any change in what they can actually carry on their own. A rules engine that fires a reminder about a pending request has not absorbed the tracking problem; it has added a notification to it. The work that would genuinely help is the work of reading what came in, reconciling it against what the organization knows about that payer's expectations, assembling and routing accordingly, and holding the state of every open request — with human review wired into anything that touches clinical substance. That posture, in which specialist agents run the assembly and people own the judgment, is the shape of the broader argument set out in the literature on autonomous enterprise operations, and it is how platforms like StudioX describe the boundary in their own AI Missions: the agents carry the coordination, and the human-in-the-loop gates sit exactly where a decision has consequences for a person.

The mental model worth carrying out of this is a change in what you measure. The instinct is to watch approval rates and turnaround times, both of which describe the payer's behavior more than your own and neither of which you control. The more honest measure sits entirely on the provider side: what fraction of your requests were complete the first time they crossed the wall, and how many of your open requests could you account for right now, without asking anyone. A prior authorization operation that can answer both of those questions has stopped treating the exchange as a queue to be pushed through and started treating it as a shared-context problem to be closed — which is what it always was, and the only version of it that a machine should be trusted to help with.