DoctorAnywhere · Human-in-the-loop Design · 2025–2026

An AI fraud signal that supports human judgment

Designing how an AI fraud-risk score appears inside a live, daily-use claims-assessment tool, across two models, two claim types, and two assessor teams. The signal had to be always visible but never dominant.

Role
Product Designer (sole designer, both tracks)
Timeline
2025–2026
Pattern
AI decision-support · human-in-the-loop
Platform
Ops + Provider portals
Overview

Fraud at a scale no human can review

An estimated 2–5% of all GP panel clinic and non-panel claims fall under FWA: fraud, waste, and abuse. Receipt forgery, drug-diagnosis mismatches, and duplicate claims inflate the costs paid on insurers' behalf. Manual review can't catch this at scale: as claim volume grows from 10,000 toward a target of 100,000 claims a month, fraud slips through proportionally.

The AI team built two models. One scores panel claims for duplicate medications, mismatched diagnosis-and-medication pairs, and excessive quantities, which is clinic behaviour. The other scores non-panel claims for image alteration and frequent submission patterns, which is member behaviour. My job was to design where and how that risk signal appears to the two assessor teams who act on it.

~2.5%
Panel claims flagged · of 7,000/mo
~10.4%
Non-panel flagged · of 10,000/mo
359 → 36 → 12
Flagged → clinics contacted → claims closed
The problem

Two teams, two definitions of suspicious

Panel and non-panel claims are assessed by entirely different teams, with different criteria. Same underlying question: where does an AI risk signal belong on a dense claims-review page? But two handoffs, two stakeholder groups, and two definitions of "suspicious."

  • Panel → Provider Management team: reviews diagnosis-medication combinations, duplicate prescriptions, and excessive quantities. They act by contacting clinics to amend claims.
  • Non-panel → Claims Assessors: reviews receipt authenticity (timestamps, software-edit metadata, camera info) and submission frequency (more than once a day, more than three times a week, more than four times a month). They act by contacting members to resubmit documents.

Foundation work: before Agent Nox's UI existed, I had spent the prior year building the drug-to-diagnosis tagging infrastructure in the Provider Admin Portal, covering medication-to-diagnosis tagging, quantity thresholds, and tapering-dose exceptions. That structured data is what the panel model now scores against.

Always visible, never dominant

Always visible, never dominant. Get it wrong in either direction and the feature is either ignorable or coercive.

Always visible. If assessors must scroll to find the score, they form a judgment first and check the AI afterward, which defeats a decision-support tool.

Never dominant. Assessors are professionally accountable for their assessments. Visually overweighting the AI score signals that the machine decided: exactly wrong.

Core flows

The shipped experience.

[ Export: shipped sticky bar + expanded FWA section, redact PII ]

One sticky bar, no new patterns

The FWA tag lives in the bar assessors already use for claim status. Zero new patterns to learn, and the existing workflow stays untouched.

Exploration

Five directions

AI-pattern libraries had nothing for an always-on signal inside a dense professional review workflow. So I reframed the search. Instead of looking for AI UI, I looked for interface patterns with the same behaviour: persistently visible while scrolling dense content, supporting action without demanding it.

  • Inline section: visible only when scrolled to. Assessors could judge before seeing the AI. Rejected.
  • Floating chat-style widget: always present, but detached from the claim. Early feedback: "feels like an ad." Rejected.
  • Side drawer (Notion/Docs-comment style): good depth, but covered the claim when open. Assessors were reluctant to trigger it. Rejected.
  • Slide-up panel (iOS Maps style): integrated, unobtrusive, expandable on demand. My preferred direction, killed by the sprint timeline.
  • Corner widget variant: same detachment problem as the floating widget. Rejected.
[ Export: 5-direction exploration board ]
Design decisions

Working within a tool they already trust

Rather than introduce a new pattern into a tool assessors use daily, I worked within what existed: a sticky bottom bar already used for claim status, with anchor navigation.

  • FWA tag added directly into the sticky bar, so it stays visible while scrolling.
  • Full FWA assessment section placed immediately before the "Change Status" action, sitting in the assessor's natural decision path.
  • Anchor behaviour redirected: clicking the FWA tag jumps straight to the assessment detail.

The honest tension. My preferred direction, the slide-up panel, didn't ship. Shipping into a live daily-use tool means the right answer isn't always the viable one on the current timeline. I designed the strongest version of what could ship now instead of holding the release for an ideal I couldn't build yet.

Impact

Designing the signal to scale

Risk currently displays as HIGH only, when any check flags: deliberately binary. As model accuracy improves, the plan expands to High and Medium tagging, so the interface scales with the model's confidence rather than against it. Low-risk claims get no tag at all. A green "low risk" badge invites complacency on a professional judgment task; absence of a flag is the correct design for "nothing anomalous."

The work didn't stop at the UI. I also structured how daily audit feedback, confirmed fraud, false positives, and behaviours the model hadn't seen, flows back into retraining, so the model keeps improving after launch. Structuring that loop was a design decision too.

Reflection

What this taught me

  • Designing AI for internal professional tools is about restraint, not spectacle. Support the workflow, don't announce the AI.
  • When one system serves two user groups, consistency comes from shared patterns, not identical screens.
  • Design doesn't end at launch. Structuring the model's feedback loop is a design decision.
  • Build the interface to scale with the model's confidence over time, not frozen at launch-day accuracy.