Finding More Codes Is Not the Same as Getting Them Right

US health insurers get paid more for covering sicker patients. That is deliberate and sensible: without it, insurers would quietly avoid anyone expensive.

How sick a patient is gets established through diagnosis codes pulled from clinical notes. So an entire software industry grew up to find codes in those notes, because every code found meant revenue.

Look closely at what that software was asked to do. It was optimized to find codes. Finding codes was treated as standing in for accuracy. Those are not the same objective, and the distance between them is where the money and the liability both sit.

Every business has done a version of this. You want to improve something real and hard to measure, so you pick a number you can count and manage that instead. Call centres measured handle time and got shorter calls that solved nothing. Sales measured activity and got more meetings with people who were never going to buy.

The metric is never wrong exactly. It just is not the thing you wanted.

In risk adjustment the stand-in was volume. Codes found per chart, additional conditions identified, revenue captured per review. Vendors were selected on those numbers and paid against them. Nobody was measured on codes correctly removed, so nobody built for it.

A federal audit reviewed a sample of records where insurers had billed for a stroke. The records failed documentation review, and the reason is the interesting part.

Most of those patients had genuinely had a stroke. It was documented, real, in their medical history. The billing described it as happening currently rather than years earlier, and a current stroke and an old one are worth different amounts of money.

Nobody invented a patient or a diagnosis. Software did exactly what it had been optimised to do, at scale, for years. It found codes. It was never asked whether the codes it found were still true.

Here is the mechanism, and it is worth understanding because it explains why this persisted rather than being caught.

These systems predict. Given a chart, they estimate which codes probably apply and rank them by confidence. That architecture is very good at its job and structurally incapable of a different one. It cannot tell you if a code already submitted is wrong, because a probability distribution contains no value that means "remove this." It can rank a code lower. It cannot return a negative finding.

So an insurer can run its charts through review repeatedly and never surface a single deletion. Not through negligence. The tool has no output for one.

There is documented precedent for this class of failure. In 2019, researchers publishing in Science examined an algorithm that decided which patients needed extra care. It used cost as a stand-in for illness, which sounds reasonable until you notice that less had historically been spent on some patients at the same level of need. The algorithm read lower spending as lower need. The journal summarised the effect plainly: the bias cut the number of Black patients identified for extra care by more than half.

That study looked at care management, not coding, and makes no claim about coding models. The connection is that both learn from a stand-in, and that reading is mine rather than the study’s.

Strip out the healthcare and this is a procurement problem any business owner will recognise.

You buy software to solve a problem. You measure the vendor on the thing that is easy to count. The vendor optimises for what you measure, because that is what you are paying for. Two years later the number looks excellent and the underlying problem has quietly changed shape.

• What is the vendor actually optimised for, as opposed to what the pitch says it does?

• Does the system have any output that means "this is wrong," or only outputs that mean "here is more"?

• Who gets paid when it finds something, and does anyone get paid when it finds nothing?

Regulators moved first. Guidance now names failing to remove previously submitted codes, once a review shows they were unsupported, as potentially abusive conduct. The obligation runs in both directions: organisations must report unsupported entries and the resulting overpayments, under statute and regulation.

Which turned a volume metric into a liability. A program judged only on codes found is now a program with an obligation it may not be able to see.

The fix was architectural rather than a matter of tuning. A risk adjustment solution that tests a record against explicit documentation rules, instead of scoring how closely it resembles other records, can return a negative result, because a rule is able to fail. Ranking cannot fail. It can only sort. That is the question worth putting to any vendor in any industry: show me what your system produces when the answer is no.