Case Study 2 — The Coder Who Knew It: A Composite

A composite built from the failure mode described in §8.1 and from documented annual-update patterns. Tier 3; the person and the practice are constructed. The mechanism is entirely ordinary.

Background

Section 8.1 made an argument that sounds like moralizing: look everything up, every time, including codes you have used four hundred times.

Every experienced coder has heard it. Most break it daily, and they break it for a defensible reason — looking up a code you are certain of feels like theater, and productivity is measured (Chapter 6 §6.9).

This case study is what the rule is actually protecting against, and it is not "you might misremember a code."

The composite

Constructed. Not a real person.

A coder with nine years in the same specialty practice is, by every available measure, excellent. Their audit accuracy is consistently high. Their productivity is the best in the department. They are the person other coders ask.

They also, for the specialty's twenty most common diagnoses, code from memory. They know these codes the way you know your own phone number, and they have been right about them for years.

In an October update, one of those twenty categories expands. The category they have used thousands of times gains an additional character position — a laterality distinction that did not previously exist. The old code, which was complete at five characters, is now a subcategory that subdivides, and the valid code is six characters.

Nothing about this is unusual. Category expansion is one of the most common kinds of annual change, and it is specifically the kind that Chapter 7 §7.3 warns produces invalid-code rejections.

Here is what happens next, and the sequence is the case study.

The first week

Claims carrying the old five-character code begin rejecting as invalid. The billing office notices within days — rejections are visible, and Chapter 6 §6.7's advice to watch the two-week rejection spike is exactly designed to catch this.

They tell the coder. The coder is surprised, checks, finds the expansion, and corrects. Total damage: about forty claims, resubmitted within the week, no revenue lost.

That is the good outcome, and it is the one this coder gets — because an expansion that invalidates the old code is a loud failure. The claim rejects. Somebody notices.

The failure that is not loud

In the same update, a different category the coder uses daily gains a new instructional note in the Tabular. Not a code change — the code is unchanged, valid, and still describes the condition. The category now carries a use additional code instruction directing that a second code be reported to identify an associated condition.

Nothing rejects. The claim is complete, the code is valid, and the missing second code is not missing from the payer's perspective — the payer has no way to know it should have been there. The claim adjudicates and pays.

The coder does not know. They did not look, because they knew the code, and they were right about the code. The instruction was three lines above it and they have not read that page in four years.

What it cost

Constructed, and deliberately modest — the point is not that the number is large.

The omitted second code was, in this practice's payer mix, mostly inconsequential for fee-for-service payment. It was not inconsequential for two other things:

• Risk adjustment. Roughly a fifth of the practice's patients were in risk-bearing arrangements, and the omitted code identified a condition that affects the risk score. Chapter 36.
• The problem list and the quality data. The practice's own reporting understated the prevalence of a condition it treats constantly.

It was found fourteen months later, during a payer's risk-adjustment chart review, which flagged documented conditions that had not been reported. The finding was not adverse — nobody alleged anything — but the practice had underreported for over a year, and correcting it retroactively was not possible for most of the period.

What it shows

First, the argument for the two-step rule is not about memory. The coder's memory was perfect. They recalled the code correctly and the code was correct. What they could not recall was an instruction that did not exist when they learned it.

This is the precise reason §8.1 states the rule as an absolute rather than as risk management. A coder who looks up only the codes they are unsure of will never look up the codes that changed, because certainty is not correlated with currency — it is correlated with how long ago you learned it, which is exactly backwards.

Second, the two failure modes have wildly different detection profiles, and organizations systematically prepare for the wrong one:

Chapter 6 §6.7's update checklist has an item for this — check whether a guideline changed, not just whether codes changed — and it is the item most often skipped, because the other items produce visible results and this one produces nothing.

Third, the coder was not negligent and the practice was not badly run. This is the part worth sitting with. The coder was the best in the department by every metric the department had. The metrics did not measure whether anyone was reading the Tabular, because no metric can.

Fourth, it was found by an outside party. Fourteen months later, by a payer's chart review, in a context where the practice was not in trouble. The next practice in this situation might be found by a different kind of review, in a different posture, and Chapter 5 §5.2 explains why the difference matters enormously.

The lesson

Certainty is a signal about how long ago you learned something, not about whether it is still true.

Three carry-forwards:

Look it up because things change, not because you might be wrong. Reframing the rule this way is the only version that survives contact with an experienced coder, because it does not insult their memory — it acknowledges that their memory is fine and the book is not the same book.

Pay attention to the failures that do not reject. A rejection is a gift: it is an error announcing itself. The errors worth fearing are the ones that pay, and the annual update produces them every year in the form of new instructions on unchanged codes.

And read the categories you use most, at least once a year. Not all of them — the ones you use daily and would never look up. That is a short list for any coder, it takes an hour after each October update, and it targets exactly the population of codes where certainty is highest and currency is lowest.

Discussion questions

1. The coder's memory was correct and their coding was wrong. Restate that as a general principle about expertise, and name one other profession where the same principle applies.

2. Design the annual routine described at the end: which categories does a coder re-read, how are they identified, and when? Be specific enough that someone could actually do it.

3. The loud failure was detected in days and cost nothing. The silent one took fourteen months and could not be fully corrected. What does that suggest about where an organization should spend its update-cycle effort — and is that where organizations actually spend it?

4. No metric the practice had would have caught this. Is there a metric that could? Try to design one, and then say honestly whether you would want to be measured by it.

5. Compare this composite to Chapter 6's Case Study 2 (the scrubber rules nobody remembered configuring). Both are about an unexamined default operating for years. What is the common structural feature, and does it have a common fix?