Most engineering teams building risk adjustment tooling treat clinical documentation as a black box: notes go in, codes come out, RAF scores get calculated. But if your HCC (Hierarchical Condition Category) capture rate is low, the problem usually isn't your scoring engine — it's upstream, in the documentation itself. This is where Clinical Documentation Improvement (CDI) becomes a data-engineering concern, not just a clinical one.
The capture gap, in concrete terms
A member can have a chronic condition that absolutely belongs in the CMS-HCC V28 model, but if the provider's note for the year doesn't document that the condition was evaluated and addressed, it never becomes a codable diagnosis, and it never contributes to the RAF (Risk Adjustment Factor) score. The condition is real. The data is missing. Multiply that across a panel and you have a systematic understatement of risk.
CDI exists to close that gap at the source. From a systems perspective, that means surfacing the right prompt to the right clinician at the right moment — which is squarely an engineering problem.
Where developers come in
A modern CDI workflow is a pipeline:
clinical note (NLP) -> candidate conditions
-> cross-check vs claims history + problem list
-> documentation gap? -> provider query/prompt
-> resolved diagnosis -> HCC mapping (V28) -> RAF
Each stage is testable. A few things to get right:
- Evidence linkage. Every suggested condition should carry a pointer to the evidence (the lab value, prior claim, or note span) that triggered it. A prompt with no evidence is noise, and clinicians tune out noise fast.
- Suppress the already-documented. If the condition is already captured for the year, don't prompt. Deduping against the current-year encounter set is essential.
- Hierarchy awareness. In the HCC model, hierarchies mean a more severe condition supersedes a less severe one in the same family. Your suggestion logic should respect that so you're not prompting for a code that wouldn't add value.
Synthetic example
Consider a synthetic member with a documented history of CKD and a recent eGFR of 28. If the current-year note mentions kidney disease only in passing without staging, the CDI engine flags a documentation gap and suggests a clarification. The clinician confirms the stage, the diagnosis is documented, and the appropriate HCC is captured. No new clinical reality was invented — the documentation simply caught up to it. (All values here are synthetic; no PHI.)
The compliance guardrail
CDI is not a code-maximization tool. Every prompt has to be clinically defensible and every captured diagnosis must reflect a condition actually evaluated and addressed at the visit. Build your prompts to be neutral and evidence-based, not leading, so the resulting documentation holds up under a RADV (Risk Adjustment Data Validation) audit. If your engine nudges clinicians toward unsupported codes, you're building audit liability, not value.
Measuring whether it works
Track the boring metrics: query response rate, query agreement rate, recapture rate of chronic conditions year over year, and the delta between suspected and confirmed conditions. If your prompts have a low agreement rate, they're probably low-quality or poorly timed — fix the evidence linkage before you add more rules.
For the clinical playbook side of this — how CDI specialists actually structure queries and partner with providers — see the resources maintained by VBC Risk Analytics. The full featured article walks through the operating model end to end: CDI: The Missing Link to Improve HCC Risk Capture.
Done right, CDI is the difference between a scoring engine that's technically correct and a risk picture that's actually complete.
VBC Risk Analytics. Educational only — not coding, billing, or clinical advice; verify against the current CMS Rate Announcement. Synthetic data only.
Top comments (0)