This article is initially available on our podcast. Click here to listen.

We are continuing on the path of just trying to get a denials to report to analyze and figure out what’s going on with a particular healthcare provider. The goal is to figure out what the top problems are, why things aren’t getting paid so that we can analyze and figure out what we can do to solve them, and then, of course, track that improvement over time.

Retrieving denial data

We’ve been looking at, “How do we get denial information, particularly denial codes, rejection codes, things like that?” These are the CARCs and RARCs if we go with those types of codes. Following up on yesterday, it’s just one more step in the giant path to get us to the point where we could analyze data. So this is all still data prep, exporting data, trying to get the data.

It’s funny. I’ve given lots of presentations at conferences about how to analyze financial data in healthcare, and I frequently said, “Half the battle is just getting usable data.” The more time I spend in this business, the more I realize it might even be the majority of the challenge. 

Think of how many indigent systems there are out there where somebody says, “I can’t even get the data that I want.” At this stage, virtually everybody can do pivot tables and some analysis, even fundamental calculations in Excel. The problem is getting the data that they want, so that’s ultimately a lot of the trick.

What about remittance codes?

As we’ve been diving in now to this particular denials report, I think, as I’ve mentioned in the prior post. I haven’t shared this part of it. The remittance codes are buried. So there isn’t a column that says “Remittance Code” and then 119 or 45, or 38, or whatever the number might be. There’s a notes field, and this is a text field that includes dozens to hundreds of characters, sometimes dozens of words, that frequently starts with something like a CO119, or a CO-119, or just a 119. 

There are carets and special characters and slashes. There are descriptions in there and a lot of them. Sometimes, there’s a number and not a description. Perhaps, there’s a description and not a number. Yet, they’re all jumbled together in a giant mess. The numbers can be at the beginning. They can also be in the middle. Further, they can be at the end.

Manual processing is out

Historically, what people have had to do is slog away at these things one by one. That’s the old style, I think, for billers, which is you get billers who go in and troll away individual claims and say, “Okay, let’s go through the denials report.” They go through one by one and say, “Okay, this one was denied for X reason. Let’s go solve this single problem with this single claim.” We’ve preached for many years that that’s an inefficient and old-school way of doing things.

If you can identify that “Hey, there’s a problem with these 500 claims” rather than going one by one, you can knock down significant problems rather than slogging away at individual ones. To do that, you need a couple of different types of resources within the organization. 

Revisit the numbers

I think this is where many healthcare providers have challenges unless they’re large entities. That means you need to have billers who can go and slog at individual claims, and that’s existed for a long time. But you need to have, what we used to always billing managers and even analysts who can sort of help you slice and dice the numbers and take the data and sort of cut it and say, “Okay, here’s the top three or four reasons, the problems you’re having that are accounting for 30 or 40% of the problems. Tackle these first, and that’ll knock off a couple of thousand claims, as opposed to going one by one.”

Take a step back from the data

I tend to be pretty good at data. But when somebody’s swimming in the data, there’s no way that they’re going to see this kind of pattern. Certainly not billers who are just immersed in it so heavily that they really can’t take a step back and see what’s going on and see that, “Oh, yeah, three days ago, I had two of these problems. The day before, I had one of these. And six days before, I had 18 of these.” There’s no way anybody’s going to see that pattern when they’re wading through all of it. You need to be able to analyze and chunk all that together.

The data structure means that most people cannot do that. Even if you have somebody like an analyst, who can crunch that and do basic pivot tables or even more complex pivot tables for you, if you don’t have the data, there are no hidden notes fields for anybody to do that. It would help if you had something more sophisticated. 

Break it down

So you can’t run an analysis. That’s, I think, really a problem with many people I’ve run into: they can’t do what they want. They can’t export it to Excel and pivot it or even hand it to somebody to do all that kind of stuff. It just becomes a massive nightmare to try to figure anything out.

I think systematically. We’ve seen many providers who kind of throw up their hands and say, “Okay, it’s not possible. We give up” or “It’s not possible with this particular system or this payer or whatever insert X variable.” Without massive years or millions of dollars, something like that, there’s no way we’re going to tackle this very quickly and systematically. Or somebody does a small pilot project, and there are few of them in an extreme case. But again, there’s no systematic way to cover that.

Final thought

Ultimately, what we need is usable data. If systems were designed to focus on our ability to analyze and solve problems, they would be better structured. Since that’s not the case and it doesn’t seem like that’s changing anytime soon, I think we’ve got to focus on “How do we extract useful information out of the systems?” so that we can identify what’s going on and solve the problems. That’s the path that we’re trying to figure out. So pulling, extracting reason codes out of ugly notes fields, free text – we should have that done shortly, and we’ll be back with more.