Prior Auth Copilot
Reads a prior authorization request and its clinical records, checks them against the coverage policy one criterion at a time, and gives the nurse reviewer a recommendation in which every finding links to a sentence in the record.
Faster reviews under tighter deadlines
Under the CMS Interoperability and Prior Authorization final rule (CMS-0057-F), impacted payers must decide expedited requests within 72 hours and standard requests within 7 calendar days, starting in 2026. Most of a nurse's review time goes to reading notes and matching them to policy criteria. That step is well suited to a language model, provided its output can be checked and the decision stays with a clinician.
A fixed workflow, not an open-ended agent
| Step | Who does it | Why |
|---|---|---|
| 1. Policy lookup | Code | The service code determines the policy. Retrieval is deterministic, so the wrong policy can't be picked. |
| 2. Identifier redaction | Code | Names, dates of birth, MRNs and phone numbers are removed before any text leaves the plan's boundary. |
| 3. Criteria evaluation | Claude Opus 5.5 | For each criterion: met, not met or insufficient, with verbatim quotes. Output is constrained to a JSON schema. |
| 4. Citation check | Code | Each quote must appear word for word in the cited document. A finding with no verifiable quote is downgraded to "insufficient". |
| 5. Routing | Code | All met → recommend approval. Anything missing → request info. Anything not met → nurse review. The copilot never recommends denial. |
- Model
- Claude Opus 5.5, medium effort, structured output, server-side fallback on a safety decline
- Cost control
- System prompt cached; per-visitor daily cap; replay mode when no key is set
- Prompt-injection defense
- Records are wrapped as data, and nothing the model writes can change routing
- Deadline tracking
- Due time computed from receipt: 72 hours expedited, 7 days standard
Measured against labeled cases
Live run on claude-opus-5-5, 2026-11-01. Labeled set: 3 synthetic cases, 12 criteria.
| Metric | Result | Definition |
|---|---|---|
| Criterion accuracy | 100% | Final status (after the citation check) matches the reviewer label |
| Routing accuracy | 100% | Case routed to the same queue the reviewer chose |
| Citation verification rate | 100% | Quotes found verbatim in the cited document |
| Unsafe approvals | 0 | Cases recommended for approval that the reviewer would not approve (target: 0) |
Three cases demonstrate the pipeline; they don't make a benchmark. The next step is a labeled set of 150 to 300 synthetic cases across 10 policies, with a nurse reviewer providing the labels.
Three synthetic requests
What changes at a real health plan
Integration
- Intake from the UM platform via X12 278 or FHIR Da Vinci PAS
- Policies loaded from the plan's medical policy library, versioned and effective-dated
- Hybrid search over policies when the service code alone doesn't identify one
Governance
- Claude through Amazon Bedrock under the plan's AWS BAA, or the Claude API with a BAA
- Audit log of inputs, outputs, reviewer action and policy version per case
- Model risk review, drift monitoring, and periodic re-labeling of a sample
The same engine in TypeScript and Java
Both versions return the same JSON for every demo case. Contract tests generated from the TypeScript engine run against the Java service on every build.
TypeScript (this site)
- Engine: the model call, checks and decision rules
- API route and pages
- Synthetic data and recorded runs
Java (Spring Boot)
- pa-engine-java: the service, with its contract test
- payer-ai-common: shared model calls, live limits and checks
- Contract tests: the expected output for each case