What prior authorization automation needs from your data
Automating prior authorization is as much a data problem as an AI problem. Here are the six inputs every decision depends on, where they usually break, and how to check yours.
Emerald Isle Consulting · October 2026 · 6 min read
Prior authorization is one of the most promising places for AI in a health plan. Most requests are routine, reviewers are stretched, and providers and members feel every day of delay. Automation can approve the clear cases, route the rest to the right reviewer, and draft the rationale for each decision.
But an authorization decision draws on more data than almost any other process in a plan. If one of those inputs is missing, stale or unreadable at the moment of the decision, the automation either can't decide or decides wrongly. Neither is acceptable for a decision about someone's care.
The six inputs every decision depends on
| Input | What goes wrong | Where it usually lives |
|---|---|---|
| The request: services and diagnoses | Codes missing, or only in a faxed form | Portal, fax or electronic request |
| Member eligibility and benefits | Today's coverage, not coverage for the date of service | Eligibility and enrollment system |
| Provider and network status | One clinician under several NPIs and TINs; stale network flags | Provider data system |
| Medical policy criteria | Criteria written as prose, not rules a system can apply | Policy documents and reviewer guides |
| Clinical documentation | Scanned images with no extracted text | Attachments, faxes, records |
| Decision history and rationale | Outcomes kept, reasons not; past decisions overwritten | Utilization management system |
Why the rationale matters as much as the decision
Authorization decisions get appealed, audited and reviewed by regulators. CMS's Interoperability and Prior Authorization final rule (CMS-0057-F) requires many payers to return decisions within set timeframes, 72 hours for expedited requests and seven calendar days for standard ones, and to give a specific reason for every denial.
That raises the bar on two grades. AI consumability: the inputs have to be readable fast enough to meet the clock. Lineage: every decision has to be traceable to the request, the criteria and the documentation it was based on, as they stood at the time.
An automated approval nobody can explain is a faster way to create an audit finding.
Where the data usually breaks
Eligibility as of the date of service. Retroactive changes often overwrite the past, so the system can say who is covered today but not who was covered on the day of the procedure. A model trained on today's view learns from information it won't have.
Medical policy as prose. Criteria live in documents written for human reviewers. Until they're expressed as structured rules, the automation can only suggest, never decide.
Clinical documents as images. The evidence that a criterion is met is usually in an attachment. If text isn't extracted and linked to the request, a model can't read it at decision time.
Decisions without reasons. Many systems keep the outcome of past reviews but not the criteria applied or the documents relied on. That leaves nothing to train on, and nothing to show an auditor.
How to check your readiness
- 01
Pick one service category. Start where volume is high and criteria are clear, such as advanced imaging, and list every system its decisions draw on.
- 02
Rebuild 50 past decisions as of their decision date. For each, try to retrieve the request, eligibility, provider status, criteria version and documents as they stood that day. Every gap you hit is a lineage or consumability finding.
- 03
Time the inputs. Measure how long each input takes to become available after a request arrives, against the timeframes you have to meet.
- 04
Check that criteria can be applied by a system. If a reviewer has to interpret the policy text, the first project is turning that category's criteria into rules.
The result is a short, ranked list: what blocks automation for that category, what would reduce its accuracy, and what creates audit risk. Fix the blockers for one category, prove it, then widen.
