Coding Doesn’t End When the Claim Is Submitted

For a long time, coding has been treated like a stop on the revenue cycle assembly line. Review the documentation, assign the codes, get the claim out the door and move on to the next one. That may keep work moving, but it misses a much bigger opportunity.

Coders occupy an important intersection between what happened clinically and what ultimately gets paid. Their decisions influence clean claims, denials, A/R, cash flow and revenue capture. When coders can see what happens to their work after a claim leaves their hands, they also gain something incredibly valuable: the ability to learn from what happens downstream and make the next claim better.

That is how coding should work. Coders shouldn’t simply complete their piece and hand the claim off to someone else. They should understand the work across the lifecycle, from abstract coding and edits through coding-related denials and the lessons those denials provide. 

Silos break the feedback loop

In many organizations, that isn’t how coding is structured. Production coders code. Edit teams work edits. Denial teams handle denials. Each group may be doing its job well, but the handoffs can create a blind spot: the person making the original coding decision may never see what happened to the claim afterward. That matters because denials give you important information.

They can show where documentation needs attention, where payer behavior is changing and where a coding decision that looked perfectly reasonable on the front end created an issue downstream. If that information never makes its way back to the coder, the organization may fix the denial without fixing what caused it.

Meghan McKee, Revology’s Director of Coding Services, describes the value of closing that loop this way:

“Coders can learn a lot from denials, particularly when they point to coding errors or payer requirements that could have been addressed upfront. For example, a denial for a missing laterality modifier can help coders recognize when that modifier needs to be added proactively. The same goes for medical necessity denials, where reviewing LCD and NCD requirements can help ensure the appropriate diagnosis codes are included and supported by the medical record. The goal is to use what we learn from denials to improve coding accuracy on the front end and prevent avoidable denials down the road.” 

That’s the difference between working a denial and learning from it. When there is a structured feedback loop between denial management and coding, what happens on the back end can inform behavior on the front end. Over time, that can mean fewer repeat issues, stronger coding practices and less revenue getting hung up for avoidable reasons.

Coding performance is revenue cycle performance

It’s easy to measure coding as a production function. How many charts were coded? How quickly? How big is the backlog? Those things don’t tell the whole story.

A strong coding operation should also be asking what happens after the work leaves coding. 

• Are coding-related denials increasing? 
• Are the same issues showing up repeatedly? 
• Are unbilled accounts sitting because coding work isn’t moving? 
• Are there revenue opportunities being missed?

Revology worked with one client to implement a coding center of excellence, establish coder goals, provide additional education and improve processes. As a result, unbilled pending coding dropped by more than 70%. Actionable coding-related denials decreased by 27%, while improvements in coding performance and additional revenue identification contributed to stronger year-over-year cash performance.

That’s a great example of why coding shouldn’t be evaluated in isolation. What happens there has consequences throughout the revenue cycle.

Follow the claim

Coding shouldn’t operate in a vacuum, and coders shouldn’t lose sight of a claim the moment it moves to the next work queue. Give them visibility into what happened. Let them see the denials. Use that information to find root causes and adjust upstream behavior. Then use technology to make that entire process faster and more focused, without assuming technology can replace the people who understand what the data is actually telling you.

Because whether the initial code comes from a person, an autonomous coding platform or some combination of the two, the job isn’t finished when the claim is submitted. Coding doesn’t end when the claim goes out the door. What happens next is part of the job, too.