Prior Authorization UX: The Request Lives or Dies on the First Missing Field

Ask anyone who works the front desk of a specialty clinic what eats their week, and prior authorization comes up within a minute. Staff juggle payer portals, fax cover sheets, hold music, and sticky notes with reference numbers. Patients wait. Doctors get pulled into peer to peer calls they never scheduled.

Health tech teams keep promising to fix this, and plenty of them have shipped a digital prior auth product. Most of those products still feel like a fax machine with a nicer font. The form is online, the rules are hidden, the status is vague, and the denial arrives with a code nobody can act on.

We think prior authorization UX is one of the highest leverage design problems in health care right now. Regulators are pushing payers toward electronic prior auth and faster decision timelines, which means every vendor in the space is about to be compared on how the experience actually feels for the person submitting the request. Here is how we look at it.

The real user is a coordinator with forty open requests

Most prior auth tools are designed around a single request. The real user is a care coordinator or billing specialist holding dozens of open requests across several payers, each at a different stage, each with its own deadline.

That changes what good looks like:

• The home screen is a work queue. Sort by what needs action today: missing documents, payer questions, decisions about to expire, appeals with a deadline.
• Every request has a visible clock. Show when it was submitted, when a decision is due, and how long it has been sitting with whom.
• Ownership is explicit. If a request is waiting on the clinic, say who at the clinic. If it is waiting on the payer, say that plainly too.

A tool that makes coordinators open each request to learn its status has already lost. They will go back to their spreadsheet, and your product becomes one more tab.

Most denials start at intake

The single most expensive moment in prior authorization is the first submission. A request that goes in incomplete comes back as a pend, a request for information, or a denial, and every one of those adds days.

Good intake design does three things:

1. It asks only for what this payer needs for this service. Generic forms with forty optional fields train people to skip things. Adaptive forms that change by payer, plan, and procedure code cut the noise and surface the fields that actually decide the outcome.
2. It explains the clinical criteria before submission. If the payer requires six weeks of conservative therapy before imaging, say so on the screen, next to the field where the coordinator documents it. Hidden criteria are the root of most avoidable denials.
3. It pulls from the record. Diagnosis codes, prior treatments, and recent notes already live in the EHR. Every field a human retypes is a field that can be wrong.

The test we run: can a coordinator who has never submitted to this payer get a complete request through on the first try? If the answer depends on tribal knowledge, the intake is the bug.

Status needs plain words and a next step

"Pending" is the most useless word in health care software. It tells the coordinator nothing about whether to wait, call, or upload something.

Strong status design names the state in human terms and pairs it with the next action:

• Received, in clinical review. Decision due by a specific date. Nothing needed from you.
• More information requested. The payer needs the last two visit notes. Upload them here.
• Approved. Here is the authorization number, the approved units, and the valid date range.
• Partially approved. Eight of twelve visits approved. Here is why, and here is how to request the rest.

Each status should also tell the coordinator when they will hear next. A clear expected date reduces phone calls more than any chatbot.

Denials should read like instructions

A denial screen is where most products give up. A reason code, maybe a PDF letter, and a link to a generic appeals page.

We treat the denial as the start of a workflow:

• Translate the reason. Show the payer's code and a one line plain language explanation of what was missing or what criteria were not met.
• Show the fix. If the denial was for missing documentation, let the coordinator attach it and resubmit from the same screen.
• Offer the right path. Some denials call for a corrected resubmission, some for a peer to peer review, some for a formal appeal. The product should say which one fits and what the deadline is.
• Keep the history together. The original request, the denial, the appeal, and every message should live in one thread. Nobody should rebuild the story from email.

Clinics measure vendors by how many denials turn into approvals without a phone call. Design for that number.

AI helps when a person keeps the judgment

Every prior auth vendor now pitches AI. Some of it is genuinely useful: summarizing a long chart into the evidence a payer wants, flagging missing criteria before submission, drafting an appeal letter from the denial reason.

The UX rules we hold teams to:

• Show the source. If the model says the patient completed physical therapy, link to the note that says so. Coordinators and clinicians will not trust a claim they cannot check.
• Make the human approve. AI can prepare the packet. A person with clinical or billing responsibility reviews and submits it, and the interface makes that step obvious.
• Flag uncertainty. When the model cannot find evidence for a criterion, say that clearly so the coordinator goes looking before the payer does.

AI that quietly fills a form and submits it creates a new liability. AI that assembles evidence and hands it to a person for a decision saves real hours.

What we reject

When we review prior authorization products, these patterns go straight on the fix list:

• A single long form for every payer and every service.
• Status labels like "Pending," "In process," or "Under review" with no date and no owner.
• Denial screens that show only a code and a PDF.
• Appeals that require starting a new request from scratch.
• Notifications sent by email only, with no in app queue to match.
• AI suggestions with no link to the underlying record.
• Payer rules buried in a help center article the coordinator never opens.
• Mobile views that hide the attachments list.

How to know your prior auth UX is working

Track a short list of numbers and watch them weekly:

• First pass completeness. The share of requests submitted with nothing missing.
• Time to decision. From first submission to final answer, split by payer.
• Touches per request. How many times a human had to open, edit, call, or upload.
• Denial to approval rate. How many denials turn into approvals, and how many of those needed a phone call.
• Queue age. How many requests have sat untouched for more than two days.

If those numbers move, the experience is improving. If the product only looks cleaner, the fax machine is still winning.

Where we come in

We work with health tech, insurance, and fintech teams on complex, regulated workflows like this one. We review the live product, map the real coordinator workflow, and ship working software for the fixes that matter, with senior designers and engineers who have done regulated work before. AI speeds up our execution, and people make the calls.

If your prior authorization product still sends coordinators back to the phone, let's look at it together. Book a discovery call or email us at ash@uxsignalstudio.com.