AI Claims Adjudication

Standing up a new plan under classic rules engines can burn months of config that drifts from the actual contracts. I designed the ops UI for an agent-first claims pipeline so people can see confidence, the plan language behind a decision, and when a human has to take the wheel.

Role
Principal Product Designer
Team
AI Accelerator
When
Greenfield · design + working prototype
Impact
Agent pipeline + HITL review patterns
8 stages
Intake through encounter submission
HITL
Review queues when confidence is low
RAG
Decisions grounded in plan documents
Mock-first
FE/BE ship in parallel on one contract
GenAI / BedrockVue 3 · QuasarHuman-in-the-loopHealthcare ops
Claims pipeline operational dashboard
Pipeline: stages from intake through encounter submission

The problem

Classic adjudication leans hard on rules configuration. Benefit mapping, fee schedules, clinical edits: standing up a new plan can eat months, and the work drifts from the contracts themselves.

I sat with claims ops and plan configuration folks on that pain. AI can reason over plan language, but only if people trust it. They need confidence, exceptions, and source text. Nobody wants a black box that silently denies.

Research

  • SME interviews (claims / plan ops)
  • Competitive and rules-engine teardown
  • Task analysis of adjudication stages
  • Trust / failure-mode workshops
  • Wizard-of-Oz and mock-first prototypes
Participants
Claims operations, plan configuration stakeholders, AI Accelerator eng and product
Constraints
No silent auto-deny; decisions must be audit-ready; plan docs as source of truth over opaque rule IDs

Research was about trust, not model demos. With claims and plan stakeholders I mapped today’s path: where rules engines create multi-month onboarding, where operators lose the thread on exceptions, and what would make them reject an AI assist (black-box denials, missing source text, no human gate).

We treated the eight stages as real work and stress-tested UI concepts on mock pipelines before every AWS stage was live. That way we could learn the language for confidence, review queues, and document grounding without waiting on production agents.

What I owned

Product design for the Vue 3 / Quasar ops shell: pipeline, claims list and detail, review queue, agents, knowledge base, payments, and encounters. I partnered with platform engineering on the agent-first stack (Step Functions, Lambda, Bedrock / Nova Pro, RAG over plan docs).

Approach

Let people watch the pipeline, open the source, and take over when confidence is low—no silent auto-deny.

Hypothesis: if sources and human gates are obvious, ops will use the agents. Goal: high automation with no silent auto-deny, and a UI that stays stable as stubs flip to production.

  • One operational path: people shouldn’t guess which screen owns the next action across pipeline, list, detail, and review.
  • Trust surfaces: confidence, audit flags, and human review that never quietly finalizes high-risk outcomes.
  • Document-grounded decisions: link agent output back to plan language, not opaque rule IDs alone.
  • Mock-first delivery: a full local API contract so design and eng could iterate without waiting for every AWS stage to light up.
Claims list and search interface
Claims worklist: search, filter, open adjudication context
Human review queue for AI-flagged claims
Review queue: human-in-the-loop for exceptions and audit flags

The 8-stage pipeline

Intake/Parse → Eligibility → Benefit Adjudication → Pricing → Clinical Edits → Audit → Payment → Encounter Submission. Benefit adjudication uses RAG over plan documents. Later stages can run deterministic stubs while fee schedules and CMS tables load. Operators keep the same shell either way.

Where claims land after automated pass (pilot mix)
  • Straight-through (no human touch)61%
  • Soft review (spot-check / low risk)22%
  • Hard review (exception / audit flag)14%
  • Failed / requeue for reprocess3%

Illustrative distribution from pilot batches: goal is high automation with explicit human gates, with no silent auto-deny.

Plan onboarding effort (configuration-heavy vs document-grounded)
Before3–6 moTraditional rules & benefit mapping
AfterWeeksIngest plan docs + validate sample claims

Order-of-magnitude less config before first useful run

Directional comparison used with stakeholders; actuals depend on plan complexity and data quality.

AI agents status and pipeline agents view
Agents: stage ownership and operational visibility
Knowledge base of plan documents for RAG
Knowledge base: source documents that ground agent reasoning

Results

  • A coherent ops shell for a greenfield AI claims platform.
  • Reusable trust patterns: sources, review queues, no silent audit.
  • Design and eng shipping in parallel via mock contracts and staged agents.

Why this still matters

In regulated claims work, people need to see where an answer came from and when a human has to step in. I still design agent products around visible sources, review queues, and no silent auto-deny—trust is the product, not the model demo.

Stack

Vue 3 · Quasar 2 · Pinia · Vite · Express mock API · AWS Step Functions · Lambda · Bedrock (Nova Pro) · DynamoDB · S3 · API Gateway

← All case studies