A provider group's prior authorization queue runs on paperwork: checking whether a service needs approval, pulling the referral and chart fields, matching them to a payer's requirement, and getting the request in front of that payer through whatever channel it still uses. None of that paperwork requires a clinical judgment, and none of it requires an agent to act without a person checking the result.
At a glance
- Intake, document collection, rule lookup, packet drafting and status tracking are administrative; medical-necessity and submission decisions are not.
- A nine-step control matrix assigns each step a permission — read, draft, submit-with-approval, or human-only — plus the evidence it logs and where exceptions route.
- An agent never submits a request on its own; a named reviewer approves every packet before it reaches a payer.
- An exception taxonomy routes missing documentation, rule ambiguity, portal failures and denials to a named queue instead of stalling silently.
- Turnaround and reviewer workload are measured per step, not only end to end, so a bottleneck shows before it becomes a backlog.
Which prior authorization steps are administrative and safe to automate?
This design treats a prior authorization (PA) request as moving through one shape: confirm the service needs approval, assemble the record, match it to the payer's requirement, put the request in the channel the payer accepts, track it, and respond if the payer asks for more. Every one of those is routing, lookup, drafting, and tracking against a defined form, not a judgment about medical necessity.
- Triage: whether the planned service, on this plan, requires a PA at all.
- Document and data collection: pulling the referral and chart fields a payer's form asks for.
- Payer-rule lookup: finding the payer's current requirement and form for that service code.
- Packet and form drafting: populating the request and attaching supporting documents.
- Submission and status tracking: transmitting the packet once a reviewer approves it, then following its status.
- Administrative response: supplying a field or document the payer names.
The AMA's 2025 survey of 1,000 practicing physicians found that, on average, practices complete 40 PAs per physician, per week [1] — volume that's worth designing for. One submission format is X12 transaction set 278, published as the Health Care Services Review – Request for Review and Response standard [2] — a transport format for the packet, not the payer's clinical criteria, which still have to be looked up separately for each service and plan.
What stays off this list matters just as much: whether a service is medically necessary, how to read ambiguous criteria, and whether to submit at all are decisions for clinical and authorization staff. The design below keeps that line explicit.
The human-in-the-loop queue design
A workable design names, for every step in the PA intake process, exactly one of four permissions:
- Read — look up and summarize information already in your systems or the payer's published requirements. Nothing changes.
- Draft — populate a form or compose text, but nothing leaves the workflow unreviewed.
- Submit-with-approval — transmit a packet to a payer only after a named reviewer approves it.
- Human-only — never reaches the agent; a licensed clinician or authorization staff member decides it.
Applied to a typical PA workflow, those four permissions split across nine steps:
| Step | Agent permission | Evidence logged | Exception route |
|---|---|---|---|
| Intake triage (is a PA needed?) | Read | Service code, payer, plan, timestamp | Ambiguous requirement → Policy queue |
| Document and data collection | Read | Fields pulled; fields not found | Missing item → Missing-documentation queue |
| Payer requirement lookup | Read | Rule source, date retrieved | Lookup failure or stale rule → Policy queue |
| Packet and form drafting | Draft | Draft content; incomplete fields flagged | Incomplete packet → Missing-documentation queue |
| Submission (portal, 278 transaction, or fax/eFax) | Submit-with-approval | Reviewer, approval timestamp, channel, confirmation | Transmission failure or rejection → IT/operations queue |
| Status tracking and information requests | Read | Status checks; new requests logged | New document requested → Missing-documentation queue |
| Medical-necessity and clinical-criteria review | Human-only | Reviewer name and credential, decision | Always routes to the Clinical queue |
| Appeal packet preparation | Draft | Draft content; documents compiled | Denial reason unclear → Appeals queue |
| Appeal and resubmission decision | Human-only | Decision-maker, rationale reference | Always routes to the Appeals queue |
Exception taxonomy
The matrix above assumes the happy path. In the AMA's 2025 survey of 1,000 practicing physicians, nearly a third (32%) reported that PAs are often or always denied [1] — one reason a denial route has to exist before the agent touches the workflow. This taxonomy uses six exception types:
| Exception type | What triggers it | Routes to | Who resolves it |
|---|---|---|---|
| Missing documentation | A required field or attachment isn't in the chart or referral | Missing-documentation queue | Staff request the item from the referring provider or patient |
| Payer-rule ambiguity | The requirement is unclear, conflicting, or unpublished for that plan | Policy queue | Reviewer or payer-relations staff confirm with the payer |
| Portal or transaction failure | A portal is unavailable or changed, or a 278 submission is rejected | IT/operations queue | Operations staff retry, or fall back to fax or phone |
| Clinical-criteria question | The request turns on medical necessity or clinical judgment | Clinical queue | Licensed clinical or authorization staff — never the agent |
| Time-sensitive case | The service is urgent or expedited review applies | Escalation queue | Supervisor or the staff designated for urgent cases |
| Denial or partial approval | The payer returns an adverse or partial determination | Appeals queue | Staff review the agent's drafted appeal and decide whether to submit it |
Should an AI agent ever submit a prior authorization without review?
No. In the matrix above, submission is always submit-with-approval, never autonomous: a named reviewer approves the packet before it reaches the payer, and that approval is part of what the step logs. The same read/draft/write-or-send separation applies to any agent with access to an external system; least-privilege tool access for AI agents covers the general pattern this article applies to one workflow.
The reason is practical: a submitted PA is an administrative act on the provider's behalf, and a stale payer rule or mismatched service code doesn't just fail quietly — it can trigger a denial or a delay someone has to track down. Catching that before it goes out avoids having to unwind it after, the same principle behind keeping a person in the loop generally: human-in-the-loop AI governance covers how to set the limits that decide when any AI agent escalates rather than acts.
How does an agent handle missing documentation?
It names the specific gap instead of guessing or filling it in. During collection, the agent compares the payer's requirement list against the chart and referral, and anything it can't find — a signed order, a lab value, a prior-treatment note — gets listed by name, not summarized as "incomplete." The packet routes to the missing-documentation queue above.
- A missing field: a date or identifier the form requires but the referral didn't include.
- A missing attachment: an order or report the payer's requirement list names specifically.
- A mismatch: a referral for one service when the chart supports a different one.
The packet stays open and paused, not auto-submitted incomplete and not auto-denied by the workflow itself. Staff request the specific item from the referring provider or patient, and work resumes once it's in — the same handling whether the gap surfaces during collection or later, in response to a payer request for more information.
What happens when a payer portal changes?
The payer-rule lookup and submission steps depend on systems outside the provider's control, so they fail closed instead of guessing. When a portal's login flow changes or a form adds a field, the step detects that the expected page no longer matches what it logged last time, stops, and routes to the IT/operations queue — the same route a 278 rejection uses. A changed or stale payer requirement is different: the lookup step routes that to the Policy queue instead, for a reviewer or payer-relations staff to confirm.
Phone stays part of the design: in the AMA's 2025 survey of 1,000 practicing physicians, phone was the most commonly reported method for completing PAs for medical services, and only 24% said their EHR offers electronic PA for prescription medications [1]. A design that assumes every payer takes a clean electronic submission stalls on the payers that don't. Dating every rule lookup is worth doing too: it can catch a requirement that changed quietly before it turns into a denial.
Where to start: a first scoped workflow
A first version is scoped narrow on purpose: one payer, one service line, every exception route built before the agent touches a live request.
- Pick one payer and service line
A high-volume, well-documented combination, not every payer at once.
- Map the current manual steps
What staff do today for that line, including every channel: portal, fax, phone.
- Apply the permission matrix
Assign each step a label from the matrix above, and name the reviewer for each approval point.
- Build the exception routes first
Stand up each queue above before the agent goes live.
- Run a shadow period
The agent drafts while staff still submit manually; compare drafts and flags against what staff did.
- Review, then expand
Once the measures below hold steady, add the next payer or service line.
Measure the workflow by step, not only start to finish:
- Turnaround by step: triage to submission, submission to decision, decision to appeal.
- Reviewer minutes per packet: how long an approval actually takes.
- Exception rate by type: how often each taxonomy row fires, so a spike is visible early.
- Queue depth at each exception route, not just the overall backlog.
- First-pass completeness: how often a draft needs no further information before submission.
For a human step with its own response-time target, what happens to the SLA when an AI agent hands off to a human covers reporting that stage separately from the agent's own.
When this design doesn't apply
- Volume is too low to justify six named exception routes.
- The payer relationship is entirely phone-based; that channel work stays manual regardless of what drafts the packet.
- Documentation is chronically incomplete at referral; the bottleneck is upstream of intake, not in it.
- There's no reviewer capacity to approve submissions promptly — an unapproved queue is worse than the manual process it replaced.
Frequently asked questions
How do you measure turnaround and reviewer workload?
Track turnaround by step, not only end to end: time from triage to submission, submission to payer decision, and decision to appeal when needed. Pair that with reviewer minutes per packet and an exception rate broken out by type, so a growing queue shows where the bottleneck sits before it becomes a backlog.
What does human-in-the-loop mean for prior authorization intake automation?
It means every step that changes what a payer sees stays behind a named person. An agent may read records, draft a packet, or flag an exception, but submission only happens after a reviewer approves it, and medical-necessity or clinical-criteria questions are decided by clinical or authorization staff, never by the agent.
Can an agent read the EHR directly, or should it work from a queue?
Either can work, provided the read scope is narrow: the agent reads only the fields and documents a given request needs, through a defined integration or a work queue built for it, not an open-ended EHR session. We recommend a dedicated queue: it's simpler to scope, log, and audit than broad EHR access.
Does intake automation work with payers that still require fax?
Yes. A workflow built this way routes a drafted packet to whatever channel a given payer accepts — a portal, a clearinghouse transaction, or fax — rather than assuming every payer takes the same electronic format. The exception route for a channel failure applies to fax the same way it applies to a portal.
What is the X12 278 transaction?
X12 278 is the transaction set X12 publishes as "Health Care Services Review – Request for Review and Response." It defines an electronic data interchange (EDI) format for exchanging that type of request and response as a standardized document, rather than setting any clinical or coverage criteria.
Related reading
- The next step: document review with human approval — the broader pattern behind reviewer sign-off before anything relies on an extraction.
- For the front end of the patient journey, AI patient intake and scheduling covers referral-to-visit scheduling, a separate workflow from PA intake.
- For the principle behind every approval point above, see human-in-the-loop AI governance.
- For the access-design pattern behind read/draft/submit separation, see least-privilege tool access for AI agents.
- For reporting turnaround once a reviewer is in the loop, see the SLA clock after an AI handoff.
More in Document intelligence
340B Program Documentation: Where AI Agents Reduce Audit Risk (Not Replace Compliance Officers)
How AI agents can assemble 340B program documentation, from split-billing records to contract pharmacy files, while your compliance officer keeps each decision.
Pharmacy ChainsChargeback and Returns Dispute Document Automation for E-Commerce Brands
Chargeback and returns dispute automation for e-commerce: a step-by-step dispute-document workflow and evidence table, with submission kept with your staff.
Ecommerce OperationsJoint Interest Billing and Land/Lease Administration Document Automation for Independent Energy Operators
Joint interest billing automation for independent operators: a lease-to-distribution workflow showing what an agent drafts and what staff approve.
Utilities and Energy Companies