Sorting Denials by Where They Were Born, Not by Code

Sorting denials by code tells you what the payer objected to. Sorting them by where they were created tells you what to do differently. Only the second question has an action attached to it.

The report everyone already runs

Most practice management systems will produce a denial report grouped by reason code without much persuasion, and that report is where denial conversations usually begin and end. It is genuinely useful for one thing, which is knowing what the payer said. It is close to useless for the thing people actually want from it, which is knowing what to change on Monday.

The gap is that a reason code describes the payer's decision, not the practice's behaviour. Two claims can carry the same code and have gone wrong in completely different places, for reasons that live in different departments and require different fixes.

Asking a different question of the same data

The exercise that changed how I look at this is straightforward and does not need new software. Pull a month of denials, and instead of grouping them, go through them one at a time asking a single question: at what moment did this denial become inevitable?

It is slower than reading a summary report, and the first time through it is tedious. What comes out of it is a list of moments rather than a list of codes, and moments have owners.

What the categories tend to be

The moments cluster in a small number of places. Some denials were decided when the appointment was booked, because the plan selected at scheduling was not the plan the patient actually had. Some were decided when a payer changed an authorization requirement and that change reached a billing inbox rather than the people who schedule and order.

Some were decided in the exam room, where the documentation and the code describe slightly different visits. Some were decided by an internal queue nobody owned, which is how a claim reaches a filing deadline without anyone deciding to let it. A genuine share are errors made in billing, and that share is usually smaller than the meeting assumes.

Why this reframes the meeting

When denials are up, the conversation tends to turn toward the billing team, because that is the department the denials arrive in. If most of them were created upstream, then asking billing to fix denials is asking a team to correct decisions that were made before they saw the claim. They can appeal, and they should, but appeals are rework, and rework has a cost that never appears as a line on the P&L.

Sorting by origin moves the conversation to where the decision actually happened. It also tends to lower the temperature, because it stops looking like a performance problem in one department and starts looking like a process that hands off badly.

Making it a routine rather than a project

The practices I have seen get traction on this do not run a denials initiative. They run a short, dull, recurring review: the top few origin categories by dollars, each one attached to the process where it was created, with one change and a date against it.

One caution worth stating. This only works if surfacing a problem is safe. The first time a review turns into blame for the department that reported an error, reporting stops, and what you are left with is a report that looks better every month while nothing underneath it has changed.

What the exercise does not do

Sorting by origin tells you where to look. It does not tell you what the fix is, and it can create a false impression that every category has one. Some of what surfaces is a process the practice controls and could change this month. Some of it is payer behaviour, a rule that shifted with little notice, and the honest response there is a faster way of hearing about changes rather than a corrective action.

Separating those two early is worth the effort, because a list that mixes them produces a meeting where the fixable items get the same treatment as the ones nobody in the room can affect, and everyone leaves with the impression that the whole subject is weather.