Auto-Approval Without Auto-Denial: The Compliance Line in Prior Authorization Automation

Every UM operations leader is being asked the same question right now: how much of the prior authorization queue can we automate? The honest answer is "a lot of the approvals and none of the denials," and the difference between those two halves is not an engineering preference. It is a regulatory line with a citation attached. Teams that internalize the line early build automation programs that survive audits; teams that discover it late build rules engines they have to partially dismantle.

What auto-approval actually is

Straight-through processing in prior authorization means a request arrives, a rules engine evaluates it against structured clinical criteria, and an approval goes back — no human touch, minutes instead of days. In EDI terms, the 278 response carries HCR01 = A1, certified in total, and nobody at the payer ever opened a case.

The evaluation itself is unglamorous: is the member eligible on the service date, is the service actually on the PA list, does the requesting provider check out, and do the clinical facts in hand — diagnosis codes, prior treatment history, structured questionnaire answers — satisfy a criteria set the medical policy team has approved for automated disposition? When every check passes, the system approves. The design question that matters is what happens when a check fails.

The regulatory line: automating "no"

For Medicare Advantage, the line is explicit. Under 42 CFR 422.566(d), if an MA organization expects to issue a partially or fully adverse medical-necessity decision, that organization determination must be reviewed by a physician or other appropriate health care professional — with expertise in the field of medicine appropriate to the service, and knowledge of Medicare coverage criteria — before the decision is issued. Not after. Not on appeal. Before the determination goes out the door.

CMS's February 2024 FAQ on the 2023 MA final rule (CMS-4201-F) addressed the algorithm question directly: an algorithm or software tool can be used to assist in making coverage determinations, but the MA organization remains responsible for ensuring the decision complies with all applicable rules — including 42 CFR 422.101(c)'s requirement that medical-necessity decisions be based on the individual patient's circumstances, such as medical history, physician recommendations, and clinical notes. An algorithm that decides coverage from population-level data rather than the individual record is, per the FAQ, not compliant.

Medicaid managed care has a parallel rule. Under 42 CFR 438.210(b)(3), any decision to deny a service authorization request — or to authorize less than requested in amount, duration, or scope — must be made by an individual with appropriate expertise in addressing the enrollee's medical, behavioral health, or long-term services and supports needs. Note the "less than requested" language: a partial approval is on the denial side of the line, not the approval side. An engine that auto-approves 8 of 12 requested visits has made an adverse determination and needs a clinician in the loop.

One boundary worth drawing precisely: an intake rejection is not a medical-necessity denial. A 278 bounced with an AAA code for a bad member ID never became a reviewable request, and returning it automatically is normal transaction processing, not an adverse determination. The line guards clinical judgment, not schema validation. But the closer an automated "administrative" closure gets to the merits — closing a request because documentation never arrived, for instance — the more it deserves compliance review before anyone calls it administrative.

Designing a rules engine that can only say yes

The clean architecture drops out of the regulation almost mechanically: the engine has two outputs, approve or route to a human. There is no automated deny path to misuse.

• Automate sufficient conditions, not necessary ones. The automated criteria set should be a conservative subset of the full medical policy: conditions that, when met, are sufficient for approval. Failing the subset means "a human applies the full policy," never "denied." This asymmetry is the whole design.
• Fail open to review, at every layer. Missing data, an unmappable code, a criteria version mismatch, a timeout — every failure mode lands in a review queue with the clock still visible. An exception path that silently closes requests is an automated denial wearing a trench coat.
• Version the criteria like code. Every automated approval should be reproducible: which rule set, which version, effective when, approved by whom on the medical policy committee. When policy changes, old decisions must still be explainable under the version that made them.
• Give clinicians the kill switch. Medical policy owners should be able to pull a service category out of automation without an engineering deploy — criteria drift is discovered clinically, not in code review.

Audit trails for decisions no human made

When a human reviewer decides, the case file records who and why. When software decides, the audit trail has to be constructed deliberately, and it needs to survive scrutiny years later — MA program audits, state market conduct exams, and litigation discovery all move slower than your release cadence. For every automated determination, persist at minimum:

• the input snapshot — the request content and every data element the rules consulted (eligibility result, history pulled, questionnaire answers), as they were at evaluation time;
• the rule and criteria versions, with pointers to the governance approval of each;
• the evaluation trace — which conditions passed, in enough detail to reconstruct the decision without re-running the engine;
• timestamps for receipt, evaluation, and response, since automated approvals anchor the favorable end of your published decision-time averages;
• the disposition path — auto-approved versus routed to review, and if routed, why.

The test is simple: could you hand a regulator the full story of one automated approval from three years ago in an afternoon? If reconstructing it requires archaeology across log retention policies, the trail does not exist.

What auto-approval does to your metrics

Automation changes the published numbers from CMS-0057-F's public metrics requirement in ways worth anticipating rather than discovering. Average decision time falls, but bimodally: auto-approvals in minutes, human decisions unchanged. Report the average alone and you obscure the human queue; keep the internal split visible even where the public report blends it. Approval rate typically rises — the automated tier approves at 100 percent by construction — which is fine, and even a useful signal that prior review was friction rather than filter for those categories. Where the automated approval rate for a service category approaches 100 percent over sustained volume, the honest next question is whether that category belongs on the PA list at all, or belongs in a gold-carding program — automation at that point is paying the cost of review without the benefit.

Watch two second-order effects. First, criteria drift: the clinical evidence moves, and a rule set that was conservative in January is generous — or wrongly restrictive at the routing step — by September. Trend the auto-approval share by service code monthly and treat step changes as review triggers. Second, the routing boundary is where compliance risk quietly concentrates: everything the engine declines to approve becomes human workload, and if that queue is understaffed, your 72-hour and 7-day clocks breach precisely on the hard cases. Automation does not reduce the need for the time-to-breach discipline on the human queue; it concentrates it.

The one-sentence policy worth writing down for your compliance file: software may say yes, software may ask a human, and only a qualified clinician may say no. Every architecture decision in the program is a footnote to that sentence.

Verify the clinician-review requirements against 42 CFR 422.566(d), 42 CFR 438.210(b)(3), and CMS's February 2024 coverage-criteria FAQ for CMS-4201-F — and check your states' UM statutes, which can be stricter.