Every Generation of AI Solved a Different Problem
Each wave of artificial intelligence arrived to answer a question the previous wave could not, a succession of researchers describe as waves defined by what the last one could not do.² Rules-based software followed instructions but could not learn. Machine learning learned patterns but could not read a note. Language models read the note but cannot tell you whether what they found will survive a records request.
That last gap is where most risk adjustment programs are sitting right now.
Ask your coding system why a diagnosis was submitted, and you will usually get a probability. But confidence measures how closely a chart resembles other charts the model has seen. It says nothing about what the provider documented, at which encounter, or whether the documentation meets the standard a reviewer would apply.
There is a related pattern most risk adjustment leaders have noticed without naming it. The system only ever hands back more codes. It surfaces conditions that may have been missed and never once suggests that a condition already reported is not adequately supported. That is not an oversight in the product. It follows from how the system was built.
Key Takeaways
- A predictive system can identify a probable diagnosis. It cannot state which documentation requirement a diagnosis failed.
- Flagging an unsupported diagnosis means holding a rule and testing evidence against it, which is a different kind of system than one trained to predict.
- Regulators treat unsupported diagnoses as a compliance risk area, not only missed diagnoses as a revenue issue.4
- Defensible risk adjustment runs in two directions: finding supported conditions that were missed and surfacing reported conditions the record does not support.
- Whether a system can do both depends on its architecture, making it a compliance question.
From Machine Learning to NLP: What Each One Solved
Before machine learning, coding software did what it was told. A developer wrote a rule, the software applied it, and anything the rule did not anticipate went unhandled.
Machine learning changed the arrangement. Instead of instructions, the model was given examples: thousands of charts alongside their assigned codes. From those, it learned statistical relationships between what appeared in a record and what was ultimately coded, enabling it to direct coders toward records worth a closer look. That shift, from encoded rules to patterns learned from data, is the second wave.²
What machine learning could not do was read. It worked on structured fields, claims history, and problem lists. The evidence that determines whether a diagnosis is supported rarely lives there. CMS requires every submitted diagnosis to be documented in the medical record as the result of a face-to-face encounter, which places the proof in the narrative.5
Natural language processing was built to close that gap. It could identify a condition mentioned in a progress note or a specialist letter and surface it for review, making large-scale chart review practical rather than theoretical. It is still doing useful work in most risk adjustment programs today.
But NLP was designed to find and classify language. It was never designed to think the way a coder.
Why NLP Can Find a Diagnosis But Cannot Prove One
A coder does not stop at finding a condition in a note. Was this condition assessed at this encounter?
Is there evidence of management, evaluation, assessment, or treatment? Does the provider type qualify?
Is this active, or is it a history carried forward?
These are not preferences. CMS requires submitted diagnoses to be documented as the result of a face-to-face visit, drawn from acceptable data sources, and coded according to the ICD-10-CM Official Guidelines for Coding and Reporting.5
A language model does not ask those questions because they are not the kind it was built to answer. It reports what the text resembles. Three examples make the limitation concrete.
Same chart, two answers. Run an identical record through a general-purpose language model twice, with the same prompt, and it can return different codes. One run assigns an old myocardial infarction. The next assigns personal history of other circulatory diseases. The evidence did not change. The output did, and that is not a basis a reviewer can defend six months later.
Inference presented as documentation. A chart shows a BMI of 44. The model assigns morbid obesity. But coding turns on what the provider documented, not on a value from which a condition might reasonably be inferred. The number is in the record. The diagnosis is not.
Context that changes everything. A note reads: history of breast cancer, status post bilateral mastectomy, incision site well healed, no new complaints. The assessment line says only “breast cancer.” A pattern-matching system sees a malignancy in an assessment. A coder sees a patient with no active disease and codes the history status.
This distinction is not academic. It is the error federal auditors find most often. Across three compliance audits issued in March 2026, the recurring finding from stroke and myocardial infarction through several cancers was a documented past medical history treated as an active condition.5,7
None of these are failures of accuracy in the ordinary sense. The system found something genuinely present in the text. Finding a diagnosis and proving one are different tasks, and getting better at the first does not produce the second.
This is also why the add-only pattern exists. A model trained to predict what a record probably contains can make a proposal. To state that a reported diagnosis is not supported, a system must meet a documentation requirement, test the evidence against it, and identify which part failed. Absence of adequate evidence is not a pattern to be recognized. It is a conclusion to be reasoned.
Inside Neuro-Symbolic AI: Learning Plus Reasoning
Neuro-symbolic AI is not a marketing term. It describes a recognized approach in the AI research literature, sometimes called the third wave, that combines neural learning with symbolic knowledge representation and logical reasoning rather than choosing between them.2,3
The neural layer reads. It handles the messiness of real clinical documentation: abbreviations, negation, temporal language, and the difference between a condition ruled out and one actively managed.
The symbolic layer reasons. It holds coding guidelines, hierarchies, clinical ontologies, and documentation requirements as explicit, inspectable logic.2,3 When the neural layer surfaces a candidate diagnosis, the symbolic layer tests it. Is there evidence of management, evaluation, assessment, or treatment?
Is that evidence linked to a qualifying encounter?
Does the guideline permit this code given the surrounding context?
The output is different in kind. Rather than a diagnosis with a score attached, a reviewer receives a diagnosis with the documentation that supports it, the encounter it came from, and the rule applied. In the breast cancer example above, the symbolic layer holds back the active malignancy code because the surrounding language establishes a historical context that the guideline treats as disqualifying.
Two consequences follow. The reasoning can be reconstructed months later because it was recorded as reasoning rather than inferred backward from an output. And the same rule layer that supports adding a diagnosis also supports flagging one that the record does not support. Both directions run on the same machinery.
This approach has a real cost. A predictive system improves by being shown more examples. A rule-based layer improves only when someone encodes the change, and coding guidance does not sit still. That is slower, and it carries a maintenance obligation that a purely statistical system does not. The trade-off is that the maintenance is visible: when a rule changes, it changes in one inspectable place, and every recommendation after that reflects it. Retraining a model makes it harder to pinpoint a single change that accounts for shifts in its output.
What Regulators Now Expect from a Coded Diagnosis
The technology argument would be optional if regulators cared only about missed diagnoses. They do not.
In February 2026, OIG issued Medicare Advantage Industry Segment-Specific Compliance Program Guidance, its first update to Medicare Advantage compliance guidance since 1999.4 The guidance is voluntary and creates no new obligations. What it describes is another matter. Among the conduct federal investigations have revealed, OIG lists failing to remove diagnosis codes previously submitted to CMS when a chart review shows those codes were unsupported or otherwise invalid.4 Leaving an unsupported code in place appears alongside submitting a wrong one.
Two further items in that list belong in any conversation about coding AI. OIG names prompting physicians to add risk-adjusting diagnoses that patients did not have, and explicitly includes prompts generated by artificial intelligence algorithms.4 It also notes that MA organizations must report unsupported and otherwise invalid diagnosis codes to CMS through designated systems, an obligation that sits in regulation rather than in the guidance itself.4,5
Then comes the recommendation. Among the oversight steps OIG suggests, the first is to pair the processes that surface additional diagnoses with those that ensure data accuracy.4 That is a two-way review, described by the regulator before any vendor named it.
The scale appears in OIG’s own audit work. Three compliance audits issued in March 2026 found that medical records did not support the submitted diagnosis codes for 247 of 271 sampled enrollee-years in one case5, 252 of 300 in another6, and 232 of 286 in a third7.
CMS moved in the same direction on encounter linkage. Beginning in CY 2027, diagnoses from unlinked chart review records are excluded from risk-score calculation, with an exception for beneficiaries who switch from one MA organization to another. 8
What this looks like on a chart is more instructive than the numbers. A chronic condition appears in the assessment at every visit, carried forward, with no evidence of assessment, treatment, or monitoring at any of them. It has been reported for years. Under review, it is an overturn, and the plan has to explain it. “DM2 stable” and “DM2, A1C 8.2, adjusting metformin, follow up in three months” carry the same diagnosis. Only one is defensible.
Some categories turn on a rule rather than a pattern, and this is where the two kinds of systems diverge most sharply. A condition documented as history can sometimes be coded as active where there is clear evidence of current management. Deep vein thrombosis is not one of them. In one of those March 2026 audits, reviewers found documentation of a past medical history of deep vein thrombosis that did not result in an HCC, yet an embolism code had been submitted.5 A pattern-based system has no way of knowing that this category is an exception. A rule layer does, because the exception was written down.
Add-Only vs Two-Way Review
Put the two approaches side by side, and the difference is not sophistication. It is a direction. An add-only review asks what we missed, returns a condition with an attached probability, and leaves anything already reported in place unless a coder happens to catch it. A two-way retrospective review asks whether the record supports what was reported, returns a condition with the documentation and encounter behind it, and surfaces reported diagnoses along with the requirement the documentation did not meet. When the record is pulled, one approach explains the code after the fact, and the other already has the reasoning on hand. Neither changes how many stages of human review a program runs. Every recommendation in either direction is decision support, and coders hold final authority.
Architecture Is a Compliance Decision, Not an IT Decision
Most AI evaluations in risk adjustment still center on accuracy, which is the wrong first question, because it measures agreement with a reference answer rather than the ability to explain how that answer was reached. Two questions get closer. Can you show me the reasoning behind a recommendation on a real chart, not a summary of it?
And can the system identify a reported diagnosis that the record does not support, and state which requirement it failed?
None of this is unique to healthcare. NIST’s AI Risk Management Framework, a voluntary cross-sector framework, treats transparency and accountability as characteristics of trustworthy AI and asks organizations to document how a system reaches its outputs.1 It does not prescribe an architecture for anything, let alone risk adjustment coding. It does make the question a fair one to ask.
The answers describe the architecture, and the architecture decides what the output can prove. A system built only to predict will keep producing more codes, because that is the only direction it can move. Defensible risk adjustment does not run one way. It means finding supported conditions that were genuinely missed and equally surfacing reported conditions the record does not support before someone else does. Previously reported is not the same as currently defensible.
Which brings the argument to its simplest form.
An AI that can never tell you a code should come out cannot tell you why it added one.
To see how this works in practice, read more about Neuro-Symbolic AI in risk adjustment.
Frequently Asked Questions
What is risk adjustment in coding?
Risk adjustment is how CMS adjusts payment to reflect the health status of enrolled members, using diagnosis codes from clinical encounters. See our Risk Adjustment Coding: 2026 HCC and MEAT Guide.
Why can a machine learning model add a diagnosis code but not remove one?
A predictive model estimates what a record likely contains based on patterns in its training data. Stating that a reported diagnosis is unsupported means holding a documentation requirement and testing evidence against it. That is reasoning against a rule, and prediction has no mechanism for it.
Can a confidence score prove that a diagnosis is supported?
No. A confidence score indicates how closely a record resembles the records the model was trained on. It says nothing about which provider documented the condition, at which encounter, or whether the documentation meets the requirement. A reviewer cannot present a probability as evidence.
How does a neuro-symbolic system link a diagnosis to MEAT evidence?
The neural layer identifies clinical language in the note. The symbolic layer tests it against documentation requirements, checking for evidence of management, evaluation, assessment, or treatment tied to a qualifying encounter. The recommendation carries the supporting text and the rule applied.
How can you tell whether a vendor's AI produces a real evidence trail?
Ask to see the reasoning for one recommendation on a live chart. A real evidence trail names the documentation, the encounter, and the requirement satisfied. A score with a highlighted phrase is not.
What can neuro-symbolic AI not do?
It cannot absorb a change in coding guidance the way a predictive model absorbs new training examples. When guidelines are revised or CMS recalibrates a model, the rule layer has to be updated deliberately. That maintenance is the cost of reasoning that can be inspected.
Is coding at risk from AI?
No. Both directions of review are decision support, and coders hold final authority. Human review is part of how the system is designed to work rather than a safeguard added afterward, and a recommendation that a diagnosis lacks support is exactly the judgment that belongs with a reviewer.
