AWV as Patient Enrollment Engine: Turning One Visit Into a Care-Management Pipeline

In population health research, the data-collection moment and the data-use moment are supposed to be connected, and in practice they’re often not. The Annual Wellness Visit is the clearest example I’ve seen of this gap in a Medicare billing context: the Health Risk Assessment collected during it identifies exactly which chronic-care, monitoring, and behavioral-health programs a patient likely qualifies for, and in most practices that data gets documented into the visit note and goes nowhere else.

Epic-Approved Vendor · HIPAA and SOC 2 controls built into every build · 50+ healthcare solutions shipped.

What the HRA Actually Captures

Every one of these five components maps to a specific downstream program’s eligibility criteria, which is the connection most AWV workflows never make explicit.

Mapping HRA Findings to Program Eligibility

The HRA is already asking the questions that determine program eligibility, the gap isn’t in the data collection, it’s in what happens to the answer immediately afterward.

Why Off-the-Shelf AWV Tools Stop at the Care Plan

Most AWV software, ThoroughCare and HealthViewX included, is built to generate the Personalized Prevention Plan the visit requires and document it correctly for billing. That’s the letter of what CMS asks for, and these tools do it well. What they don’t do, because it isn’t the product they’re selling, is treat the HRA’s findings as a trigger for a second workflow. A positive depression screen gets recorded in the AWV note. Whether that finding turns into a BHI enrollment conversation depends entirely on whether a human on the care team happens to notice it and follow up, not on any system logic connecting the two.

This isn’t a criticism of those tools doing their job poorly, it’s a scope observation. An AWV-specific platform is built to satisfy AWV’s own billing requirement end to end, which is a real and reasonably complex problem on its own: the HRA questionnaire, the cognitive and depression screens, the Personalized Prevention Plan generation, the advance care planning discussion, the immunization review, all correctly documented and coded.

Building that well is the product. Building the second layer, connecting each of those outputs to five other programs’ entirely separate eligibility logic and enrollment workflows, is a different product, one that has to understand CCM’s condition-count threshold, RTM’s functional-limitation criteria, and BHI’s screening-score cutoffs simultaneously, not just AWV’s own requirements. Most vendors in this space build the first layer well and treat the second as out of scope, which is a defensible product decision and also the exact reason the eligibility-routing gap persists across the industry rather than in any one vendor’s specific implementation.

What Happens When the Pipeline Doesn’t Exist

The cost isn’t abstract. A patient whose AWV flags two chronic conditions and a positive depression screen is, on paper, eligible for CCM or APCM and for BHI concurrently, a legitimate stack per this cluster’s own stacking rules. Without a routing mechanism, that patient’s AWV note documents the finding, satisfies AWV’s own billing requirement, and the CCM and BHI enrollment opportunities sit unconverted until, if ever, someone reviews the chart for an unrelated reason and notices. Across a full panel, this isn’t a handful of missed patients, it’s every patient whose eligibility depended on the AWV surfacing it rather than a separate, redundant screening process catching it later.

The revenue math compounds in a way that’s easy to underestimate from a single-patient view. A practice completing 800 AWVs a year, a realistic volume for a mid-sized primary care panel, that misses even a conservative 15% CCM-or-APCM-eligible conversion rate because the eligibility signal never left the visit note is looking at 120 patients a year who generated a real, documented eligibility finding and never became an enrolled, billing patient in a second program. That’s not a hypothetical inefficiency, it’s the direct, countable output of a workflow gap that shows up in exactly zero of the AWV’s own quality or billing metrics, because the AWV itself gets billed correctly either way. The gap is invisible to anyone measuring AWV performance in isolation, which is part of why it persists.

Building the Eligibility-Routing Logic

The routing rules themselves are a straightforward mapping exercise once the pipeline exists: each HRA finding is checked against the program-eligibility criteria, flagged for action, not silently logged. Where this needs EHR connectivity is pulling the HRA data live from wherever it’s captured and getting the flag back into a workflow the care team actually sees that day. ConnectHealth is the layer that handles that connectivity, whether the AWV is documented in Epic, Cerner, Athenahealth, or a separate wellness-visit tool, so the eligibility check runs against current visit data rather than a batch export pulled days later.