What this automation does
Prior authorization is mostly a search problem. The coordinator knows what the payer wants, and spends the time hunting through the chart for proof. This workflow does the hunting and drafting, and leaves judgment and signatures with people.
- Detect. When an order is placed for imaging, a procedure, an infusion, durable medical equipment or a specialty drug, the workflow checks a rule table of payer and code combinations your auth team maintains. Matches open a case. Unknown combinations go to a coordinator to check the payer’s current list.
- Confirm coverage. An eligibility check confirms the patient’s active plan before any work starts, because a changed plan makes the whole packet go to the wrong payer.
- Gather. The workflow pulls only what this service needs: diagnosis codes, the visit note documenting the indication, prior treatments with dates, and relevant lab or imaging reports from a capped date range.
- Map to criteria. The coordinator attaches the payer’s clinical policy for the service. The model lists each criterion and returns the supporting quote, note and date from the chart, or “not found in chart”.
- Draft. The model fills the payer form or electronic questionnaire fields and drafts a letter of medical necessity from a template your clinicians wrote. Every clinical sentence carries a citation.
- Review and sign. The coordinator checks completeness. The ordering clinician reads and signs the letter. Nothing goes out unsigned.
- Submit and track. Staff submit through the payer’s channel and log the reference number. Scheduled checks and reminders follow up until a decision arrives, and approved auth numbers, units and date ranges are written back to the order.
- Handle denials. When a denial letter arrives, the model summarizes the stated reason and drafts an appeal outline from the cited chart evidence for clinician review.
When it is worth building
This is worth building when coordinators spend most of their day assembling packets, when services get rescheduled because authorizations arrive late, or when denials cite missing documentation that was actually in the chart.
It is not worth building when volume is low, when your EHR’s or clearinghouse’s built-in electronic prior authorization already covers your main payers, or when nearly all requests are pharmacy requests that already flow through dedicated ePA tools. Buy before you build.
Payer rules also change. CMS’s Interoperability and Prior Authorization final rule (CMS-0057-F) requires Medicare Advantage plans, Medicaid and CHIP programs and plans, and qualified health plans on the federal marketplace to offer an electronic prior authorization API for items and services other than drugs, with a compliance date of January 1, 2027. Most of those payers also had to meet faster decision timeframes starting in 2026. Commercial payers outside those programs move at their own pace. Design for a mix of portals, electronic requests and fax for some time, and keep payer-specific logic in a table staff can edit, not in code.
Architecture
| Layer | What we use | Why |
|---|---|---|
| Order detection | EHR API events or a scheduled order report | Starts the case the moment an order exists |
| Rule table | A Postgres table owned by the auth team | Which payer and code pairs need auth is a lookup, not a model guess |
| Chart retrieval | EHR FHIR or vendor APIs with a read-only service account | Pulls notes, conditions, medications and results with minimum necessary scope |
| Evidence mapping and drafting | Claude through an API arrangement covered by a BAA | Handles long clinical notes and returns quotes with sources |
| Quote verification | A code step that string-matches every quote against the source note | Blocks invented evidence before a person ever sees it |
| Orchestration | Self-hosted n8n or a small Python service on HIPAA-eligible cloud | PHI stays in your environment |
| Work queue | A review screen with case status, criteria checklist and due dates | Coordinators work one queue instead of six portals and a spreadsheet |
How to build it
- Pick two or three services. Choose the highest-volume ones, for example advanced imaging or a common procedure. Review recent submissions and their outcomes to see what documentation each payer actually asked for.
- Build the rule table with the auth team. Payer, plan type, code, whether auth is required and the policy document. Set a monthly review date on every row.
- Sign BAAs and scope access. Cloud host, model provider, fax vendor and anyone else touching PHI. Give the service account read access only to the resource types the workflow needs.
- Define retrieval per service. Which note types, which date range, which results. Pulling the whole chart is slower, costs more and breaks the minimum necessary standard.
- Write the criteria-mapping prompt. Input is the criteria list and the retrieved excerpts. Output is strict JSON: criterion, quote, note ID, date or “not found”. Then verify every quote verbatim in code.
- Draft from verified evidence only. The letter template is the clinicians’ wording. The model fills it only from quotes that passed verification.
- Route gaps back to the clinician. “Not found” criteria go to the ordering clinician, who decides whether the care was documented elsewhere or whether the request should go forward at all. Any addendum follows your compliance policy.
- Track and write back. Store reference numbers, follow-up dates, decisions, auth numbers and approved date ranges, and push them to the order so scheduling cannot book outside the window.
The retrieval pattern follows our guide on connecting an LLM to internal data safely. If you have tried screen-scraping bots on portals before, our RPA vs AI agents comparison explains why we keep submission manual.
What breaks in production
- Stale payer policies. A criteria document from last year produces a confident, wrong packet. Show the policy’s effective date on every case and expire rows on schedule.
- Faxed outside records. Outside imaging reports often arrive as low-quality scans. Run them through a vision model, and flag pages it cannot read instead of skipping them.
- Copy-forward notes. Old text carried into today’s note looks current. Use note dates, and prefer the original source note for each fact.
- Code mismatches. The payer approves a different CPT code or fewer units than the scheduled service. Compare approval against the order and alert before the visit.
- Urgent requests sitting in a queue. Expedited cases go straight to a person with an alert, never into the normal batch.
- EHR API approval. Epic and athenahealth access usually requires a partner program or your organization’s approval. Start that request in week one, because it often sets the go-live date.
Timeline and cost
The first two or three service lines typically take five to eight weeks. Lumeor builds prior authorization automation in the range of $20,000 to $55,000. The low end is one EHR, one specialty and a review screen where coordinators copy approved details back. The high end covers several specialties, structured EHR write-back, denial and appeal drafting, and status tracking across many payers. Model usage per case is higher than simple form extraction because clinical notes are long, but it is usually small next to coordinator time. See what a custom AI agent costs for how we scope these.
How to measure success
- Coordinator minutes per submission
- First-pass approval rate, by payer and service
- Requests returned by the payer for missing information
- Days from order to decision
- Visits rescheduled because authorization was late
- Rate of “not found” criteria, which shows documentation gaps to fix upstream