Prior auth, submitted, tracked, and appealed, with a human hand on every payer touch.
Prior-Auth Autopilot pulls the chart, assembles the payer-specific packet, submits it, chases the status, and drafts the appeal when it gets denied, so the authorization lands before the appointment instead of after it. It is an autopilot, not an autonomous bot, so it stops and asks a human before it reads a record, before it submits to a payer, and before it files an appeal.
Book a prior-auth pilot See a sample assembled packet
THE PROBLEM
A clinician orders the procedure, and then someone on your team spends the afternoon in ten payer portals, copy-pasting from the EMR, hunting for the one clinical note the payer wants, and refreshing a status page that never updates. When the denial comes back (and a lot of them do), the appeal is another day of the same work, and by then the appointment date has already slipped. As of January 1, 2026, the CMS Interoperability and Prior Authorization Final Rule puts the decision clock on the payer (72 hours for urgent, 7 calendar days for standard), which reads as relief, except it only helps if you can get a clean packet in the door fast enough, so the bottleneck quietly moves from the payer to your own assembly queue.
HOW IT WORKS
Prior-Auth Autopilot runs the whole lifecycle as one composed workflow, and it stops at a human checkpoint every time it is about to touch a patient record or a payer. It validates the request, pulls the clinical record from your EMR (with your coordinator's sign-off), scrubs PHI on the way through (twice), reads the clinical picture, assembles the payer-specific package, and shows it to a human before anything is submitted. You approve, it submits, it tracks the status for you, and if the payer denies, it drafts the appeal letter against the denial reason and hands that back to a human too. Five human checkpoints, not zero. The clinical judgment stays with your clinicians and coordinators; the portal drudgery is the part that goes on autopilot.
WHAT YOU GET
- An assembled, payer-specific PA packet built from the actual chart, ready for a human to approve before it goes anywhere. - Submission and status tracking through the payer surface, so nobody is refreshing a portal. - A drafted appeal letter written against the denial reason when a request comes back denied, so the fight starts the same day instead of next week. - A PHI-scrub receipt and a human-approval record at every payer and record boundary, the same auditable shape of proof AYA uses on its own work.
An agent that does the coordinator's worst hours, not one that acts behind your back.
WHO IT'S FOR
Revenue-cycle and prior-authorization teams at specialty practices and health systems that are drowning in payer-portal work, first, then digital-health and care-navigation companies that submit prior auths on behalf of patients and want an auditable, human-gated agent instead of an offshore queue. If you want a bot that submits without anyone reviewing it, this is deliberately not that, because none of this should happen to a patient record unsupervised.
PRICING
Prices are hypotheses we want to prove on your own volume, not a rate card.
- Pilot (fixed price, roughly $7,500 to start): a paid proof on your own backlog of pending prior auths, so you see turnaround, first-pass approval rate, and coordinator hours saved before you commit to anything. - Value-metered (roughly $12 per completed authorization): once the pilot proves the delta, you pay per authorization we carry through submission, tracking, and appeal drafting. - Platform license: the full Luigi PA lifecycle and payer-overlay maintenance into your stack, priced by value and negotiated. The IP is licensed, never assigned.
Any step that moves money or submits to a payer is fail-closed and asks a human first.
PROOF (how we dogfood it)
AYA runs this product's own discipline on itself. Every capability we ship ends as a verification receipt, the same shape of auditable proof the PA wizard's checkpoints and PHI-scrub steps produce. This very page came out of that discipline: the workflow behind the product (a 20-step sequence with 5 human checkpoints and a double PHI scrub) was quality-scored before we wrote a word of marketing (it scored 93 out of 100, an A), and all 17 of its building blocks were verified present before this page published. We are selling the receipt, so we make the build leave one.
HONEST NOTE
This has not yet been run against a live EMR or a real payer portal with real patient data. Doing that needs a signed BAA, EMR read access, and payer-portal or API credentials, and that is a credentials-and-access gate, not a code gap, the workflow is built. No live submission, no live spend, and no approval-rate or turnaround number has been produced yet, so you will not find one quoted above as if it were real. When a pilot produces those numbers, they will be yours, from your backlog, and every payer-facing and record-facing step will still stop and ask a human first.
_This page is a specification. The capability it describes is not built yet, and nothing here is a claim that it runs today._