Prior authorization is an evidence workflow

An authorization coordinator opens a power-wheelchair request and finds an encounter record, but no finalized order. Highlighting the missing document helps. The remaining work is harder: request the existing record, match the reply to the case, check for conflicts, and give a reviewer a packet whose sources they can inspect.

The prior-authorization workbench makes that administrative loop visible. It uses original synthetic documents for a fictional California durable medical equipment supplier preparing an initial Medicare fee-for-service K0823 request, under a Noridian Jurisdiction D policy context. That narrow scope keeps the rules and their limits inspectable.

The result is a packet ready for administrative review. Medical necessity, payer authorization and payment remain separate decisions outside the application.

Follow one missing document

The demo begins with case-f02-loop. Its requirement matrix distinguishes a missing order from an unreadable record or conflicting evidence. Findings link to exact source versions and fields, so the operator can check why a requirement is unresolved.

Synthetic case at revision 1. Captured from the packaged rules workbench on 24 October 2026, with the agent graph off.

The operator prepares a neutral request for the existing finalized document, then approves its exact text. The request cannot ask someone to create or amend a clinical record to satisfy the application. A worker records a simulated delivery receipt; nothing leaves the local system.

Recording the archived synthetic reply creates revision 2 and triggers reassessment. The supplied order resolves this demo's missing-document finding. Other replies can leave conflicts unresolved. Receiving a document and having a usable packet are different states.

flowchart TD
  A[Inspect missing evidence and citations] --> B[Approve a neutral request for an existing record]
  B --> C[Record a simulated delivery receipt]
  C --> D[Attach the archived synthetic reply]
  D --> E[Create a new revision and reassess]
  E --> F[Human reviews the exact administrative packet]

The final reviewer sees the packet's document list, findings, revision and content hash. Acceptance records an administrative decision against that exact packet. The clinical-review requirement remains visible.

The synthetic packet after reassessment, before the fixture reviewer makes a decision. Rules mode, agent graph off; this is not a payer approval.

Keep approval tied to what was reviewed

A new reply can arrive while an operator has an older tab open. The API therefore binds approval to the case revision, source snapshot, policy and packet. A changed binding invalidates the old decision.

Commands also carry an identity and payload hash. An identical replay returns the stored result; reusing that identity with different content is refused. Approval and its background job are written in one database transaction, and simulated delivery produces a unique receipt. These controls address interrupted requests without treating another click as a new action.

The implementation separates a Next.js interface, Fastify API and worker in one supervised application container, with PostgreSQL alongside it. The database stores source bytes, case revisions, review decisions and jobs. LangGraph checkpoints record investigation progress separately from authoritative case state.

Give the agent a bounded investigation

The optional agent can list documents, read them, inspect policy and propose cited facts or document requests. The API checks each proposed fact against its source version, content hash, field location and value. Valid proposals still wait for human review. Deterministic rules control readiness.

A source citation in the rules workbench. The documents are structured synthetic JSON; this screen does not demonstrate extraction from arbitrary PDFs.

The default deployment disables the graph. Recorded mode runs a scripted provider through the real workflow. Live mode uses Claude with explicit cost admission. These modes establish different things: a scripted rejection tests a boundary, while a live evaluation observes model behavior.

What the evaluation actually showed

The 21 October live report records one run of Claude Opus 5.5 across 22 synthetic cases:

• All 223 accepted fact proposals matched source evidence and deterministic extraction.
• Four of six proposed document requests passed the applicability gate; two were rejected.
• The run used 128 provider calls and cost about USD 1.84. Median case latency was 33.7 seconds, versus about 2 milliseconds for rules alone.

Both arms produced the same issue findings. The graph inherits those findings from deterministic code, so their equal scores do not demonstrate an agent improvement. The evaluator also mirrors the API's proposal checks; this run is not proof of the packaged live interface.

A separate four-case baseline found all 14 required facts with rules alone, but produced no request for the one useful follow-up target. That baseline emits no requests by design. It leaves a specific contribution to investigate: selecting appropriate follow-up work. It does not establish reduced reviewer effort. Its scripted agent examples test the scorer, and its detectors cover tool calls and proposals, not final narrative advice.

The public repository includes Compose setup, framed screenshots and the reports. The implemented boundary is deliberately local: synthetic records, simulated exchanges and administrative review. There is no EHR or payer connection, FHIR conformance claim or measured customer time saving. The useful engineering result is an inspectable request-and-review loop; the incremental value of model-led investigation remains unproven.

Editorial archive date: 22 October 2026. Revised 24 October against public snapshot 1cbc5c9; evaluation dates above identify historical runs, not a fresh run of that snapshot.