Paying twice for the same denial
A denial arrives with a reason code. Somebody reads it, works out what it means for this payer, this service and this contract, establishes what will actually fix it, and fixes it. Then the knowledge goes into that person's head, or into a note attached to that one claim, and the next claim carrying the same code from the same payer costs the same again.
The code is not the knowledge
Reason codes are a shared vocabulary, which means they are general by design. A code saying that a claim lacks information required for adjudication is true of a great many situations that need completely different responses. Two payers return the same code for different underlying causes, and one payer returns it for different causes on different service lines.
So the analysis is never "what does this code mean". It is "what does this payer mean when it sends this code on this kind of claim, and what has actually resolved it". That is the expensive part of the touch, and it is the part that is identical across every claim in the group.
Count the recurrence before deciding it does not matter
The arithmetic here uses reports you already have. Take your largest payer, take its most frequent denial reason from last quarter, and count the claims that carried it. Every one of them paid for the same lesson, at whatever a touch costs you.
Then look at the second reason, and the third. The distribution is usually steep: a small set of payer-and-reason pairs accounts for most of the volume. That steepness is good news, because it means a small amount of captured knowledge covers a large share of the work.
What to capture, and where to attach it
The instinct is to write it in the claim note, and that is where it dies. A note attached to a claim is retrievable only by someone already looking at that claim — which is exactly the person who does not need it.
The knowledge belongs against the pair rather than the claim: this payer, this reason code, this kind of service. What is worth recording is short.
- what the payer actually means by this code in this context
- what has resolved it before, and what did not
- what to check before attempting the resolution, so the attempt is not wasted
- whether claims in this category are worth pursuing at all
Four lines. If it takes longer than that to write, it will not be written, and a rule nobody follows is worse than no rule, because it creates the belief that the knowledge has been captured.
The test of whether it is working
There is a clean measure. Does the second claim in a payer-and-reason group take less time than the first? Touches per resolution, cut by payer and reason code, is the number to watch. If the group's average is not falling as the group grows, the knowledge is not reaching the person doing the work — either it is not being captured, or it is not being found.
That failure is usually about retrieval rather than capture. Plenty of operations have the knowledge written down somewhere, in a shared document nobody opens while working a claim, because opening it costs more than guessing.
The other reason recurrence matters
A denial reason that repeats is information about something upstream. Registration errors, coding patterns, an authorisation step being skipped, a fee schedule loaded wrong — these surface first as a repeated denial, and the follow-up team is usually the only part of the organisation that sees the repetition.
That signal often goes nowhere, because the follow-up team's job is defined as resolving the claim in front of it and the report it produces is about collections. A monthly list of the reason codes that grew, sent to whoever owns intake, costs almost nothing and is the cheapest denial prevention available.
Resolving a denial gets one claim paid. Noticing that you have resolved it forty times gets the next forty prevented.