Risk Adjustment and HCC Coding Software: Why Chart Review Falls Apart the Moment an Auditor Picks the Sample

The number your plan gets paid on is assembled by hand and audited backwards

A VP of Risk Adjustment is looking at three files on a Thursday. One is a retrieval vendor's status report saying 41,000 charts were requested and 28,000 received, with the gap concentrated in independent practices that still fax. One is a coder productivity report showing conditions added by chart. One is an MAO-004 response from CMS showing which diagnoses were actually accepted from encounter data. The three files do not reconcile, and the reason they do not reconcile is that each was produced by a different system with a different key. Somewhere in the difference is revenue the plan earned and did not collect, and somewhere else in it is revenue the plan collected and cannot defend.

That is the operating condition in most risk adjustment shops, including sophisticated ones. It persists because the work spans four distinct problems that vendors have historically sold separately: getting the chart, reading the chart, submitting the diagnosis, and proving the diagnosis two years later. Each vendor is competent at their piece. The seams between them are where the money and the exposure both sit, and the seams are owned by your team and a spreadsheet.

The stakes changed when CMS finalised its RADV audit methodology with extrapolation, applied from payment year 2018 forward. Before that, a failed audit meant repaying the sampled contracts. With extrapolation, a sample becomes a payment year. That single change turned risk adjustment from a revenue optimisation function into a documentation defensibility function, and most tooling in the market was designed for the former.

Retrieval is the bottleneck, and no product solves your specific provider mix

Every additional percentage point of chart retrieval is directly convertible to accurate revenue, and retrieval rates are set by your provider mix, not by your vendor's capability. A plan whose membership sits with three large health systems on Epic can pull most of what it needs through direct connections. A plan with a long tail of independent practices, federally qualified health centres and behavioural providers is dealing with fax, portal downloads, on-site retrieval, and offices that treat a records request as an imposition.

Inovalon, Cotiviti and Reveleer all run retrieval at scale and they are genuinely good at the industrial parts: outreach cadence, on-site scheduling, image intake. Where a plan gets stuck is that retrieval status lives in the vendor's system with the vendor's identifiers, so your own view of which member and which date of service is still missing requires an export and a join. And the strategy question, which charts are worth chasing at all, gets answered with the vendor's generic suspecting rather than your own knowledge of which providers document well.

What a custom build does: treat retrieval as an orchestration layer over multiple sources rather than a single vendor relationship. Direct EHR connections where you have them, using FHIR bulk data or targeted queries against the systems that support it, health information exchange participation where your state has a usable one, vendor retrieval for the tail, and a structured record of every attempt against every chart. Chase priority is computed from expected yield, which is a function of the member's suspected conditions, the provider's historical documentation quality with you, and the cost of that retrieval channel. That last input is the one no vendor has, because it is your history with your providers.

The model changes underneath you, and last year's logic quietly becomes wrong

The transition from CMS-HCC version 24 to version 28 phased in across payment years and changed which conditions map to a payment HCC, how coefficients behave, and therefore which suspects are worth chasing at all. Plans that hardcoded HCC logic discovered that their suspecting, their coder guidance and their financial forecasting were all built on a mapping that had moved. Commercial ACA business runs a different model entirely through the EDGE server, and Medicaid lines run state-specific arrangements. A plan with three lines of business is running three risk models with three calendars.

What a custom build must include: model version as first-class data. Every diagnosis, every suspect, every projected revenue figure carries the model version it was computed under, and the system holds multiple versions simultaneously because during a phase-in year you genuinely need both. Coder guidance and query templates are versioned alongside, because documentation requirements that satisfy one model year are not automatically sufficient for the next. When CMS publishes a new mapping, the change is a data load with a validation run against last year's population, not a development project. Any system where a model update requires engineering will be late every single year.

Coder workflow is where accuracy is actually made, and it is nobody's product priority

Natural language processing over a chart is now table stakes and it works reasonably well at surfacing candidate conditions with a supporting passage. What determines whether your programme is accurate or exposed is what the coder does next, and that is a workflow problem.

The specific things that matter: the coder sees the extracted passage and the surrounding page image at once, so they are validating in context rather than trusting a snippet. MEAT criteria are captured explicitly as the reason a condition was accepted, not implied by the act of accepting it. Deletes are as prominent as adds, because a review programme that only ever adds conditions is the pattern federal enforcement has repeatedly focused on, and a plan that cannot show it removes unsupported diagnoses with the same diligence has a problem that no amount of coding accuracy fixes. Coder decisions carry a confidence and a reason code, and second-level review is triggered by rules you set rather than by a fixed percentage.

Vendor platforms have coder workspaces, and they are adequate. The reason plans end up building is that their own coding policy is more specific than the vendor's configuration allows, that they want their internal coders and their outsourced partners working in the same tool with different permissions and audit trails, and that they want the abstraction record to be theirs rather than an export they receive. When a chart is reviewed, the artefact that matters legally is the record of who decided what, on what evidence, under what guidance version. That artefact should live in your system.

Submission and reconciliation is the part everyone skips and then rebuilds in Excel

A condition found by a coder is worth nothing until it has been submitted, accepted and reflected in payment. That path runs through encounter data submission, response files, and a reconciliation that most plans do quarterly in a spreadsheet because their coding platform ends at the abstraction and their EDI platform starts at the 837.

Edifecs is strong on the encounter pipeline itself and if your problem is EDI plumbing, that is a reasonable place to be. The gap is the round trip. You need to know, for a specific member and date of service, that a diagnosis your coder added was submitted, was accepted or rejected with a reason, and appears in the risk score CMS calculated. When it does not, you need to know whether it failed validation, was filtered by your own submission logic, or was never sent. Plans that cannot answer that question at the diagnosis level are leaking revenue in a way that is invisible until a year-end reconciliation shows a variance nobody can decompose.

What a custom build does: carry one identifier from chart to abstraction to submission to response. Every diagnosis has a lineage that survives the whole journey, so reconciliation is a query rather than a project. Rejections are worked as a queue with reason codes, not summarised as a rate. Deletes flow through the same pipeline with the same tracking, because an unsubmitted delete is an exposure you have already documented and failed to act on, which is worse than never finding it.

Audit defence is an evidence packaging problem, not a coding problem

When a RADV sample lands, the task is to produce, for each sampled member and HCC, the medical record page that supports it, signed and dated by a valid provider, from a valid encounter type, within the correct service window. If your charts sit in a retrieval vendor's repository, your abstractions in a coding platform, your submissions in an EDI system and your provider validation in a credentialing database, assembling that package is weeks of work per audit and the assembly itself introduces errors.

What a custom build does: the evidence package is generated, not assembled. Every accepted diagnosis already points at the specific page image, the passage, the signature block, the provider's validated credential at the date of service and the encounter type. A one-best-record selection can be prepared in advance for high-value HCCs rather than under deadline. The system can run a self-audit on any sample you choose, which is the practice that separates plans that survive RADV from plans that discover their problems during it. Sampling your own population quarterly with the same rules the auditor uses is cheap and it tells you your real error rate rather than your coder's accuracy rate, which are different numbers.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this category prices as follows. A first release covering retrieval orchestration across your sources, a coder abstraction workspace with two-way review and explicit documentation criteria capture, model-versioned HCC mapping, and diagnosis-level submission reconciliation runs $90,000 to $190,000 over 14 to 20 weeks. A full platform adding prospective suspecting and provider-facing gap workflows, in-home and annual wellness visit coordination, multi-line support across Medicare Advantage, ACA and Medicaid models, and RADV evidence packaging with self-audit runs $250,000 to $600,000 phased over 8 to 14 months.

Cost drivers specific to risk adjustment: the number of distinct EHR and health information exchange connections, since each one has its own authentication, data quality and legal agreement. Multi-line business, because each risk model is effectively a separate calculation engine with its own calendar and submission path. Whether you employ coders, outsource them, or both, since a mixed model needs separate permission and audit structures. And the volume of historical abstraction data you want migrated, which matters more than plans expect because your own history is the best input to suspecting.

What holds cost down: starting with one line of business, your top providers by membership, and the reconciliation problem. Reconciliation is the fastest payback in the category because it usually surfaces submitted-and-rejected revenue nobody was working.

Build versus buy

Buy if you are under roughly 20,000 risk-adjusted lives or you are a provider group whose risk adjustment work is a few thousand charts a year. Reveleer or a comparable retrieval and abstraction platform is proportionate, and your money is better spent on certified coders and on getting your clinicians to document properly at the point of care.

Keep buying retrieval even if you build. Physical and on-site chart retrieval is a logistics business with field staff and provider relationships, and there is no advantage in recreating it. What you build is the layer that owns your data: the orchestration, the coder record, the model versioning, the reconciliation and the evidence.

Build when you can answer yes to two of these. Your provider mix is fragmented enough that retrieval strategy materially affects your revenue and no vendor's generic prioritisation reflects it. You run more than one line of business and are maintaining parallel processes for each. You cannot currently trace a single diagnosis from chart to payment. Or you have been through a RADV or an internal audit and discovered that assembling evidence took weeks. That last one is the honest trigger for most plans that come to us.

How to choose a developer for risk adjustment software

Ask how they would model a diagnosis so it can be traced from the chart page to the CMS response. If the answer does not describe a single lineage identifier surviving abstraction, submission and response reconciliation, they have built a coding tool and you will be back in a spreadsheet at year end.

Ask how a model version change is handled. It should be a data load with a validation run, never a code change, and the system should hold two model versions at once during a phase-in year.

Ask how deletes are treated in the workflow. If deletes are a secondary feature or an exception path, walk away. A review process that structurally favours adds is the exposure, and your system should make the two paths symmetric and equally measured.

Ask what they have integrated on the clinical side, specifically: which EHRs, whether through FHIR bulk data or another route, and how they handled a provider who could only supply PDFs. Ask about their approach to protected health information at rest and in transit, minimum necessary access for coders, and audit logging that will satisfy your own compliance team before it satisfies anyone else. And settle ownership before kickoff: you should own the repository, the cloud environment and every byte of abstraction history, in writing. At Digital Heroes the client owns all of it from the first commit, which for a data asset that is also your audit defence is the only sane arrangement.