Case Study 2 — Every Visit Was Initial: A Composite

A composite built from §12.3's definitions and documented audit patterns. Tier 3; the practice and figures are constructed. The error is among the most common in injury coding.

Background

Section 12.3 called the seventh character the most misapplied convention in ICD-10-CM and gave the reason: "initial" does not mean the first visit.

This is what the misapplication looks like at scale, and why it is worth a case study rather than a footnote: the error produces no rejection, no denial, and no financial signal — and it is trivially visible in data.

The composite

Constructed. Not a real organization.

An orthopedic practice of nine surgeons and four advanced practice clinicians. Competent, busy, and coding is done by a small in-house team using an encoder.

The practice's seventh-character distribution, across injury diagnoses, is roughly 94% "A."

For an orthopedic practice, that is close to impossible. Orthopedics is a specialty defined by follow-up: the fracture is set once and then seen at two weeks, six weeks, twelve weeks. The overwhelming majority of injury encounters in an orthopedic practice should carry D.

Ninety-four percent A means the practice is describing itself, in data, as providing active treatment at essentially every encounter.

How it happened

Three causes, none of them malicious, and the third is the one that surprises people.

Cause 1 — the intuitive definition. Coders and clinicians alike read "initial encounter" as "the first encounter." A patient arriving at the practice for the first time gets A, because it is their first visit here. This is the plain-English reading and it is wrong.

Cause 2 — the default in the workflow. The practice's charge entry template carried A as the pre-populated seventh character, because A is the most common value for the first encounter of any injury and someone had configured it years earlier to save keystrokes. Changing it required an affirmative action at every follow-up visit, and it frequently did not happen.

This is Chapter 6's Case Study 2 in a different costume: an automatic default, configured once, operating at volume, unreviewed.

Cause 3 — nothing ever pushed back. No claim rejected. No payer denied. No edit fired. The seventh character is a valid character either way, and the claim adjudicates identically.

The practice had no feedback loop of any kind on this field, and in the absence of feedback the default persisted for years.

What it cost

Constructed, and the interesting part is that the direct cost is nearly zero.

On the claims themselves: nothing measurable. Payment for an office visit does not turn on the injury code's seventh character.

In the practice's data: the record is wrong. Every patient's injury history reads as a series of new acute events rather than as one injury with a course. A patient with a single wrist fracture seen five times appears, in the practice's own data, to have had five encounters of active treatment.

And in exposure: the pattern is a flag. A 94% initial-encounter rate in an orthopedic practice is visible to any analytics program looking at it, and what it suggests — that the practice is billing active treatment at every visit — is a question about the services billed alongside those diagnoses, not about the diagnosis codes themselves.

That is the real risk and it is indirect. The seventh character error costs nothing. It draws attention to the claims around it, and whether that attention finds anything depends on what else the practice is doing.

What it shows

First, a plain-English reading of a technical term is the most durable kind of error, because nothing corrects it. The coder is not confused; they are confident, and their confidence is based on what the words appear to mean. §12.3's decision tree exists precisely to replace the intuitive question ("which visit is this?") with the correct one ("what kind of care is this?").

Second, a pre-populated default in a workflow will be accepted. Not because people are careless — because the default is right often enough that overriding it becomes the exception, and exceptions get missed under time pressure. A default that is correct 30% of the time will be accepted 90% of the time.

Third, the absence of a feedback signal is what allowed it to persist. This is now the fourth case study in this book with the same structure: Chapter 6's scrubber rules, Chapter 8's added instruction, Chapter 9's ED coding, Chapter 10's history code. In every one, the error produced no rejection and was found — when it was found — by someone reading records or reading data, not by any control the organization operated.

That repetition is deliberate. The single most important structural fact about revenue cycle errors is that the dangerous ones do not announce themselves.

Fourth, and specific to this case: the finding was available from the practice's own data in about five minutes. A distribution of seventh characters, by code, is a query any practice management system can run. Nobody had run it because nobody had thought to look at a field that never causes a denial.

The lesson

The errors worth hunting are the ones with no financial signal, and you find them by looking at distributions rather than at claims.

Three carry-forwards:

Replace the intuitive question with the correct one, explicitly. Not "which visit is this?" but "what kind of care is this?" §12.3's decision tree, taped to a monitor if necessary.

Audit your defaults. Every pre-populated field in a charge-entry workflow is a decision somebody made once and nobody has reviewed. Chapter 6 §6.5's scrubber inventory generalizes: list the defaults, and read a month of output.

And look at distributions. A seventh-character distribution, an unspecified-code rate, a level distribution, a modifier frequency. These take minutes, they require no chart review, and they find things that no claim-level control ever will. Chapter 37 §37.2 builds this into an internal audit program.

Discussion questions

1. The error cost essentially nothing directly and the case study still treats it as serious. Defend that position, then argue against it.

2. §12.3's decision tree replaces "which visit is this?" with "what kind of care is this?" Design the one-sentence prompt you would put in a charge-entry workflow to force the correct question.

3. A default that is correct 30% of the time gets accepted 90% of the time. Is the answer to remove defaults, or to change them? What would you do here specifically?

4. Four case studies in this book now share the structure "no financial signal, found by looking rather than by a control." List them, and say what a control that would have caught them would have to look at.

5. The practice's 94% figure was available in five minutes from its own data. What three other distributions would you run on your first day in a new coding department, and what would each tell you?