Payment Integrity Radar
Finds providers whose billing stands out from specialty peers, using statistics, not a language model. Claude then writes a short, neutral brief so an analyst can start from the evidence. It explains the lead. It never decides.
Too many outliers, not enough analyst hours
Special investigations teams spend much of their time assembling evidence before they can tell whether a lead is worth opening. False leads are costly in their own right: they burn analyst time and damage provider relationships. A language model is the wrong tool for detection, because it can't be audited and shouldn't be making claims about a clinician. It is a good tool for explaining numbers that were already computed.
Statistics detect, Claude explains, code checks
| Step | Who does it | Why |
|---|---|---|
| 1. Peer comparison | Code | Robust z-scores (median and MAD) within each specialty, so extreme outliers can't hide themselves by inflating the spread. |
| 2. Risk adjustment | Code | The 99215 share is judged against a Theil-Sen line on patient risk. Sicker panels are expected to have more high-level visits. |
| 3. Scoring and tiers | Code | Flag at z of 3.5 or more, plus a hard rule for more than 16 billed hours in a day. The tier sets the action and record sample size. |
| 4. Lead brief | Claude Opus 5.5 | Sees only a list of computed facts, all aggregates. Writes the pattern, legitimate explanations to rule out, and next steps. |
| 5. Brief checks | Code | Every figure must appear in the facts. Words implying wrongdoing hold the brief. Citations must resolve and include a flagged pattern. |
- Why a held brief, not a blocked lead
- The lead stands on the statistics. A failed check only sends the wording to an analyst to edit.
- Language rules
- Briefs describe billing patterns, not conduct, and never recommend recoupment or referrals. Those decisions need a records review.
- Privacy
- The model receives provider-level aggregates only, with no member data, so the PHI exposure is minimal by design.
- Known limit
- The number check confirms a figure exists in the facts, not that it's attached to the right measure. Analysts still read the brief.
Measured against injected patterns
Screen of 120 synthetic providers. Briefs from a live run on claude-opus-5-5, 2026-11-07.
| Metric | Result | Definition |
|---|---|---|
| Screen precision | 100% | Leads that are injected patterns |
| Screen recall | 100% | Injected patterns the screen found, each on the injected feature |
| Decoys cleared | 100% | Raw outliers explained by patient risk that did not become leads |
| Briefs passing checks | 100% | Briefs with every figure sourced, neutral language and valid citations |
| Briefs citing the right pattern | 100% | Brief cites the fact for the injected pattern |
The number check earned its place during development. On the first live run it held 5 of 6 briefs. One had invented "60 to 75 minute sessions" as an example, and others mentioned figures or codes that weren't in the facts. The fix was a tighter prompt, not a looser check.
These patterns were injected into synthetic data by a generator I wrote, so the screen scores are a sanity check, not evidence of real-world performance. Real precision comes from closed investigation outcomes.
What changes in a real deployment
Detection
- Run on the plan's claims warehouse, by specialty and region, with billing and rendering NPIs separated
- Train isolation forest or XGBoost models on closed SIU cases alongside these explainable rules
- Add sequence and network features, such as shared patients and referral loops
Governance
- Fair-treatment review of false-positive rates across specialties, regions and practice types
- Analyst feedback on each lead, feeding precision tracking and threshold tuning
- Case-management integration, with an audit trail from statistic to decision
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)
- pi-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