Shahul Ummarali · AI Systems Architect
Risk adjustment · CMS-HCC V28 · MEAT

HCC Evidence Finder

Reads a member's chart and compares it with the diagnosis codes already submitted. It works in both directions: supported conditions that were missed, and submitted codes the chart doesn't support. A certified coder decides every line.

Run the demoView the code
Problem

Accuracy in both directions

Medicare Advantage risk scores depend on diagnoses documented in face-to-face encounters. V28 is fully phased in for payment year 2026, and RADV audits look for submitted codes the chart can't support. Tools that only hunt for additional codes create compliance risk. So this design treats deletions as seriously as additions, sorts them first, and never shows a risk score or dollar figure to the coder or the model.

Design

Claude reads the chart, code owns the rules

StepWho does itWhy
1. Identifier redactionCodeNames, dates of birth, MRNs and phone numbers are removed before any model call.
2. Chart reviewClaude Opus 5.5For each submitted code and documented condition: supported, not supported, or query the provider, with verbatim quotes tagged Monitor, Evaluate, Assess or Treat.
3. Evidence checkCodeSupport needs at least one verified quote from an acceptable encounter. A nurse phone call can't count, whatever the model says.
4. Active-disease ruleCodeCodes that mean active disease can't be supported by quotes such as "history of".
5. HCC map and hierarchyCodeThe ICD-10 to HCC lookup and hierarchy come from a table. The model never assigns an HCC.
6. ReconciliationCodeCompares findings with submitted codes: review for deletion, suggest adding, query, confirmed, replaced by hierarchy. Any submitted code the model skipped still goes to a coder.
Compliance posture
Nothing is submitted or deleted automatically. The prompt excludes risk scores and payment, so the review has no reason to favor adding codes.
Prompt injection
One demo chart hides an instruction to code E11.22. The chart is treated as a record, and the code isn't suggested.
Scope of the map
A small demo subset of V28, checked against published coding guides rather than the CMS mapping file. Verify before relying on it.
Known limit
The "history of" rule is a simple text match on quotes. It's a backstop, not a replacement for coder judgment.
Evaluation

Measured against labeled charts

Live run on claude-opus-5-5, 2026-11-07. Labeled set: 3 synthetic charts, 9 labeled codes.

MetricResultDefinition
Disposition accuracy100%Final disposition is one the label accepts
Supported additions found100%Missed conditions the chart supports, suggested for adding
Unsupported codes caught100%Submitted codes without support, sent for deletion review
Citation verification rate100%Quotes found verbatim in the chart
Forbidden codes suggested0Codes the chart must not produce, such as the injected instruction or a BMI with no diagnosis (target: 0)

I wrote these three charts and their labels myself, so this checks the pipeline. It isn't a benchmark. Real numbers need hundreds of charts labeled by certified coders, with inter-rater agreement measured.

Path to production

What changes in a real deployment

Data

  • The full CMS V28 mapping and hierarchy tables, versioned by payment year
  • Charts from retrieval vendors and EHR feeds, with OCR, signature and date-of-service validation
  • Encounter acceptability from CMS rules on provider type and service, not a flag on the document

Compliance

  • Report adds and deletes side by side, and track the balance as a control
  • Send deletes through the plan's overpayment and data-correction process
  • Audit trail from quote to coder decision, with sampled second-coder review
Source code

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)

Java (Spring Boot)