Denial Root Cause Analysis: Fixing Denials at the Source

A denial root cause analysis groups a period's claim denials by reason code, traces each group back to the upstream step that produced the error, such as registration, authorization or coding, and fixes that step so the same denial stops recurring. Appeals recover individual claims; the analysis stops the next hundred from being denied for the same cause.

What are the most common claim denial reasons?

The most common claim denial reasons fall into a handful of categories: missing authorization, missing or wrong claim information, eligibility problems, medical necessity, coding conflicts, duplicates, timely filing and coordination of benefits. Which category leads differs by practice, payer and specialty, so your own remittance data is the only reliable ranking.

Each category maps to codes the payer prints on the remittance. Claim adjustment reason codes (CARCs) are the standard set; the X12 Claim Adjustment Reason Codes list says they "describe why a claim or service line was paid differently than it was billed." A denial root cause analysis starts by sorting denials into these categories using those codes.

This post does not rank these categories for the industry, because no ranking here would come from your data. The worked example in the next section uses 100 fictional denials to show the method.

Grouping denials for root cause analysis

Grouping denials for root cause analysis means sorting a set period's denials by reason category, then splitting each category by payer, provider, location and the workflow step that owns it. The first cut shows which problems are biggest. The later cuts show where each one comes from.

Start with a fixed window, such as one quarter of remittances, and pull every denied line with its group code, reason code, remark code, payer, rendering provider, location and date of service. Count denied lines or denied dollars, and use the same unit throughout. Then sort the categories from largest to smallest and add a cumulative percentage. That ordering is a Pareto table: it shows how few categories account for most of the denials.

A worked example: 100 sample denials

The table below is entirely fictional. It shows 100 denied lines from an invented multi-provider clinic over one quarter. The counts are made up to show the method, not to describe real denial patterns.

In this example the top three categories account for 58 of the 100 denials. That is where the analysis spends its effort first.

The second cut splits each top category. In the fictional clinic, suppose 17 of the 24 authorization denials came from one payer and one imaging order type, and 14 of the 19 information denials had a missing or mistyped subscriber ID. Those splits turn a category into a specific, fixable problem.

Moving denials into work queues by code is a separate job from analyzing them. The post on denial intake, reason codes and routing covers that queue design.

Tracing each denial to the step that caused it

Tracing each denial to the step that caused it means following a denied line backwards from the remittance, through billing, coding, the visit and scheduling, until you find the first point where the wrong or missing value entered. The reason code names the symptom. The trace names the step, the person and the field.

Take a sample of claims from each top category, ten or so, and walk each one back. Ask the same questions every time. What value did the payer object to? Where on the claim did that value come from? Who entered it, and from what source document? Was the right value available at that moment?

For the fictional clinic, the traces for the top three categories led to these upstream fixes:

1. Authorization absent (24 denials). The traces showed that schedulers booked imaging for one payer without checking whether it required prior authorization, and that two approved authorizations were never entered on the claim. The fix: an authorization check at scheduling for the order types that payer lists, and a required authorization number field on those orders before the claim can go out.
2. Missing or wrong information (19 denials). Most traced back to subscriber IDs keyed from photocopied insurance cards at registration, with letters and digits confused. The fix: capture the card image at intake, have a second person or a review step confirm the ID against the image, and re-verify when the patient reports a new plan.
3. Eligibility (15 denials). The traces found patients whose coverage had ended between booking and the visit, and returning patients whose plan was never re-checked. The fix: run an eligibility check close to the visit date and at every visit, not only at first registration.

Several of these causes start at the front desk. The patient intake category collects the posts on intake forms and registration data, including how demographic and insurance fields go wrong.

A trace sometimes ends in a surprise. A line denied for missing information may turn out to have been correct on the clinic's side and dropped by a clearinghouse edit. That is still a root cause, and it gets a fix of its own.

Appeals still have a place after the trace. Claims already denied for a reason the trace shows was the payer's error, or that the record can answer, go to appeal. The medical appeal letter sample shows how to write one that answers the specific denial reason.

How do you prove a denial fix worked?

You prove a denial fix worked by measuring the denial rate for the targeted category before and after the change, over windows of equal length with a similar claim mix, and by waiting long enough for the after-period claims to be adjudicated. A drop in that one category, with other categories steady, is the evidence.

Define the measure before you change anything. A denial rate is denied claims divided by claims submitted in the same period, and you can compute it overall, by category and by payer. Pick the category rate that matches the fix: for the authorization fix, that is authorization denials per claim for the affected order types and payer.

Three cautions keep the comparison honest.

• Lag. Denials arrive on remittances days or weeks after submission. Count by date of service or submission date, and wait until the after-period claims have mostly been decided before you compare.
• Mix. A new payer contract, a new provider or a seasonal change in visit types can move the rate on its own. Compare the same payers and order types in both windows.
• Displacement. A fix can move denials rather than remove them. If authorization denials fall but medical necessity denials on the same orders rise, the problem moved.

In the fictional clinic, suppose authorization denials for the targeted payer fell from 17 in the quarter before the change to 3 in the quarter after, on a similar number of imaging claims. That is the shape of evidence to look for. A real result would need your own data.

Tracking the overall denial rate alongside other revenue cycle measures is the subject of RCM KPI dashboard metrics and their formulas, which defines each metric.

If the fix depends on intake data entered correctly, the data entry step itself is worth checking. Schema Care reads patient intake forms and EOBs into fields, scores each one, and holds the fields under your threshold for a reviewer to confirm against the original page, as shown on the human review section.

Denial root causes outside your control

Some denial root causes sit outside your process: the payer's coverage rule, the patient's benefit plan, a retroactive change in coverage or a payer processing error. A denial root cause analysis should label these separately, because the response is an appeal, a policy check or a patient conversation rather than a workflow change.

The X12 list has codes for several of these. Code 204 says "This service/equipment/drug is not covered under the patient's current benefit plan." Code 27 covers expenses incurred after coverage terminated, which can happen when a plan ends coverage retroactively after the visit. Code 109 says the claim is "not covered by this payer/contractor" and must go to the correct payer. Each points to the payer's or plan's rules, not to an error by your staff.

Even then, the analysis can find something to fix. A benefit exclusion that shows up repeatedly for one plan may call for a benefits check before scheduling that service. A retroactive termination cannot be prevented, but a pattern of them for one employer group is worth knowing before the next visit. A code 109 denial may show that registration recorded the wrong primary payer.

Payer errors are their own group. When a trace shows the claim was correct and the payer misapplied its own rule, the fix is an appeal, and the trend is evidence for a conversation with the payer's provider representative. For Medicare claims, the appeal route and forms are laid out in the guide to the Medicare appeals form at each level.

Medicare also separates small errors from appeals. The Medicare Claims Processing Manual, chapter 29, says minor errors or omissions in an initial determination may be corrected only through the contractor's reopening process, and that appeal requests involving them are treated as reopenings. In a root cause table, those denials belong with the internal errors that caused them, not with the payer's.

Keep the outside-your-control share visible on its own line. If it grows, the cause may be a payer policy change that needs a front-end response, such as a new authorization requirement, rather than more appeals.