"AI captures the HCC" is easy to say and hard to verify, so here is the actual mechanic. When an AI agent closes a Hierarchical Condition Category (HCC) gap, it surfaces the suspected condition from the member record, validates that the documentation is RADV-defensible, applies V28 trumping logic so only the correct HCC is captured, routes the opportunity to a coder or a provider at the point of care, and tracks the resulting claim through the submission lifecycle until it lands. At our flagship physician-led IPA in New York, that sequence cut risk adjustment coordination from about 30 minutes to 3 minutes per member and let the same team cover 2 to 3 times more members. On that one contract, the platform surfaced 25,000-plus HCC opportunities with the supporting documentation already attached.

That last detail is the whole point. Analytics tools flag the suspect. Pelica attaches the documentation and closes the loop. Below is the anatomy of a single HCC gap, from the moment a suspect appears to the moment the capture clears CMS reconciliation, using a chronic condition recapture as the worked example. The companion to this piece is what an AI agent does when it closes a care gap; this is the risk adjustment mirror of it.

Step 1: Surface the suspected HCC

The agent starts by comparing the member's full claims history against the chart in one canonical record. CMS-HCC risk adjustment is prospective and the slate resets every year, so a chronic condition coded last year does not carry forward. If a member was coded for chronic kidney disease or diabetes with complications in a prior year and there is no supporting diagnosis on the books this year, that is a suspected HCC: a condition the history supports but that has not been recaptured.

This is where an analytics dashboard stops. It produces a suspect list and hands it to a team to chase. The agent goes further: it reads the underlying chart, pulls progress notes, labs, and medication signals, and assembles the evidence in the same record where the suspect was surfaced. It is V28-aware, so it knows which conditions still map to an HCC under the current model and which were dropped, and it does not waste a coder's time on suspects that no longer count.

Step 2: Validate the documentation is RADV-defensible

A suspect is not a capture. Before anything moves forward, the agent checks whether the documentation actually supports the code under the MEAT standard: is the condition being Monitored, Evaluated, Assessed, or Treated in the record? A diagnosis listed on a problem list with no supporting clinical activity does not meet MEAT, and submitting it invites a Risk Adjustment Data Validation (RADV) takeback.

When the documentation does support the HCC, the agent attaches the specific evidence: the chart page, the note, the lab result, with a clear chain of custody back to the source. That attachment is what makes the capture defensible if CMS pulls the chart in a RADV audit. We cover how to build this end to end in the RADV-defensible HCC guide. The contrast with an analytics-only tool is sharp here: a suspect with no evidence behind it is a liability, not a capture.

Step 3: Apply V28 trumping logic

Risk adjustment is not additive. The CMS-HCC model uses hierarchies, and within a hierarchy the most severe condition trumps the less severe ones: only the highest counts toward the member's RAF. Under CMS-HCC V28, the hierarchies and the diagnosis-to-HCC mappings changed, several conditions were dropped, and coefficients shifted. Applying old logic over-codes some conditions and misses the correct one on others.

The agent applies the V28 hierarchy as it validates each suspect, so it captures the HCC that actually counts and suppresses the ones that are trumped or no longer map. This is the difference between lifting a RAF score accurately and inflating it with codes that will not survive an audit. The goal is the correct capture, never the maximum capture. For the team-level playbook on this, see how to improve your RAF score under V28.

Step 4: Route to the right human or workflow

The agent does not submit codes on its own. Once a suspect is validated and the correct HCC is identified, it routes the opportunity to where a human can confirm it, and the path depends on the workflow:

  • Coder workspace. For retrospective review, the opportunity lands in a coder's queue with the suspected HCC, the MEAT-validated evidence, and the chart page side by side. The coder confirms or rejects in seconds instead of hunting across systems for the documentation.
  • Point of care. For prospective capture, the agent surfaces the suspect to the provider inside the EMR through a SMART-on-FHIR overlay, so the condition can be addressed and documented during the visit, while the patient is in the room.

A human always makes the call on whether the code goes in. The agent never auto-submits an unsupported code. What it removes is the lookup, the chart-chase, and the documentation pull, which is most of the 30 minutes that turns into 3.

Step 5: Track the claim through the submission lifecycle

Capture is not closure. A confirmed HCC still has to survive submission, and most of the value leaks here when teams stop at the coder's desk. The agent tracks each claim through the cycle and works the rejects:

  1. 277CA. The agent monitors the 277CA acknowledgment for accept or reject status on each submitted claim, rather than assuming a submission landed.
  2. MAO-004. It reconciles the MAO-004 report to confirm which diagnoses CMS actually accepted for risk adjustment, and flags the deletes and rejects.
  3. Rework. When a diagnosis is rejected, the agent surfaces it for rework with the reason attached, so a fixable reject does not silently fall out of the RAF.
  4. MMR and MOR. It ties the captured conditions back to the Monthly Membership Report and the Model Output Report, so the team can confirm the HCC is reflected in the member's risk score and the payment that follows.

Tracking the full 277CA to MOR lifecycle is what separates a capture that counts from one that was filed and forgotten. An analytics tool that ends at the suspect list has no visibility into whether CMS accepted the diagnosis at all.

30 to 3 min
Risk adjustment coordination per member at our flagship physician-led IPA in New York
2 to 3x
Members covered by the same team, no new headcount
25,000+
HCC opportunities surfaced with documentation attached on one contract

Why every step writes back to the record

Each step above writes to the canonical record: which suspect was surfaced and why, what evidence was attached, what the MEAT validation found, which V28 hierarchy applied, who confirmed the code, and how the claim moved through 277CA and MAO-004. This is not a nicety. It is the chain of custody that makes the capture RADV-defensible, and it is what lets the next coder or the next agent pick up current state instead of a stale snapshot. Under SOC 2 Type II and HIPAA, with full audit trails, the record of every action is the product, not a byproduct.

Analytics flags the suspect; execution closes the loop

The recurring contrast in this walkthrough is the one that matters in risk adjustment. A suspecting engine, a retrospective chart-review vendor, and a point-of-care prompt all do a version of the first step well: they tell you a condition might be missing. The open question is who does steps two through five. Who validates the documentation, applies the correct V28 logic, puts the evidence in front of a coder or a provider, and follows the claim until CMS accepts it.

That is the work that consumes a risk adjustment team, and it is the work an execution agent is built to take off their desk. When the work is done end to end, the same eight-person team covers two to three times the panel, and the RAF reflects the members' real burden of illness, defensibly.

The measure of an HCC agent is simple: did it just hand you a suspect, or did it attach the documentation, apply the right hierarchy, and follow the claim until CMS paid on it?

Sources and further reading