RxHCC Recommendation Engine: Point-of-Care Risk Capture, Explained

An RxHCC recommendation engine is a clinical workflow tool that surfaces diagnosis codes a patient's record already supports — but that never made it onto a claim. It sits where the prescriber works, flags the gap, and attaches the documentation CMS requires before the code ever gets submitted.

This is the operational answer to the question every MA-PD plan eventually asks: we know the acuity exists in our members — how do we get it documented, coded, and submitted without creating audit exposure?

The problem it solves

Part D plans are paid on diagnoses, not on conditions. A member with diabetic nephropathy whose claims only ever show `E11.9` (diabetes without complications) is, from CMS's perspective, an uncomplicated diabetic. The plan receives the Direct Subsidy for uncomplicated diabetes — regardless of what the EHR says.

The gap is rarely fraud or laziness. It's structural:

• Prescribers document for care, not for risk adjustment
• Specificity (`E11.21` vs. `E11.9`) feels like coder trivia at the point of care
• Plans see the gap months later in retrospective review, when the encounter is cold

An engine moves the moment of capture to the moment of care.

How it works

1. Ingest the evidence. The tool reads what's already clinically established: problem lists, encounter notes, labs (eGFR, A1c), medications, and prior claims. Nothing is invented — the engine only works from acuity that already exists in the record.

2. Identify the delta. Current claims-coded diagnoses are compared against supported conditions. The output is a short, ranked list: which RxHCC categories are uncaptured, what each is worth in coefficient terms, and what the member's score becomes if they're documented.

3. Attach the documentation. Every suggestion carries its evidence trail — the note, the lab, the prescription that supports it. If a suggestion can't cite MEAT-compliant documentation, it isn't made. This is what separates a recommendation engine from an upcoding tool.

4. Close the loop. The prescriber accepts or dismisses. Accepted codes flow into the encounter and, critically, into the claim — because a diagnosis in the EHR that never reaches a claim pays nothing.

What a recommendation looks like

A typical member view shows current coded state versus supported state:

The dollar figure is arithmetic, not projection: coefficient × the plan's Direct Subsidy base. The compliance figure matters more — every added code traces to a specific piece of clinical evidence, RADV-ready by default.

Why it survives audits

Retrospective-only programs raise scores and hope. A point-of-care engine inverts the evidence order: documentation first, code second, claim third. When CMS extrapolates RADV findings across a contract, the question is never "were scores raised?" — it's "can you produce the record for this code?" An engine that only suggests evidence-backed codes turns that question into a formality.

The scale math

Pharmacy claims concentrate: roughly 40% of prescribers account for 80% of claims value. For a typical plan, that's 600–1,200 prescribers driving most of the RxHCC opportunity. An engine deployed to that subset — not an enterprise-wide transformation — captures the bulk of the delta. That's a focused workflow, not a multi-year program.

CuraFi works with plans to deploy exactly this: provider-aligned, evidence-first RxHCC capture at the point of care. Get access to see it on your own population.

Frequently asked questions

Is a recommendation engine the same as a coder tool?

No. Coder tools help coders translate notes into codes after the encounter. The engine works prospectively, at the point of care, before the claim exists.

Does suggesting codes create compliance risk?

Suggesting unsupported codes does. A compliant engine only surfaces codes the record already documents, and requires prescriber confirmation — the clinical judgment stays with the clinician.

How is this different from retrospective chart review?

Retrospective review finds gaps months after the encounter and submits addenda. The engine closes the gap during the encounter, when the prescriber can actually act on it — and the evidence is fresh.