AI voice agent for prior authorization calls: eligibility, auth and claim status

What it is

On this page the agent is the caller. It takes a work-queue item from the practice system (verify eligibility and benefits, check a prior-authorisation status, submit a prior-authorisation request, chase a claim), assembles everything the payer will ask for, dials the payer's provider line, listens to the phone tree, presses or speaks the right options, waits on hold for as long as it takes, and when a representative answers it asks the question, answers the representative's verification questions, captures the answer and the reference number, reads the number back digit by digit, and writes the result to the practice system with the representative's name and a timestamp.

The hard parts are not conversational. They are navigating a phone tree that changes without notice, sitting silently through hold music without transcribing it as speech, waking up within a second when a live voice appears, and getting a twelve-character alphanumeric reference exactly right.

Revenue-cycle teams buy this as payer call automation. Dental offices buy it as insurance verification calls. Same mechanics, different volume.

Who buys it

• Revenue-cycle and patient-access leaders in health systems and large groups, where payer phone time is a staffed queue measured in full-time equivalents.
• Dental and specialty practice managers whose front desk spends the quiet hours on insurance verification before tomorrow's schedule.
• Billing companies and revenue-cycle outsourcers working claims and authorisations for many practices against the same handful of payers.

Budget owner: the revenue-cycle or operations lead. Compliance signs off the business associate chain and what the agent may say to a payer; IT signs off the write-back into the practice system or work queue.

KPIs

Time one week of payer calls first: dial, IVR, hold, conversation, documentation. That is the baseline, and the hold minutes are usually the largest part of it. Then track the KPI strip above: completed inquiries with a reference number, staff hours returned, captured-field accuracy, IVR navigation success by payer, pre-call data completeness, and disclosures limited to the inquiry.

Two measurement traps. An inquiry is complete only when the reference number and the representative's name are in the practice system; "spoke to the payer" is not an outcome. And navigation success must be tracked per payer, because one payer's menu change can halve the overall rate in a week without any change on your side.

Demo script

Run the condensed script below against recordings of your own top payer's IVR and hold loop, with a staff member playing the representative. Each step has a trap.

1. Pre-dial pack. Pick a sandbox patient with a scheduled procedure. Pass: one lookup returns the provider identifier, member identifier, date of birth, coverage on file and the service codes together, and eligibility is confirmed from that same result before the dial. Fail: a second round trip for eligibility, or a dial with a missing field.
2. IVR navigation. Play the payer's recorded menu. Pass: the agent waits for the menu to finish, selects the provider-services path by tone or speech, and enters the provider identifier when prompted. Fail: it talks over the menu or presses before the options are read.
3. IVR navigation failure. Play a version of the menu with the options reordered. Pass: the agent notices the mismatch, tries the configured fallbacks (zero, "representative"), and if those fail it logs the menu state and queues the inquiry for a person. Fail: it presses the old option and proceeds as if nothing changed.
4. Hold. Play 20 minutes of hold music with two recorded "your call is important" interruptions. Pass: silence throughout, no transcribed phantom words, and a response within one second when the representative speaks. Fail: it hangs up, speaks to the music, or needs several seconds to notice the human.
5. Representative verification. The representative asks for the provider identifier, member identifier and date of birth. Pass: each read out in grouped digits at a human pace, with the alphanumerics spelled clearly.
6. Interruption. While the agent states the service codes, the representative cuts in with "I only need the first one." Pass: it stops and continues from the representative's question.
7. Criteria questions. For a prior-authorisation submission the representative asks two clinical criteria questions. Pass: the agent answers only from information the practice supplied in the work item and says plainly when it does not have an answer. Fail: it fills a gap with a plausible "yes."
8. Confirmation before submission. Pass: the agent summarises the request and gets a clear go-ahead before it asks the payer to submit; a "wait, hold on" cancels the step.
9. Reference number. The representative speaks a reference number quickly: letters and digits mixed. Pass: read back digit by digit in groups, a correction accepted, and the confirmed value written with the representative's name and a timestamp. Mumble one character on purpose and check that it asks.
10. Eight seconds of silence from the representative after a question. Pass: one polite check-in, then patience. Fail: it repeats the whole question or treats the silence as a hang-up.
11. Disclosure. The representative asks "am I talking to a recording?" Pass: a plain statement that it is an automated assistant calling on behalf of the named practice, with an offer to connect a staff member.

Score each trap pass or fail. A vendor who wants to run the demo from their own audio has not passed the demo.

Compliance notes

In the United States, the agent speaks member identifiers, dates of birth and service codes to a payer on behalf of a covered entity, so the vendor is a business associate. The rule as published at 45 CFR 164.502(e) allows the disclosure only with satisfactory assurances in a written contract or arrangement, and the minimum-necessary standard at 164.502(b) applies to what the agent says: the fields the inquiry needs, nothing else. The TCPA's consent rules are framed around calls to residential and wireless consumers; a call to a payer's provider line is a different situation, but the identification duties for artificial-voice calls and the payer's own policy on automated callers still apply, and several states have bot-disclosure laws, so disclose when asked. CMS-0057-F requires impacted payers to implement a Prior Authorization API by 1 January 2027 and, from 1 January 2026, to decide expedited requests within 72 hours and standard requests within seven calendar days with a specific reason for any denial. For those payers, phone volume should fall over time; commercial plans, dental benefits and claim-status calls are outside the rule's scope.

In the United Kingdom and the European Union, the call content is special-category data about the patient, so the lawful basis and the processor contract must cover it, and Article 50 of the AI Act requires disclosure of the AI interaction from 2 August 2026 where the agent is interacting with a person. In India, the Digital Personal Data Protection Act governs the patient data spoken to a third-party administrator. In Australia, health information is sensitive information under the Privacy Act and many funds and practices require onshore processing. The compliance rows for your regions are listed on this page. They are informational, not legal advice.

Build or buy

Buy a packaged product if your payer mix is dominated by large national plans whose phone trees vendors already map, and your practice system is mainstream; the IVR libraries and the hold handling are the hard parts. Consider a platform or a build if you are a revenue-cycle outsourcer working dozens of regional payers, or if the work queue and write-back live in a system of your own. In either case the acceptance test is the same: your payer's recorded menu navigated, 20 minutes of hold survived in silence, a mumbled reference number caught and read back, and the result in your system with a name and a timestamp.