Engineering a Defensible Suspect-Condition Pipeline (Identify Validate Capture)

Suspect-condition workflows are deceptively simple to prototype and surprisingly hard to make defensible. Anyone can flag "this member might have HCC X." Building a system whose output survives a RADV audit is a different problem. This is a walkthrough of the three stages and the engineering decisions that matter at each.

Stage 1: Identify

Identification is pattern detection over a member's clinical record — labs, medications, prior diagnoses, utilization. Model it as a set of rules or features that emit candidate HCCs:

def identify_suspects(member):
    suspects = []
    if member["labs"].get("a1c", 0) >= 9.0 and "insulin" in member["meds"]:
        suspects.append({"hcc": "HCC38", "trigger": "a1c>=9 + insulin"})
    if member.get("egfr") and member["egfr"] < 30:
        suspects.append({"hcc": "HCC326", "trigger": "egfr<30"})
    return suspects

The temptation is to maximize recall here — flag everything. Resist it. Every unvalidated suspect you generate is downstream work and downstream risk.

Stage 2: Validate (the stage that actually matters)

Validation attaches evidence to each suspect and scores its defensibility. This is the difference between a documentation opportunity and an audit liability.

def validate(suspect, member):
    evidence = collect_evidence(suspect["hcc"], member)  # labs, rx, prior dx
    suspect["evidence"] = evidence
    suspect["confidence"] = score_evidence(evidence)
    suspect["defensible"] = suspect["confidence"] >= 0.7
    return suspect

Key design rule: a suspect with an empty evidence array should never reach a coder. Make that a hard gate, not a soft warning. Under CMS-HCC V28 and current audit posture, a captured-but-unsupported diagnosis can be extrapolated across a contract into a real clawback — so "defensible by default" is the right engineering stance.

Stage 3: Capture

Capture routes validated suspects to the right human with the evidence inline, so the clinician or coder can confirm and document efficiently:

{ "member_id": "SYNTH-50921",
  "hcc": "HCC38",
  "confidence": 0.86,
  "evidence": ["a1c:9.4", "rx:insulin_glargine", "prior_dx:E11.65"],
  "action": "confirm_and_document" }

Track two metrics relentlessly: validated-suspect capture rate and audit-fail rate of captured codes. They tell you whether the pipeline produces durable revenue or just volume.

Don't reinvent the model layer

The mapping from clinical signals to HCCs — and the V28 weighting behind it — is version-sensitive and audit-relevant. Grounding the pipeline on a maintained engine for suspect conditions risk adjustment saves you from owning a copy of the model tables that drifts out of date.

The non-code framing of the same workflow is in Suspect Conditions: Identify, Validate, Capture.

VBC Risk Analytics. Educational only — not coding, billing, or clinical advice; verify against the current CMS Rate Announcement. Synthetic data only.