Chapter 29 — Denial Management: Why Claims Get Denied, How to Fix Them, and How to Prevent Them

📍 Where you are

Chapter 28 posted the remittance and left \$128.40 sitting in a category.

This chapter decides what that category is, which sounds like an administrative question and is the difference between money recovered, money lost, and — the outcome most practices never reach — money that never has to be recovered because the denial stops happening.

Part VI opens here. Four chapters on what happens after the payer says no: classify it (29), argue it (30), chase what is left (31), and bill the patient what is genuinely theirs (32).

Overview

Denial management has a reputation as the grim part of the revenue cycle, and there is a version of it that deserves the reputation: a queue of angry work, done under time pressure, by people measured on how much of it they got through.

That version is a treadmill and this chapter is about getting off it.

The argument is in three moves.

Most denial work is misdirected. Chapter 20 §20.10 named four reasons a valid code does not pay and only one of them is arguable. Chapter 21 §21.11 refined it for edits and three of its six branches say do not appeal. A practice that works every denial the same way is spending most of its effort on categories that cannot be won.

The classification is worth more than the fix. Fixing a denial recovers one claim. Knowing what kind it was — accurately, in a category somebody chose deliberately — is the only input to preventing the next four hundred.

And the numbers most practices report are the wrong ones. §29.7. Denials worked is not denials resolved. A denial rate without a rejection rate beside it is half a measurement — Chapter 27 §27.7 — and an averaged overturn rate hides the category that never wins.

The chapter's thesis: a denial is data about your own organization, arriving with an invoice attached. Most practices pay the invoice and throw away the data.

29.1 A denial is a decision; a rejection is not

Chapter 27 §27.7 drew this line and this chapter depends on it, so it is restated here in the form that matters for the work.

A DENIAL is an adjudication decision. The payer received the claim, processed it, and decided not to pay. It has a claim number, a reason code, and appeal rights with deadlines.

A REJECTION is a claim that never arrived. It failed at the clearinghouse or the payer's front end. There is no decision, nothing to appeal, and the timely filing clock never stopped.

Three operational consequences.

They are worked differently. A rejection is corrected and resubmitted as a new claim. A denial is appealed, or corrected and resubmitted as a corrected claim — §29.6 — and confusing the two produces either a duplicate or an unappealed loss.

They are found differently. Rejections live in an acknowledgment report — Chapter 27 §27.6. Denials arrive on a remittance. Two documents, two processes, and a practice that has one and not the other has a blind side.

And they are counted differently, or should be. §29.7.

A fourth consequence, less obvious and worth stating because it decides staffing. They arrive on different clocks. A rejection surfaces within days of submission; a denial surfaces when the payer adjudicates, which for Account 10-4471 was fourteen days after the acknowledgment. So the two kinds of work do not compete for the same hour — the rejection report is a morning task on a two-day cycle, and denials arrive in the batches a remittance creates. A practice that treats them as one undifferentiated pile is scheduling a daily task and a weekly one as though they were the same job.

⚠️ Where Claims Die

The most common structural failure in this chapter is a denial work queue that is fed only by remittances.

It is a perfectly good queue and it is complete with respect to denials. Rejections are not in it, because a rejection never generated a remittance line.

So a practice can have a well-run, well-staffed, closely measured denial operation and still lose claims at a steady rate to a report nobody opens — Chapter 27's Case Study 1, which is fourteen months of exactly this.

The fix is one line in a job description, and it is worth writing out because it is easy to agree with and easy not to do: the person who works denials also works rejections, and both counts appear on the same report.

29.2 The taxonomy: seven categories

Denials sort into a small number of families, and knowing them lets you predict the fix before you read the details.

Three observations that make the taxonomy useful rather than decorative.

The rightmost column is the point. Four of the seven are not the coder's — and in most practices the four that are not the coder's are the majority by volume. Eligibility and authorization denials alone routinely outnumber every coding denial combined.

The categories are not equally winnable. A documentation denial can be argued if the record supports it. A timely filing denial generally cannot. A duplicate is usually a workflow artifact and is resolved rather than appealed.

And one category is a liar. "Duplicate" frequently means somebody else's claim — Chapter 17's Case Study 2 spent four months looking internally for a duplicate that belonged to another practice entirely. Read the CARC and the RARC together (Chapter 28 §28.4) and ask what the payer actually saw.

What each family looks like when it arrives

The category names are abstract; the denials are not. Recognizing them on sight is most of the speed in this work.

ELIGIBILITY arrives as member not found, coverage terminated, services not covered under this plan, or an OA group code pointing at another payer (Chapter 28 §28.3). The tell is that nothing about the claim is wrong — it is a correct claim sent to the wrong place, or to the right place at the wrong time.

AUTHORIZATION arrives as precertification absent, referral required, or — the one that catches people — an authorization that exists and does not cover what was done. Chapter 24 §24.6: the number without its scope is a number, not a record. A denial on an authorized service is frequently a scope problem, not an absence.

CODING is the family everyone expects and it splits three ways in practice: code selection (wrong or deleted code), modifier (missing, wrong, or unsupported), and units (Chapter 20 §20.3's arithmetic). They have different owners and different fixes, which is why §29.4's list keeps them apart.

DOCUMENTATION arrives as the documentation does not support this level of service or records requested. It is the only family where the claim may be entirely correct and the answer still lives in a chart.

TIMELY FILING arrives as CO-29 and is the family with the least to discuss and the most to prevent.

COVERAGE / NECESSITY arrives as CO-50, PR-204, or a reference to a policy document. Chapter 22's test applies: coded wrong, or never going to be covered.

And DUPLICATE arrives as CO-18, and the first question is always whose claim.

🎓 Exam Watch

Credential exams test the taxonomy by scenario, and the reliable pattern is: a scenario describes a denial, and the question asks who should fix it or what the next step is.

The trap is that the plausible answer is usually "the coder." Read the scenario for where the failure originated, not for where the denial landed.

"A claim denies because the patient's coverage terminated two weeks before the visit." — not a coding denial. Eligibility, and it was preventable at check-in.

"A claim denies as a duplicate; the practice finds no duplicate in its own system." — look outward, not inward.

And know that a rejection is not on the denial list at all. A question offering "appeal it" for a front-end rejection is offering an action that does not exist.

🔢 Code It

Six denials. Category, owner, and whether it is winnable.

text 1. CO-29 the time limit for filing has expired 2. CO-197 precertification/authorization absent 3. PR-204 not covered under the patient's current benefit plan 4. CO-18 exact duplicate claim or service 5. CO-16 with a RARC naming an invalid rendering provider identifier 6. CO-50 not deemed a medical necessity

1 — TIMELY FILING · the process · almost never winnable. (And before closing it, Chapter 27 §27.7: was this claim rejected earlier and resubmitted late? If so it is a preventable administrative write-off with a cause, not a contractual one.)

2 — AUTHORIZATION · the front end · rarely winnable after the fact. Some payers permit retroactive authorization in defined circumstances; ask before writing it off, and either way it belongs in the preventable count.

3 — COVERAGE / BENEFIT · policy · not winnable by argument. The service is not a benefit. The only live question is whether the patient was told in advance — Chapter 22 §22.7, and PR means the payer holds them liable, which is not the same as saying you may collect.

4 — DUPLICATE / WORKFLOW · the workflow · usually resolvable rather than appealable. And look outward before inward. Chapter 17's Case Study 2.

5 — CREDENTIALING · NOT BILLING · not winnable by anyone in the billing office. Chapter 25 §25.7. Resubmitting will not change it, and a queue that keeps returning it to a biller is generating labor that cannot possibly succeed.

6 — DOCUMENTATION or COVERAGE, and you cannot tell which from the code. This is the one that requires reading. Chapter 22's test: coded wrong (fixable) or never going to be covered (not fixable by coding). CO-50 is the reason code that most rewards opening the record and most often does not get it.

The lesson: six denials, and exactly one of them is worth an argument on the merits. Two are preventable process failures, one belongs to a different department entirely, one is a workflow artifact, and one is a policy fact. A practice that treats these as six units of the same work is the practice Chapter 21's Case Study 1 describes.

29.3 Hard and soft, preventable and not

Two independent axes, frequently confused, and the confusion produces bad reporting.

HARD versus SOFT describes whether the money can still be obtained.

A SOFT denial is recoverable — correct something, supply something, appeal, and it can still pay. A HARD denial is not. The claim is dead; the amount becomes a write-off.

PREVENTABLE versus NON-PREVENTABLE describes whether the practice could have stopped it.

                      PREVENTABLE          NOT PREVENTABLE
                 ┌────────────────────┬────────────────────┐
      SOFT       │ missing modifier   │ payer edit you     │
   (recoverable) │ wrong POS          │  cannot predict    │
                 │ authorization on   │ retroactive        │
                 │  file, not on the  │  eligibility       │
                 │  claim             │  change            │
                 ├────────────────────┼────────────────────┤
      HARD       │ TIMELY FILING      │ genuinely          │
   (dead)        │ no authorization   │  non-covered       │
                 │  obtained          │  service           │
                 │ ►► THE EXPENSIVE   │ patient not        │
                 │    QUADRANT        │  eligible, ever    │
                 └────────────────────┴────────────────────┘

The bottom-left quadrant is where a practice loses money it never had a chance to argue for. A timely filing denial on a correctly coded, medically necessary, fully documented service is a total loss caused entirely by process — and Chapter 27's Case Study 1 generated them by the hundred.

Two clarifications worth making explicitly.

Preventable does not mean somebody was careless. Chapter 24 §24.10's argument stands: the front end's failures are usually questions nobody had written down. A category being preventable is a statement about the process, not about a person, and reporting it as the second is the fastest way to stop getting accurate data.

And a soft denial left unworked becomes a hard one. The deadline is the only difference. Which is why §29.5's queue is ordered by deadline and not by dollar.

One more distinction, because the two axes get collapsed constantly. A denial can be non-preventable and still be your problem to work, and it can be preventable and still have been correctly handled at every step. Account 10-4471 is the second: the claim was right, the modifier was right, the appeal was won — and a scrubber rule would have stopped the denial from occurring. §29.10 returns to this, because students reliably read "preventable" as "somebody erred," and that reading is the single largest cause of under-reported prevention data in real practices. A category nobody will admit to is a category nobody can fix.

29.4 Root-cause classification, and why the category matters more than the fix

Here is the distinction the whole chapter turns on.

The REMEDY is what you do about this claim. The ROOT CAUSE is what produced it.

They are frequently different, and most denial systems record the first because it is what the person working the claim did.

An example that occurs everywhere. A claim denies for a missing modifier. The biller adds the modifier and resubmits. The system records: "corrected and resubmitted."

True, useless, and it will happen again next week, because the actual root cause is one of:

The coder did not know the modifier was required — a training root cause. The template does not prompt for it — a documentation root cause. The scrubber does not check for it — an edit root cause. The payer changed its policy — an external root cause. Or the chargemaster maps the code without it — Chapter 26 §26.5's maintenance root cause, a chargemaster problem wearing a claim's clothes.

Five root causes, one remedy. A log that records the remedy cannot tell you which, and the fix is different in every case.

The integrated triage — the book's three frameworks as one test

Three earlier chapters each built a piece of this, and each promised it would be assembled. Here it is.

   BEFORE YOU WORK A DENIAL, ANSWER IN ORDER:

   ── 1 ── WHICH OF THE FOUR?  (Ch. 20 §20.10)
      bundled ................... nothing to appeal. Remove the charge.
      not a benefit at all ...... notice and liability modifiers.
      not recognized by this
        payer ................... use the code that payer has.
      not necessary AS
        DOCUMENTED .............. ►► THE ONLY ARGUABLE ONE

   ── 2 ── IF IT IS AN EDIT, WHICH BRANCH?  (Ch. 21 §21.11)
      indicator 0 ............... DO NOT APPEAL
      indicator 1, docs support . APPEAL, quoting the Policy Manual
      indicator 1, docs do not .. DO NOT APPEAL — correct the claim
      MAI 2 ..................... DO NOT APPEAL
      MAI 1 or 3 ................ workable
      proprietary ............... GET THE POLICY FIRST

   ── 3 ── IF IT IS NECESSITY, WHICH KIND?  (Ch. 22)
      CODED WRONG ............... fixable. Correct and resubmit.
      NEVER GOING TO BE
        COVERED ................. not fixable by coding. The
                                  question is whether the patient
                                  was told in advance.

Read the whole thing and count. Of the branches available, the ones that say "appeal" are a minority. Chapter 21's Case Study 1 is a denials team that spent a year writing letters into a category with an overturn rate of zero, and every one of those letters was written by a competent person doing what they had been asked to do.

**The triage costs about ninety seconds and it is the highest-return ninety seconds in the

revenue cycle.**

Not because it wins appeals. Because it stops you from writing the ones that cannot be won, which frees the time to write the ones that can.

A root-cause category list you can actually use

A workable list is short enough that people use it and long enough to distinguish the fixes.

   REGISTRATION / ELIGIBILITY ...... Ch. 24
   AUTHORIZATION ................... Ch. 24 §24.6
   CREDENTIALING / ENROLLMENT ...... Ch. 25 §25.7 — NOT fixable by billing
   CODING — CODE SELECTION ......... Chs. 13, 19
   CODING — MODIFIER ............... Ch. 14
   CODING — UNITS .................. Ch. 20 §20.3
   EDIT — NCCI / MUE ............... Ch. 21
   EDIT — PROPRIETARY PAYER ........ Ch. 21 §21.11
   DOCUMENTATION ................... Chs. 4, 22
   CHARGEMASTER / MAINTENANCE ...... Ch. 26 §26.5
   CLAIM DATA (non-clinical field) .. Chs. 25, 26
   TIMELY FILING ................... Ch. 27 §27.7
   COVERAGE / BENEFIT .............. Ch. 22
   DUPLICATE / WORKFLOW ............ §29.6
   PAYER ERROR ..................... Ch. 28 §28.8

Three rules for using it.

One category per denial, chosen deliberately. A list with a catch-all "other" will collect a third of everything, and the third it collects is the interesting third.

"Credentialing" is on the list because it is not fixable by billing. Chapter 25 §25.9's third rejection cause. A denial routed to a biller who cannot fix it will be worked, resubmitted, and denied again, indefinitely, until somebody categorizes it correctly.

And "payer error" must be available. If your list assumes every denial is your fault, §28.8's findings have nowhere to go and they will be miscategorized as coding problems.

29.5 Working a denial in order

Two questions: what do you work first, and what do you do when you get there.

Ordering the queue

The instinct is to sort by dollar amount. It is wrong, or at least it is third.

   SORT BY:

   1.  DEADLINE          ► a soft denial becomes a hard one
                           on a date. Nothing else can do that.
   2.  CATEGORY          ► work like with like. Twelve denials
                           of one kind are one investigation,
                           not twelve.
   3.  DOLLAR            ► within a category, within a deadline.

Why deadline first: §29.3's bottom-left quadrant is created by time, not by difficulty. A \$2,000 denial with sixty days left is safer than a \$180 denial with four.

Why category second: because twelve denials with the same reason code from the same payer are one finding. Working them individually costs twelve times as much and produces no root cause. Chapter 21's Case Study 1 is a year of denials worked one at a time, none of which revealed the pattern.

And dollar third, because within a category and a deadline it is the right tiebreak and nowhere else.

One category deserves its own rule: denials with no appeal rights and no fix should be closed immediately, categorized, and reported. RARC MA130 says so explicitly (Chapter 28 §28.4). Leaving them in the queue makes the queue lie about how much recoverable work exists.

Working one

   1. READ THE REMITTANCE — group code, CARC, RARC, amount.
      Ch. 28 §28.4. Not the software's summary. The codes.

   2. RUN THE TRIAGE — §29.4. Ninety seconds. Most of the time
      it ends here, correctly, with "do not appeal."

   3. CLASSIFY THE ROOT CAUSE — before doing anything about it,
      because afterwards you will remember the remedy.

   4. DECIDE: appeal · correct and resubmit · close · escalate.

   5. ACT, and record what you did AND what caused it.

   6. IF THE PATTERN IS LARGER THAN THIS CLAIM, SAY SO —
      to somebody who can change the process. Ch. 21 §21.10:
      "report a pattern, not an instance."

Step 3 before step 4 is the whole discipline. Classifying after acting produces a log full of remedies, which is §29.4's failure.

⚠️ Where Claims Die

A queue is not a control. A person who works the queue is a control.

Chapter 27's Case Study 1 established this about a report; it is equally true of a queue, and the failure mode is subtler because a queue looks like it is working. Items enter it. Items leave it. Somebody is busy.

Four questions that find a queue in trouble:

"How many items are in it?" A number nobody knows is a number nobody manages.

"What is the oldest item, and why is it still there?" The reason is almost always that it is hard, and hard items sink in every queue that lets people choose.

"How many items were closed as 'no action' last month?" If the answer is zero, items that cannot be won are still in there, and the queue is overstating the recoverable work.

"What is in the queue that nobody in this department can fix?" Credentialing, chargemaster, payer error. They will be worked forever by people without the authority to resolve them unless somebody routes them out.

📋 Read the Chart

Source: a denial work queue, exported, handed to you because "we can't keep up" What it says:

```text OPEN ITEMS ......................... 412 OLDEST ITEM ........................ 287 days CLOSED LAST MONTH .................. 138 of which RESOLVED ................ 49 of which RESUBMITTED ............. 71 of which "no action" ............. 0

TOP REASON CODES (open) CO-197 authorization ............ 96 CO-16 with RARC (provider ID) .. 58 CO-97 bundling ................. 44 CO-29 timely filing ............ 39 [uncategorized] .................. 104

SORT ORDER ......................... descending by charge ```

What it means: at least five findings, and "we can't keep up" is not one of them.

The sort order is wrong and it is the most damaging line on the page. Descending by charge means the deadline is invisible. §29.5: a soft denial becomes a hard one on a date, and this queue surfaces a large old claim ahead of a small claim expiring Friday.

"No action: 0" means nothing is ever being closed as unwinnable. With 39 open timely filing denials and 58 credentialing items, that is not possible. The queue is carrying dead items as though they were recoverable work, which is why the count is 412.

The 58 CO-16 provider-identifier items are not billing's. Chapter 25 §25.7. If they are being resubmitted, that is 58 items of guaranteed-futile labor, repeating.

104 uncategorized is 25% of the queue, and it is the interesting 25%. §29.4: a catch-all collects exactly what a root-cause report needs. This is the single number to fix first, because every other analysis on this page is computed on three-quarters of the data.

And 138 closed with only 49 resolved. Chapter 21's Case Study 1's line, arriving as a report: measure denials resolved, not denials worked. The team closed 138 items and recovered money on 49 — and nobody looking at "138 closed" would know.

What to do about it: none of the five requires more staff, and four of them are configuration or routing. The oldest item at 287 days is a symptom of the sort order, not of capacity.

Where it appears: the queue in front of you. "We can't keep up" is nearly always a statement about what is in the queue rather than about how fast people work.

29.6 Corrected claims, voids, and replacements

A denial that needs a corrected claim rather than an appeal is common, and the mechanism is the same failure on both forms.

### Both errors produce the same thing: A DUPLICATE.

Not a correction. The payer now has two claims, denies the second as a duplicate, and the original problem is still unfixed. Chapter 25 §25.3 and Chapter 26 §26.3 each said this about their own form; it is the same failure and it is worth learning once.

Three rules.

Replacement replaces; void withdraws. Use a replacement when the claim should exist and be different. Use a void when the claim should not exist at all — a claim billed for the wrong patient, the wrong provider, the wrong date.

You need the original claim number. It comes back on the remittance (Chapter 28 §28.1). A corrected claim without it is frequently rejected or treated as new.

And correcting is not appealing. A corrected claim says "here is different information." An appeal says "your decision was wrong about the information you had." Submitting a corrected claim when you meant to appeal can restart timely filing arguments and, at some payers, forfeit the appeal rights attached to the original determination. Chapter 30 §30.1.

🔍 Check Your Understanding

For each, say whether you appeal, correct and resubmit, void, or close — and give the root-cause category.

1. A claim denies because the units on a drug line are twice the documented dose.
2. A claim denies CO-97 with RARC N19; the note documents a separately identifiable service.
3. A claim denies for no prior authorization; there is no authorization and the service is done.
4. A claim denies as a duplicate; nothing in your system matches it.
5. A claim denies with RARC MA130.
6. A claim denies because the rendering provider is not enrolled with this payer.

Answers:

1 — CORRECT AND RESUBMIT. Root cause: coding — units (Chapter 20 §20.3). You billed the wrong number; there is nothing to argue.

2 — APPEAL. Root cause: edit — payer. Chapter 21's triage: an edit whose documentation supports the override. This is Account 10-4471.

3 — Depends, and this is the hard one. Frequently a hard, preventable denial with nothing to appeal (Chapter 24 §24.6). Some payers permit retroactive authorization in defined circumstances — ask before writing it off. Root cause: authorization, and it belongs in the preventable count whatever the outcome.

4 — INVESTIGATE OUTWARD, then usually appeal or resolve. Root cause: duplicate/workflow — and it may be somebody else's claim. Chapter 17's Case Study 2.

5 — CLOSE. MA130 says the claim is incomplete or invalid and has no appeal rights. Correct and resubmit if it is fixable; otherwise close it, categorize it, and do not leave it in the queue.

6 — ESCALATE OUT OF BILLING. Root cause: credentialing/enrollment. Chapter 25 §25.7. No amount of resubmission will change it, and a biller working it repeatedly is the exact failure §29.4's category list exists to prevent.

29.7 The denial log and the numbers it produces

A denial log is one row per denied line, and it is the only artifact in this chapter that turns individual claims into knowledge about a practice.

What a row needs:

   date of service · date of denial · payer · provider ·
   CODE and MODIFIERS · CHARGE and ALLOWED ·
   group code · CARC · RARC ·
   ROOT CAUSE CATEGORY (§29.4) ·
   PREVENTABLE? (§29.3) ·
   action taken · outcome · DATE RESOLVED

Two of those fields are the ones practices leave out, and they are the two that make the log worth keeping: root cause category and outcome.

The numbers

Four things to say about that list, and each one corrects a common practice.

Measure denials RESOLVED, not denials WORKED. Chapter 21's Case Study 1 owes this section the line by name: the two numbers are identical until a category is unwinnable, and that is exactly where you need to look. A team that worked four hundred denials and resolved none was fully occupied and fully productive by the wrong measure.

Split categories finely enough to see zero. Chapter 21's Case Study 1 again: an averaged overturn rate concealed a category with a zero-percent success rate, because other categories were doing well. A rate that is an average of a winner and a loser tells you about neither.

Put the rejection rate next to the denial rate. Chapter 27 §27.7's argument, and Chapter 27's Case Study 1 is what happens without it — a denial rate that improved every month the practice lost more money, because rejected claims never reach adjudication and so never deny.

And count the preventable administrative write-offs. Chapter 28 §28.6 created that category specifically so this report could consume it. Preventable write-offs are the practice's own process failures, priced in dollars, and they are the number that makes §29.9's argument for you.

The denominator problem, which nobody warns you about

"Denial rate" is not one number. It is a family of numbers that differ by a factor of two or more, and two practices comparing their rates are frequently comparing different things.

   THREE CHOICES, EACH DEFENSIBLE, EACH DIFFERENT

   1. LINES or CLAIMS?
        Account 10-4471 is ONE claim with ONE denied line
        of four. Denial rate 100% by claim, 25% by line.

   2. ZERO-PAY only, or ANY ADJUSTMENT that is not
      contractual?
        A line paid at a reduced rate with a CO-151 was
        partially denied. Counting only zero-pay lines
        misses it entirely.

   3. WHAT IS THE DENOMINATOR — everything adjudicated,
      or everything SUBMITTED?
        Submitted includes claims still in process, which
        makes a recent period look better than it is.

Three rules that make the number usable.

Pick one definition, write it down, and never change it silently. A denial rate whose definition moved is worse than no denial rate, because a trend across a definition change is meaningless and looks real.

Report lines, not claims, for operational work. A line is what denies, what gets appealed, and what has an allowed amount. Claims are the right unit for first-pass resolution and the wrong unit for almost everything else.

And be extremely careful with external benchmarks. A published industry denial rate was computed under somebody else's three choices. Comparing your number to it is a comparison of definitions at least as much as of performance — which is why §29.9 recommends comparing yourself to yourself.

🧮 Run the Numbers

Northgate Family Medicine's denial log, one month. (Constructed and illustrative.)

```text LINES ADJUDICATED ...................... 4,180 DENIED LINES ........................... 267 6.4%

BY ROOT CAUSE registration / eligibility ........... 71 26.6% authorization ........................ 44 16.5% coding — modifier .................... 38 14.2% edit — payer ......................... 36 13.5% documentation ........................ 24 9.0% claim data (non-clinical) ............ 21 7.9% coverage / benefit ................... 18 6.7% duplicate / workflow ................. 9 3.4% credentialing ........................ 6 2.2% ───── 267

PREVENTABLE ............................ 185 69.3%

APPEALS DECIDED ........................ 84 APPEALS UPHELD IN THE PRACTICE'S FAVOR . 57 ► OVERTURN RATE ........................ 68% ```

Checks: 71+44+38+36+24+21+18+9+6 = 267 ✓ · 267 ÷ 4,180 = 6.4% ✓ · 57 ÷ 84 = 67.9%, reported as 68% ✓

Three readings.

The two largest categories are not coding. Registration and authorization are 43% of denials between them, and neither is fixable by anyone in the coding department. This is the ordinary result and it is why §29.9 is addressed to a practice's leadership rather than to its coders.

69% preventable. Not "preventable by working harder" — preventable by a process that does not currently exist. Chapter 24 §24.10's argument, quantified for one practice.

And the overturn rate is 68%, which means this practice wins roughly two of every three appeals it decides to file. That is a good number and it invites a question this chapter deliberately does not answer: 68% of what, and is filing always worth it? Chapter 40 answers it, using this figure and one other that Chapter 31 will publish.

29.8 Prevention: edits, templates, and the front end

Every denial in §29.7's log was preventable or it was not, and the preventable ones can be stopped in exactly three places.

   THE FRONT END          before the visit
     eligibility, authorization, registration accuracy
     ► Ch. 24. Fixes 43% of Northgate's denials.

   THE TEMPLATE           during the visit
     the note prompts for what the code requires
     ► Chs. 4, 15, 22. Fixes documentation and some
       modifier denials, and it is the only one that
       improves the RECORD rather than the claim.

   THE EDIT               after the visit, before submission
     the scrubber checks what the payer will check
     ► Chs. 21, 25, 27. Fixes coding, claim data, and
       known payer edits.

Three principles for building any of the three.

Prevent where the information exists. A modifier denial is preventable at the edit only if the information needed to add the modifier is on the claim. When it is not — when the answer is in the note — it is a template problem wearing an edit's clothes, and building a scrubber rule for it produces a rule that stops claims and cannot resolve them.

An edit that stops a claim must tell somebody what to do. A scrubber rule that fires with a message nobody understands converts a denial into a held claim, which is better and is not free. Chapter 27 §27.5's over-strict edits are the failure mode.

And prevention is a fixed cost against a recurring loss. This is the argument that makes the whole chapter economic: a denial costs you every time it happens. An edit costs you once.

What each of the three actually looks like

The abstraction is easy to agree with and hard to act on, so here is the concrete version of each.

The front end. Chapter 24 built this and Northgate's log says it is 43% of the denials. The specific interventions are small: a real-time eligibility check with a stated rule about who gets one · a question at scheduling about what the visit is for, which is what makes procedure screening possible at all · a defined re-verification window rather than "we checked them last year" · and an authorization record that captures the SCOPE, not just the number (Chapter 24 §24.6, and the number without its scope is a number, not a record).

The template. This is the one clinicians own and the one billing people are worst at asking for. The intervention is a prompt, not a default — "is this problem being addressed today?", "what supports the decision to inject?" — and it works because the physician is the only person who can answer, at the only moment when answering is honest. Chapter 4's copy-forward warning and §29.8's compliance callout both bound what a template may do; inside those bounds, a well-designed prompt is the highest-value prevention in the book, because it improves the record rather than the claim.

The edit. The scrubber, and the discipline is knowing what it can and cannot see. It can check anything present on the claim: code validity, modifier presence, units against an MUE, place of service against the setting, required fields, known payer-specific requirements from a companion guide (Chapter 27 §27.1). It cannot check whether the note supports what the claim asserts, and a rule that pretends otherwise is either useless or dangerous.

A practical sequencing note. Build edits for the categories your log says are large, in the order the log says. Practices routinely build scrubber rules for the denials that annoyed somebody recently, which is not the same list. §29.7's report exists precisely to replace that instinct with a ranking.

⚖️ Compliance Check

The one prevention technique that is not allowed, and it is tempting because it works.

A template that pre-populates documentation to support a code, or an edit that appends a modifier automatically, prevents denials and creates a compliance exposure.

Chapter 21's Account 31-2245 is modifier 59 appended by a billing macro rather than by a coder reading an operative report. The claims paid. The practice repaid \$25,720.80 and could not defend eleven of forty-two claims that were in fact defensible, because the documentation had not been built at the time.

The line is clean and it is worth memorizing:

An edit may STOP a claim and ask a question. It may not ANSWER the question.

A rule that flags "modifier 25 may be required — has a separately identifiable service been documented?" is prevention. A rule that appends modifier 25 is an assertion the practice did not make about a record nobody read — Chapter 25 §25.2's pattern, and the eleventh and twelfth configuration findings in this book are both versions of it.

The same applies to templates. A template that asks the physician a question is documentation improvement (Chapter 38). A template that carries forward an answer is Chapter 4 §4.7's copy-forward problem, and it degrades every other assertion in the note.

29.9 Building a denial-prevention case for a practice that does not want to hear it

This section exists because the technical work in this chapter is the easy part.

The situation is common enough to be a genre. A biller or a coder can see, from the log, that a category of denial is recurring and preventable. The fix lives in another department — the front desk, the clinical templates, the credentialing coordinator, the chargemaster — and that department has its own work, its own pressures, and no reason to believe a billing person's account of its failings.

Five things that work.

Lead with the number, in dollars, for a period. Not the denial count. "Eligibility denials cost us this much last quarter" is a sentence an administrator can act on; "we get a lot of eligibility denials" is a complaint.

Name the process, never the person. Chapter 24 §24.10 and Chapter 26's Case Study 1 both make the same finding: the front end's failures are questions nobody had written down, and the person entering a field was frequently never told what it does. A presentation that names an individual will be correct about the facts and will end the conversation.

Bring the smallest possible fix. "Add one question to the check-in script" beats "redesign registration." Chapter 24 §24.11's three cheap things are the model: ask what the visit is for, screen the likely procedure, frame the copay as a copay. None costs anything and each prevents a category.

Show a comparison rather than a target. "Our authorization denial rate is 16.5% of denials; here is what it was before the staffing change" is evidence. An industry benchmark from a source nobody in the room trusts is an argument about the benchmark.

And ask for a measurement, not a commitment. "Can we track this for one quarter and look again?" is nearly always accepted, and a category that is being measured usually improves before anybody changes anything — which is not a trick, because measuring it is itself a process change.

📞 On the Phone

"We don't have time to check eligibility on every patient."

This is a legitimate objection from someone with a legitimate constraint, and the response that fails is the one that treats it as an excuse.

Four things to say:

"How long does the check take?" Chapter 24 §24.3's 270/271 is a real-time transaction and the answer is usually seconds, at the desk, for most payers. A great many objections here are about a process the objector has not seen work.

"Which patients would you check, if you could only check some?" New patients, patients with a coverage change on file, and anyone whose last verification is older than a defined window. A partial process that runs is worth more than a complete one that does not.

"What happens now when it fails?" Follow the labor. The denial is worked by somebody, the claim is resubmitted or written off, and frequently a patient is billed and calls. The work does not disappear; it moves to a more expensive place and arrives later.

"Can we look at this again in a quarter?" Ask for the measurement.

What does not work: presenting the denial rate as evidence that the front desk is doing a bad job. It is evidence that a process is missing, and those are different claims that sound similar.

When the answer is no

Sometimes you do everything above and the answer is still no, and this section would be dishonest if it stopped at the version where the presentation works.

Three responses that are worth something, and one that is not.

Ask what would change the answer. Not rhetorically. "If this category doubled, would we revisit it?" A stated threshold is a real outcome — it converts a refusal into a condition, and conditions get met. A great many "no" answers are actually "not at this size."

Ask for permission to keep the measurement running. You will almost never be refused this, and the number continues to accumulate whether or not anybody acts on it. A quarter later you are presenting a trend rather than a snapshot, and a trend is a substantially different conversation.

And do the part you control. Chapter 24's front end may be out of your reach; the edit and the work queue are not. §29.8's third place — the scrubber — is frequently owned by billing, and fixing what you own both recovers money and demonstrates that the analysis was right, which is the most persuasive thing available to you.

What is not worth anything: escalating past the person who said no, early. It converts a disagreement about priorities into a conflict about authority, and the next time you bring a finding — even a correct one — it arrives as a political act. There are situations that require escalation; a declined process improvement in the first quarter is not one of them.

One more thing, and it is the reason this section exists at all. Write down what you found and when you reported it. Not defensively — Chapter 21 §21.10 makes the same recommendation for a different reason. A dated record of a correct analysis that was declined is how the same finding gets acted on eighteen months later, when the number is bigger and somebody asks whether anyone saw this coming.

29.10 🗂️ The Encounter — working Account 10-4471's CO-97

Day 20, Monday, April 3, on Chapter 1's Encounter timeline. The denial from day 17 reaches a person.

Touch 1 — read, classify, pull the note

   THE REMITTANCE SAYS
     LINE 1  99214-25  CHG 185.00  PAID 0.00
       CO   45   56.60
       CO   97  128.40
       RARC N19

Step 1 — read the codes. Chapter 28 §28.4. CO means the patient may not be billed. 97 means the payer asserts this service is included in another service's payment. N19 names the relationship: incidental to the primary procedure.

The payer has asserted that the office visit was part of the injection.

Step 2 — run the triage. §29.4.

Which of the four? (Chapter 20 §20.10.) Bundled — the payer says so. Which would ordinarily end the analysis with "nothing to appeal."

But it is an edit, so branch 2 applies. (Chapter 21 §21.11.) The relevant NCCI edit carries modifier indicator 1: a modifier may override it. The claim carries modifier 25. So the question becomes does the documentation support the override — and Chapter 14 §14.4 froze the answer:

   THE FOUR ELEMENTS SUPPORTING MODIFIER 25
   1  three chronic conditions, each separately assessed
      with a plan
   2  prescription drug management — three medications
      reviewed and continued
   3  two laboratory tests ordered with stated clinical
      reasons
   4  a new problem with its own history, examination, and
      independent management decision

   ►► ELEMENTS 1 THROUGH 3 HAVE NOTHING TO DO WITH THE KNEE.

Branch: indicator 1, documentation supports. APPEAL, quoting the Policy Manual.

Step 3 — classify the root cause, before acting.

   ROOT CAUSE ....... EDIT — PAYER
                      ("payer edit — E/M with minor procedure")
   HARD OR SOFT ..... SOFT — recoverable
   PREVENTABLE? ..... see below

Step 4 — the decision. Appeal. Chapter 30 writes it.

Touch 1: 14 minutes. Read the remit, classify, pull the note.

Touches 2 and 3

Day 24, Friday, April 7. Assemble the records, write the appeal, submit it. 31 minutes — Chapter 30 §30.3 shows what was written and why it took that long.

Day 66, Friday, May 19, after the decision letter on day 59. Track, follow up at day 45, post the second remittance. 13 minutes.

   TOUCH 1   read the remit, classify, pull the note ....  14
   TOUCH 2   assemble records, write and submit .........  31
   TOUCH 3   track, follow up at day 45, post ...........  13
                                                          ────
   TOTAL STAFF TIME ON THIS DENIAL ....................... 58 minutes

Check: 14 + 31 + 13 = 58 ✓

The appeal was upheld. The second remittance paid \$98.40 on day 66**, with **\$30.00 moving to patient responsibility — the copay that had been sitting on the account since day 0.

The log entry

   DOS ................ 03/14        DENIED ......... 03/31
   PAYER .............. Northfield Mutual
   CODE ............... 99214-25     CHG 185.00  ALLOWED 128.40
   CARC ............... CO-97        RARC ........... N19
   ROOT CAUSE ......... EDIT — PAYER
                        (E/M with minor procedure, same day)
   HARD / SOFT ........ SOFT
   PREVENTABLE ........ YES — see note
   ACTION ............. APPEALED, level one, 04/07
   OUTCOME ............ UPHELD IN THE PRACTICE'S FAVOR 05/12
   RESOLVED ........... 05/19
   STAFF TIME ......... 58 minutes across 3 touches

The "preventable — yes" entry deserves its note, because it is not obvious and students argue about it.

The claim was correct. The code was right, the modifier was right, the documentation supported it, and the appeal was won on the merits. Nothing about this claim should have been done differently.

And the denial was still preventable, because this payer denies this pairing predictably. A scrubber rule that recognized the pattern and attached the supporting detail — or a documentation template that placed the three chronic conditions where a reviewer would see them — would have changed the outcome without changing the claim's correctness.

"Preventable" does not mean "wrong." It means "a process could have stopped it," and conflating the two is why practices under-report the category.

Q4 — could the denial have been prevented? — was raised in Chapter 24 and is raised again here.

This chapter has now supplied everything needed to answer it: the minutes, the classification, the overturn rate, and the fact that the fix is an edit rather than a coding change.

Chapter 40 answers it. This chapter stops here, deliberately.

Summary

A DENIAL is an adjudication decision with a claim number and appeal rights. A REJECTION never arrived. They are worked differently, found in different documents, and a denial queue fed only by remittances has a blind side the size of your rejection report.

Seven categories: eligibility · authorization · coding · documentation · timely filing · coverage and necessity · duplicate. Four of the seven are not the coder's, and in most practices those four are the majority by volume. And "duplicate" frequently means somebody else's claim.

HARD versus SOFT is about whether the money can still be obtained. PREVENTABLE versus NOT is about whether you could have stopped it. Two independent axes, and the hard-and-preventable quadrant — timely filing, no authorization obtained — is where a practice loses money it never got to argue for. A soft denial left unworked becomes a hard one, which is why the queue sorts by deadline.

The REMEDY is what you did about this claim. The ROOT CAUSE is what produced it.

One missing modifier has five possible root causes — training, template, edit, payer policy, or chargemaster maintenance — and the fix is different in every case. A log recording the remedy cannot tell you which.

The three triage frameworks assemble into one ninety-second test: which of Chapter 20's four reasons · which of Chapter 21's six edit branches · and, if necessity, coded-wrong or never-going-to-be-covered. Most branches say do not appeal, and the value of the test is not that it wins appeals — it is that it stops you writing the ones that cannot be won.

Sort the queue by DEADLINE, then CATEGORY, then dollar. Twelve denials of one kind are one investigation. Close what has no appeal rights immediately, or the queue lies about how much recoverable work exists. And classify the root cause BEFORE acting, because afterwards you will remember the remedy.

Corrected claims: item 22 code 7 or FL 4 frequency 7 to replace; 8 to void. Get either wrong and you have created a duplicate, on both forms, for the same reason. And correcting is not appealing — at some payers it forfeits the appeal rights attached to the original determination.

The denial log's two most-omitted fields are ROOT CAUSE and OUTCOME, and they are the two that make it worth keeping. Measure denials RESOLVED, not worked. Split categories finely enough to see zero. Put the rejection rate beside the denial rate. And count the preventable administrative write-offs, which Chapter 28 §28.6 created this report to consume.

And "denial rate" is not one number. It differs by a factor of two depending on lines or claims, zero-pay only or any non-contractual adjustment, and adjudicated or submitted as the denominator. Pick one definition, write it down, never change it silently — a trend across a definition change is meaningless and looks real — report lines for operational work, and treat external benchmarks as comparisons of definitions at least as much as of performance.

Northgate's month: 267 denied lines of 4,180 adjudicated — 6.4%. Registration and authorization are 43% of them. 69% were preventable. And the practice's appeal overturn rate is 68%.

Prevention happens in exactly three places: the front end, the template, and the edit — and prevention is a fixed cost against a recurring loss.

An edit may STOP a claim and ask a question. It may not ANSWER the question.

And the case for prevention is made with a dollar figure for a period, a named process rather than a named person, the smallest possible fix, a comparison rather than a benchmark, and a request for measurement rather than commitment.

When the answer is still no: ask what would change it — a stated threshold converts a refusal into a condition — keep the measurement running, do the part you control, and write down what you found and when you reported it. Do not escalate past the person who declined, early; it converts a disagreement about priorities into a conflict about authority.

Account 10-4471's CO-97 was read, triaged through both frameworks, classified as a payer edit, appealed, and won — 58 minutes across three touches. The claim was correct and the denial was still preventable, because this payer denies this pairing predictably. Those two statements are compatible, and confusing them is why practices under-report the category.

Q4 remains open.

Key Terms

Denial · rejection · hard denial · soft denial · preventable denial · denial taxonomy · root cause category · remedy versus root cause · integrated triage · denial work queue · queue ordering by deadline · corrected claim · replacement · void · duplicate · denial log · denial rate · initial denial rate · first-pass resolution rate · overturn rate · preventable denial rate · denials resolved · rejection rate · scrubber edit · documentation template · prevention as a fixed cost

Spaced Review

From Chapter 17's Case Study 2 — a "duplicate" that was another practice's claim. Read the CARC and RARC together and ask what the payer saw.

From Chapter 20 §20.10 — the four reasons a valid code does not pay. Only the fourth is arguable, and this chapter finally builds the queue that chapter promised.

From Chapter 21 §21.11 and its Case Study 1 — the six-way edit triage, three branches of which say do not appeal, and a year of letters written into a category with a zero-percent overturn rate.

From Chapter 24 §24.6, §24.10, §24.11 — authorization, measuring the front end, and the three cheap things. Northgate's log says 43% of its denials live here.

From Chapter 25 §25.3, §25.7, §25.9 and Chapter 26 §26.3, §26.5 — item 22 and the frequency digit; credentialing; the chargemaster root cause.

From Chapter 27 §27.6, §27.7 — acknowledgments and the rejection rate that belongs on this report.

From Chapter 28 §28.4, §28.6 — the codes this chapter reads, and the write-off categories it counts.

Coming up: Chapter 30 writes the appeal. The argument, the evidence, the deadline that runs from the determination date, and why this one was won.