AI Agents for Prior Authorization With Sign-Off

An AI agent for prior authorization can do the preparation work. It can check eligibility, pull the right documents, fill the forms, and chase status. Staff and clinicians should keep the decisions.

That split is the whole design. The agent handles the typing, the lookups, and the waiting. A person signs off before anything goes to a payer, and a licensed clinician owns anything that turns on medical judgment.

This post covers what to automate, what to leave alone, how to log without leaking PHI, and what a safe pilot looks like.

Where Prior Auth Time Goes

Start with the burden, because it tells you where to point the agent.

The AMA’s 2024 physician survey (1,000 physicians, fielded December 2024) found practices complete an average of 39 prior authorizations per physician per week. AJMC’s coverage of the same survey puts the time at about 13 hours a week. The AMA also reports that 40% of physicians have staff who work only on prior authorization, and that 31% say requests are often or always denied.

Those numbers are physician-reported, and the sample is a panel survey. Use them as a sense of scale, not as your baseline. Your baseline comes from your own queue.

When I map a prior auth workflow, the time usually falls in five buckets:

1. Finding the rule. Does this payer, plan, and code need authorization at all?
2. Collecting the clinical evidence. Notes, imaging, labs, prior treatments.
3. Filling and sending the request. Forms, portals, fax.
4. Waiting and checking. Status calls, portal logins, follow-ups.
5. Handling the response. Approval, pend, denial, appeal.

Buckets 1, 2, 3, and 4 are mostly lookup and assembly work. Bucket 5 includes judgment. That is the line.

Fax and re-keying are still common. The HL7 Da Vinci Prior Authorization Support guide says as much: few EHR systems implement the standard X12 278 interface, so requests often go by fax or payer-specific portals where staff re-key the same data. That is the kind of work an agent can absorb.

Preparation Tasks the Agent Can Own

These are good agent jobs. Each is bounded, checkable, and reversible.

• Eligibility and benefits check. Confirm the patient is active on the plan and what the plan says about the service. The agent reads the response and writes a short summary.
• “Does this need prior auth?” lookup. Compare the planned service and payer to a rules table your team maintains. The agent flags yes, no, or unsure. Unsure goes to a person.
• Packet assembly. Pull the order, the relevant notes, the imaging report, and the lab results from the chart. Put them in the order the payer expects.
• Completeness check. Compare the packet against the payer’s checklist. List what is missing. Ask the care team for it.
• Draft the request. Fill the form fields from the chart. Draft the letter of medical necessity for a clinician to edit. Mark every statement with the chart source it came from.
• Status tracking. Check the portal or API on a schedule. Record status changes. Alert the owner on a pend or a deadline.
• Work queue sorting. Rank open cases by decision deadline and urgency, so staff work the oldest and the most urgent first.

A hypothetical example. Say a staffer opens a case for an outpatient MRI. The agent confirms coverage, flags that this plan requires authorization for this code, assembles the last two clinic notes and the prior imaging report, notes that a conservative-therapy record is missing, and drafts the request. The staffer sees one screen with a checklist and sources. That is much less typing than starting from a blank form.

Decisions That Stay Human

Some steps should not belong to the agent. My list:

• Medical necessity judgments. Whether the service is clinically appropriate is for a clinician. The agent may surface the payer’s criteria next to the evidence. It does not decide.
• Final submit. A named staff member reviews the packet and presses send. This is the sign-off.
• Clinical content in the letter. A clinician reviews and signs anything that states a clinical argument.
• Peer-to-peer calls and appeals. People talk to people.
• Denial strategy. Whether to appeal, resubmit, or change the order is a clinical and business call.
• Patient communication about coverage. Sensitive and context-heavy.

This lines up with where regulators are heading, even though the rules I cite target payers. California’s SB 1120, signed in September 2024, says a medical necessity denial or modification can only be made by a licensed physician or a professional competent to evaluate the clinical issues. It applies to health plans, not providers. But if a state is saying a human must own the denial side, your provider-side agent should not be making judgments on the request side without a person either.

For the design pattern, see human-in-the-loop AI agents. The short version: make approval a real step with real information, not a rubber stamp. Show the reviewer the sources, the gaps, and the agent’s uncertainty.

Logging and PHI

Prior auth data is protected health information (PHI). Logging is where well-meant projects leak it.

Three rules I follow.

1. Know who is a business associate. Under HIPAA, a covered entity can give PHI to a business associate only with a business associate agreement (BAA) in place. A business associate needs the same kind of agreement with its own subcontractors before passing PHI on. For an agent, that chain can include the agent builder, the model provider, the hosting provider, and any logging or monitoring tool that receives PHI. If a vendor in that chain will not sign, PHI does not go there.

2. Apply minimum necessary. HHS describes the minimum necessary standard as taking reasonable steps to limit use and disclosure of PHI to what the purpose requires, with role-based access. For the agent, that means it gets the fields it needs for the case at hand, not the whole chart. Note that HHS says the standard does not apply to disclosures to a provider for treatment. A request to a payer is not that, so assume it applies.

3. Log the action, not the patient story. The audit trail should answer who, what, when, and why, without copying clinical text into every log line.

A workable log record:

Field	Example	Contains PHI?
Case ID	internal ID, not MRN in plain text	Pseudonymous
Step	”eligibility_check”	No
Tool call and result code	”270/271 call, status active”	No
Source references	”chart doc ID 8841, note date”	Pointer only
Agent output hash or stored draft	Stored in the case system, encrypted	In the system of record, not the log
Reviewer and decision	”J. Rivera approved”	No
Timestamp	UTC	No

Keep raw prompts, model inputs, and drafts in the same protected store as the chart, with the same access rules and retention. Do not send them to a general-purpose logging tool. For what a complete trail should hold, see what to log in an AI agent audit trail. For the wider compliance picture, see AI agents and healthcare compliance and the HIPAA and SOC 2 checklist.

I am not your lawyer. Have your privacy officer and counsel review the data flow before any PHI touches the agent.

Payer Portals and API Options

The agent has to reach the payer somehow. You have four paths. They differ in stability.

Path	How it works	Strength	Weakness
Payer API (FHIR or X12 278)	Structured request and response	Stable, loggable, fast	Coverage varies by payer today
Clearinghouse or intermediary	One connection, many payers	Wider reach	Fees, varying depth
Payer portal automation	Agent drives the web portal	Works where nothing else does	Brittle, check each portal’s terms of use
Fax and phone	Manual or document-based	Universal	Slow, hard to track

Standards are moving toward the API path. The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) requires impacted payers to build a Prior Authorization API, with the API deadline generally January 1, 2027. The impacted payers are Medicare Advantage plans, state Medicaid and CHIP programs, Medicaid managed care plans, CHIP managed care entities, and qualified health plan issuers on the federal exchanges. The rule does not cover drugs.

The same rule sets decision timeframes: 72 hours for expedited requests and seven calendar days for standard requests, with operational provisions starting in 2026. It also requires a specific reason for a denial. Commercial payers outside these programs are not bound by it. In June 2025, HHS announced a voluntary insurer pledge that includes real-time approvals for most requests by 2027. A pledge is not a rule.

My advice: build the agent behind a thin connector layer. Today the connector may be a portal script or a clearinghouse call. Later it can be a payer API. The packet logic and the review step stay the same. And check, per payer, what is live now, not what is promised for 2027.

Measuring Turnaround and Denials

Pick numbers before you start, and measure the current process for at least a few weeks.

Turnaround metrics

• Time from order to submitted request (this is where the agent helps most).
• Time from submission to payer decision (the payer controls this).
• Touches per case: how many times a person handled it.
• Cases that sat waiting for missing documents, and for how long.

Quality metrics

• First-pass completeness: share of packets accepted without a request for more information.
• Denial rate and denial reasons, split by “missing information” versus “clinical criteria.”
• Overturn rate on appeal.
• Agent error rate: wrong code, wrong patient, wrong document, caught by the reviewer. Track every catch.

Load metrics

• Cases per staffer per day.
• Backlog age.

A caution. Do not claim the agent “cut denials” unless you compare the same payer, service type, and period. Denials depend on the payer and on clinical facts. The part you can honestly influence is “denied for missing or wrong information.” That category is where good packets help.

Also watch for a reverse effect. The AMA survey found 61% of physicians are concerned that AI will raise denial rates, which is a worry about payer-side AI. Track your own numbers so you can see the effect in your data.

A Safe Pilot Scope

Keep the first pilot small and boring.

Pick one lane:

• One service line (for example, outpatient imaging).
• Two or three payers with stable processes.
• No drug authorizations in the first round, since they follow separate pathways.

Pilot rules:

1. The agent prepares. A named staffer reviews and submits every case.
2. Run in shadow mode for the first batch: the agent prepares packets, staff do the work the usual way, and you compare.
3. Log every case with the fields above.
4. Hard stop: the agent never sends anything to a payer on its own.
5. Weekly review of every error and every “unsure” flag.
6. Exit criteria set up front: for example, first-pass completeness at or above your manual baseline, zero PHI incidents, and reviewers saying the screen saves them time.

Before go-live checklist:

• BAAs in place across the whole vendor chain.
• Privacy officer has reviewed the data flow.
• Access limited by role and by case.
• Audit log tested with a sample case.
• Kill switch and manual fallback documented.
• Baseline metrics captured.

Bottom Line

Let the agent prepare. Let people decide and sign.

The best prior auth pilot is narrow: one service line, a few payers, a named reviewer, no autonomous sends, and logs that point to the chart instead of copying it.

Next step: pull 30 recent cases from one service line and time each of the five buckets. That shows you where the hours go and where an agent can help.

FAQ

Can AI do prior authorization? AI can do much of the preparation: eligibility checks, rule lookups, packet assembly, form filling, and status tracking. It should not make medical necessity decisions or submit without a person’s sign-off. Think of it as a very fast assistant for the staff who own the case.

What should stay with staff? Medical necessity judgments, final submission, clinical content in letters of medical necessity, peer-to-peer calls, appeals, and denial strategy. A named person should review and approve each submission. Make the review screen show sources and gaps so the approval means something.

How do I log safely? Log actions, not clinical stories. Record case ID, step, tool result code, source pointers, reviewer, and time. Keep raw prompts, drafts, and model inputs in the same protected system as the chart. Make sure every vendor that can see PHI has signed a business associate agreement, and give the agent only the fields it needs.

How do I measure turnaround? Measure order-to-submission time, which the agent affects most, and submission-to-decision time, which the payer controls. Add first-pass completeness, touches per case, and denials split by missing information versus clinical criteria. Capture a baseline for a few weeks before the pilot and compare like for like.

What is a safe pilot? One service line, two or three payers, a named reviewer on every case, and no autonomous sending. Start in shadow mode, log every case, review every error weekly, and set exit criteria before you begin. Keep drugs out of the first round.

Three Ways to Work With TMA

Need an agent built? We deploy production AI agents in your infrastructure. Working pilot. Real data. Measurable ROI. → Schedule Demo

Want to co-build a product? We’re not a dev agency. We’re co-builders. Shared cost. Shared upside. → Partner with Us

Want to join the Guild? Ship pilots, earn bounties, share profit. Community + equity + path to exit. → Become an AI Architect