The Workflow Everyone Hates and Nobody Can Skip
Ask anyone who works in a US clinic what they'd delete from their day, and prior authorisation will be near the top of the list. Before an insurer will pay for many treatments, imaging studies, and medications, someone on staff has to prove the care is medically necessary — assembling patient history, physician notes, prior treatments tried, and supporting evidence into a request that matches that specific payer's specific rules. Then they wait. Then, often, they resubmit.
It is expensive, it is slow, and it sits directly in the path of patient care. A request that takes a nurse forty minutes to compile and a week to clear is forty minutes not spent on patients and a week a treatment is delayed. Multiply that across a busy practice and prior authorisation becomes one of the largest, least visible administrative costs in the building.
This is exactly the shape of problem AI handles well, because the work is high-volume, largely made of reading and drafting, and has a clearly correct output a human can verify. An AI prior authorisation assistant reads the record, drafts the request, gathers the medical-necessity evidence, and tracks the approval — while a qualified person reviews and signs off before anything reaches a payer. This guide covers how that assistant actually works, where the hard engineering lives, and what it realistically returns.
It's one of the five workflows we map in the healthcare AI development pillar, and it pairs naturally with AI revenue cycle management, which handles what happens after the claim is filed.
What the Assistant Actually Does
Prior authorisation is not a single task — it's a chain of them, and the assistant works down the chain, handing control back to a human at the point where judgement and liability matter.
Reading the record. The first job is pulling together everything the request needs: diagnosis codes, the procedure or medication being requested, relevant history, labs, imaging results, and the clinician's rationale. Some of this is structured data sitting in defined EHR fields; much of it is unstructured — free-text notes where the clinical reasoning actually lives. The assistant has to read both, which is why the FHIR and EHR integration layer underneath it matters so much. Get the data extraction wrong and everything downstream is built on sand.
Mapping to the payer's requirements. This is the part that makes prior authorisation miserable for humans and valuable for automation. Every payer has its own criteria, its own forms, and its own definition of what "medically necessary" means for a given procedure. An MRI request that clears one insurer on the first pass gets bounced by another for missing a conservative-treatment step. The assistant maps the clinical picture to the target payer's specific rule set, flags what's missing, and drafts the request in the format that payer expects.
Assembling the medical-necessity evidence. A strong request doesn't just assert necessity — it shows it. The assistant gathers the supporting documentation (the failed prior treatments, the relevant imaging, the guideline the request satisfies) and attaches it, so the reviewer on the payer's side has what they need to approve without a follow-up query.
Tracking status through to a decision. Submission isn't the end. Requests sit in queues, get approved, get denied, or come back with a request for more information. The assistant tracks each one, surfaces the ones that need attention, and keeps staff from having to log into three portals to find out where things stand.
The Human-Review Step Is the Whole Point
It is tempting to describe this as "automating prior authorisation." It isn't, and the distinction is not pedantic — it's the difference between a system a clinic will trust and one that creates liability.
The assistant drafts. A qualified person reviews and submits. Before any request goes to a payer, someone with the authority to do so checks that the clinical picture is represented accurately, that the necessity argument holds, and that nothing has been overstated or misattributed. This matters for two reasons. First, accuracy: a payer submission that misrepresents the record, even unintentionally, is a serious problem, and the model's draft is a starting point, not a signed statement. Second, compliance: prior authorisation touches protected health information at every step, and the human in the loop is part of how a clinic keeps accountability where it belongs.
That review step is also where the time saving is real without being reckless. The assistant removes the forty minutes of assembly and formatting; the reviewer spends five minutes confirming a draft rather than forty building one. The professional's judgement stays in the loop — it's just no longer spent on clerical assembly. This is the same assistive, human-in-the-loop principle that governs every serious AI agent handling sensitive data, applied to a workflow where the data is clinical and the stakes are a patient's care.
On PHI handling: because the assistant reads real patient records, the architecture has to be HIPAA-aware from the first decision — encryption, audit logging, scoped access, a signed Business Associate Agreement with any third-party model provider, and careful data minimisation before anything reaches an LLM. We cover that architecture in HIPAA-compliant AI; it is not a layer you add at the end.
Denials, Appeals, and the Loop That Actually Saves Money
Approvals are the easy case. The money and the misery are in denials.
A denied prior authorisation isn't the end of the road — it can be appealed, and appeals frequently succeed, which tells you many denials were avoidable in the first place. The assistant helps on both sides of this. Before submission, it can flag the gaps that commonly trigger denials for a given payer and procedure — a missing conservative-treatment step, an absent lab value, a code mismatch — so the request goes out right the first time. After a denial, it can read the payer's stated reason, pull the evidence that addresses it, and draft the appeal for human review.
This loop is where the ongoing value compounds. Every denial reason the system sees teaches it what a specific payer wants, and clean first-pass submissions are the single biggest lever on both cost and speed to care. Fewer denials means fewer resubmissions, less staff time, and patients waiting days rather than weeks.
The Integration Reality Nobody Warns You About
Here is the constraint that surprises teams new to healthcare: a meaningful share of prior authorisation is still transacted by fax and web portal, not clean APIs.
Yes, in 2026. Payer connectivity is uneven. Some insurers offer modern APIs; many still expect requests through a proprietary web portal, and a stubborn number still run on fax. This is a real engineering problem, not a footnote. An assistant that drafts a beautiful request is only useful if it can actually deliver it the way the payer accepts, and "the way the payer accepts" varies payer by payer.
In practice this means the delivery layer is often the hardest part of the build. For payers with APIs, you integrate directly. For portal-only payers, you either automate the portal interaction carefully or route the drafted request to a human to submit through the portal — which is fine, because the assembly was the expensive part. For fax-based payers, you generate the correctly formatted document and route it through an electronic fax gateway. A team that has done this before knows to scope the payer mix early, because it determines a large chunk of the engineering work.
What Good Looks Like
A prior authorisation assistant worth deploying has these properties:
It reads both structured and unstructured records accurately. The clinical reasoning usually lives in free text, and a system that only reads coded fields misses the argument for necessity.
It maps to payer-specific rules, not a generic template. The value is in matching the request to the target payer's actual criteria, and flagging gaps before submission rather than after a denial.
A qualified human reviews every request before it reaches a payer. The assistant drafts and assembles; a person with authority confirms accuracy and submits. This is non-negotiable, not a maturity milestone.
It handles the delivery reality. API where possible, portal and fax where necessary, with the drafted request delivered in the format each payer actually accepts.
It closes the loop on denials. Reading denial reasons, drafting appeals, and learning what each payer wants so first-pass approval rates climb over time.
It's HIPAA-aware by construction. Encryption, audit logging, scoped access, a BAA with any model provider, and data minimisation designed in from the first architecture decision.
Questions to Ask Before You Build
"How does the assistant pull data from unstructured notes, not just coded fields?" If the answer is only about structured data, it will miss the necessity argument that actually clears requests.
"How do you handle payers that are portal- or fax-only?" A good answer names a delivery strategy per payer type. Vagueness here means a hidden chunk of the work hasn't been scoped.
"What exactly does a human review before submission, and who is authorised to do it?" You want a specific review step with a specific role, not "the model checks its own work."
"How is PHI handled when records pass through the model?" They should name the BAA, the data minimisation, and the audit logging — the same discipline any HIPAA-compliant AI build requires.
"How does the system learn from denials?" The compounding ROI lives in first-pass approval rates improving over time as the assistant learns each payer's patterns.
Illustrative ROI: What the Numbers Might Look Like
The figures below are illustrative, not guarantees — every practice's payer mix, procedure volume, and starting process are different, and your results will depend on all three. They're offered to show the shape of the return, not to promise it.
| Metric | Manual process | With AI assistant (illustrative) |
|---|---|---|
| Staff time per request | ~30–45 minutes | ~5–10 minutes (review only) |
| First-pass approval rate | Baseline | Higher, via pre-submission gap checks |
| Time to decision | Days to weeks | Reduced, via faster clean submissions |
| Denial rework | Manual reassembly | AI-drafted appeals for human review |
| Staff hours reclaimed | — | Redirected to patient-facing work |
The reason hospitals and clinics pay well to fix this is straightforward: the manual process is genuinely costly, and the delays it causes sit directly on patient care. When the assembly time drops from forty minutes to a five-minute review and clean submissions clear faster, the saving is measurable in staff hours and in how quickly patients get treated. That's a business case that funds itself — but it's earned in the build, not assumed on a slide.
What It Costs and How Long It Takes
A production-grade prior authorisation assistant — one EHR integration, HIPAA-aware architecture, payer-specific mapping, and a proper human-review step — is a multi-month engagement rather than a quick build. The compliance and integration work is real, and the payer delivery layer (API, portal, and fax) is usually the part that determines the timeline more than the AI itself.
The honest caveat is the same one that applies across healthcare AI: the floor is higher than for general software. The payer mapping, the PHI handling, and the fax-and-portal reality all add work a generic app never carries. That floor is also what keeps the work valuable — it's the barrier that means a team who can clear it is solving a problem the clinic genuinely can't solve alone.
Related guides
- Healthcare AI development: the full map
- AI revenue cycle management: fewer denied claims
- FHIR, HL7 and EHR integration
- HIPAA-compliant AI architecture
- AI agents for healthcare: reducing admin burden
- Our AI development services
We Build Prior Authorisation Assistants That Clear the Compliance Bar
Prior authorisation is one of the highest-ROI workflows in US healthcare precisely because it's so painful to do by hand — and one of the trickiest to build well, because the payer connectivity, the PHI handling, and the human-review discipline all have to be right. We build assistants that read the full record, map to each payer's actual requirements, handle the API-portal-fax reality, and keep a qualified person in control of every submission.
If you want to work out where an assistant would pay off first in your setting — and where the simpler, safer design is the better one — we're happy to scope it with you.
Talk to us about your platform — no commitment, just a conversation.
Frequently Asked Questions
What does an AI prior authorisation assistant actually do?
It automates the assembly and tracking of prior authorisation requests. It reads the patient's structured and unstructured record, drafts the request in the target payer's format, gathers and attaches the medical-necessity evidence, and tracks the request through to approval or denial. Crucially, it drafts rather than decides — a qualified person reviews and submits every request before it reaches a payer. The value is in removing the manual assembly, not in removing the human judgement.
Does the AI submit requests to insurers on its own?
No, and it shouldn't. The assistant drafts and assembles; a qualified staff member reviews for accuracy and submits. Prior authorisation submissions represent the clinical record to a payer, so a human with the authority to do so confirms nothing is misstated before anything goes out. This is both a compliance requirement and simply better practice — the assistant is assistive, not autonomous.
How does it handle insurers that still use fax or web portals?
Carefully, because this is a genuine engineering constraint rather than an edge case. Payer connectivity is uneven — some offer modern APIs, many are portal-only, and some still run on fax. A well-built assistant delivers each request the way the specific payer accepts it: direct API integration where available, careful portal handling or human submission where not, and correctly formatted documents through an electronic fax gateway where that's the only channel. Scoping the payer mix early is essential because it drives a large share of the build effort.
Is it HIPAA-compliant to run patient records through an AI model?
It can be, but only with the right architecture. Because the assistant reads real PHI, the build needs encryption, audit logging, scoped access, data minimisation before anything reaches the model, and a signed Business Associate Agreement with any third-party model provider. HIPAA compliance is designed in from the first architecture decision, not added afterwards. We cover this in detail in our HIPAA-compliant AI guide.
What kind of ROI can we realistically expect?
The honest answer is that it depends on your payer mix, procedure volume, and current process, so any figure is illustrative rather than guaranteed. The typical shape of the return is a large drop in staff time per request (from assembling a request to reviewing a draft), a higher first-pass approval rate from catching gaps before submission, and faster time to decision. The compounding benefit comes from the system learning each payer's patterns over time, which lifts clean-submission rates. Treat published numbers as directional and validate against your own baseline.
How is this different from AI revenue cycle management?
They're adjacent stages of the same financial workflow. Prior authorisation happens before care is delivered — getting the payer's approval that a treatment is covered. Revenue cycle management happens after — making sure the resulting claim is coded correctly, documented, and paid rather than denied. A prior authorisation assistant reduces upfront delays and denials; RCM automation recovers revenue on the back end. Many practices build one first and add the other, since they share much of the same EHR integration and compliance foundation.