We recently did an episode about measuring productivity in revenue cycle management. This is the follow-up, part 2, relating to some of the suggested solutions.
In the prior episode, we outlined some of the challenges that you may have in measuring. The productivity of different parts of the revenue cycle management process, including front-end, back-end, and so on. Please read that article prior to this one in order to get the maximum benefit. Otherwise, this one out of context and may not make sense.
Suggested Solutions
We recommend that instead of measuring front-end productivity. Like claims per hour entered or submitted. Claims per day, or the number of claim lines per hour and per day or similar front-end metrics. We suggest measuring the back-end productivity in order to measure the front end. Let’s say for example that you did patient registration. If that patient registration was done correctly, then that claim gets paid. Net of mistakes by measuring the back end.
This also helps distinguish between the problems of minor errors and major errors. If somebody fat-fingers a name, with some payers. That may not be a problem and the claim will still get paid. If they fat-finger a patient ID and it doesn’t get paid, this is obviously much more important. It essentially filters out that problem and distinguishes between errors that don’t matter and ones that do. It also solves the problem of measuring multiple errors in one patient (like incorrect name and patient ID), since we only care about the claim is correct, not whether there were one or many errors that resulted in non-payment.
Following is an example of how this might be calculated. Let’s say medical biller A enters 100 claims. In an hour and only 50 are successful in getting paid. While medical biller B gets 80 paid. In order to do this analysis, one needs to have outstanding data and the ability to analyze it. That also includes likely having a different type of data collection.
Was the claim paid?
It is important to be able to identify whether or not the claim. Was paid or not paid due to a particular part of the revenue cycle management process. In other words. Did the insurance company just deny it for no good reason (or was intentionally obstructing the claim process), or was the patient registration process flawed? You may need to change how you enter and collect claims and denials data. This means you need to be able to find not just the denial code or was the claim missing (no claim on file), but you will need to get to the root cause of why the claim wasn’t paid.
This relates to one of the subjects of another podcast we’ve done, which is secondary-level (root) causes of claims denials. To claim resubmission or an appeal. In other words, “Was it appealed?”, was there some particular document that got submitted? Additional documentation like patient records submitted? Was it the patient ID that changed, and so on?
To identify what changed, you may not be able to extract all of that information cleanly out of your billing system. Most of them can’t do that level of analysis because they overwrite. In other words, when you change the patient ID the system no longer keeps. The first patient ID you put in there unless you add new insurance (like a case) that keeps both records in case you need to bill them contemporaneously. Or even if it does have the ability to track that kind of state-level change somehow, it may only do that in certain parts of the system. Like old insurance that termed as opposed.
Data warehousing to determine cause
That means you may need to have data warehousing. Where the sort of instantaneous level data is pulled out of the system. Then, anytime, either at specific points of time or where there’s some change. In the record, it pulls out an additional record. And keeps those statuses along the way so that you can see changes of state.
Now, we’re switching gears a little bit there in terms of quantifying the productivity of collectors. If you have sort of one-stop-shop billing where one person does all the functions. It becomes a little more complicated than, potentially, if you have separate teams. Even within collectors where one team does appeals, one team does status checking, and so on. It’s almost impossible to completely do that kind of thing because if somebody is working a claim, as a collector, trying to follow up and submit an appeal and stuff like that, as they’re in that process.
They may have to find out, “Oh, this claim is not payable!” and write it off. Therefore, you can’t fully have just sort of an independent write-off team or folks. That do appeals and don’t do write-offs, and so on. You can’t wholly silo them. You need to be able to identify different parts and different functions and quantify those separately.
QA, of course, really matters because, as a collector, you don’t care about the number of touches. You want to distinguish between how many claims got work and how many claims got paid.
We have seen some organizations do even dollar weighting of payments because; let’s say, for example, you have surgery and an E&M. The surgery, obviously, is a lot more dollars. Then the E&M, so you don’t want to weight those equally where somebody. Those are radically different in terms of the impact on the practice.
Also, not just in terms of the dollar impact but also of the workload because it is likely that the larger dollar claims are more work.
When do you get write-offs?
One of the challenges you may run into is you have to give some credit for write-offs. You don’t want to give credit for getting payments because, otherwise, people will never do write-offs.
We’ve been through that process where we tried. To create incentive systems and track all of this. We found initially that nobody would do write-offs because they are not getting credit for it. Then, we implemented a process where you get credit for the write-off, and then people only wanted to do write-offs rather than getting claims paid. Though they weren’t weighted as heavily, you could do like 1,000 of them simultaneously so like an appeal.
Also, we found weird, goofy games where somebody could do mass write-offs. They found some problems with a particular payer. Because they don’t pay off this diagnosis code, or this provider is in a role or whatever it may be.” Then, they just wrote off 500 in bulk. You got to be able to track, “Are they doing a one-off or are they doing a sort of en masse?” because that’s a whole different level of work. That’s critical to be able to know and understand how the system works and track those separately.
We do measure for a lot of clients whether appeals get paid. That’s essentially one way to know if the work was successful, but that’s doing appeals themselves. There are other parts of the collection process in terms of following-up and solving problems that you want to make sure your track
Again, the key to all this is good data, sound analysis, useful analytical tools, sort of ways to extract and get data and analyze data, and so on.
Filing Deadlines
There also needs to be some effort to make sure that you don’t miss timely filing limits, especially for the small-dollar claims. Again, it depends on how you set up your structure. But that may be a front-end function or a back-end function where if they’ve been entered. And they need to be submitted. To a different payer or resubmitted, or something like that, to log that record, so it doesn’t hit a timely filing limit.
To the appropriate department and then quantify those. And you need to have those measured separately because there are different levels of work potentially than just doing a standard patient registration because patient registration, you may be just looking up information off of the system, or you may have auto-imported or whatever the case may be. Whereas if you need to do something like contact the referring provider. Then just enter it directly from the insurance card.
Data to measure productivity
One of the challenges we’ve also seen is that many systems aren’t good at putting data. Into a format or a way for you to analyze productivity quickly. Some systems have productivity measures in there. You may be able to use them, like how many they do per hour, but again, that doesn’t handle all these sorts of complex scenarios that we’ve talked about and some productivity adjusted for quality.
Even more importantly, many systems will have collector data. As a note field where you may not see separate transactions, where they called. Instead, in one note field, perhaps that is text, you might see something like “314, contacted payer, claims not on file, resubmitted,” 430, “contacted payer, found out contract has elapsed,” or they received it. They’re asking for additional documentation, or there’s some record from May or June after that.
You have a giant text jumble that has to be parsed out and separated to say, “Okay, with this format. We can then identify if the claim was work six times.” Working in combination with extracting that information. These many different times on these many different days,” in combination with when the payment record then came in and tying the payment to the previous work done presumably before that.
Payment analysis
Although again, there’s some nuance to that, where we found situations where somebody would go in and work something. That couldn’t have resulted in payments because the payment can’t get sent in 24 hours. Effectively, you got to watch out for the situations where it seems like somebody worked.
Those are our tips in terms of how to analyze productivity. Again, you can export a lot of this data and analyze it separately, even if your system cannot do this. We’ve never seen a billing system was capable of doing these types of analyses. Data warehousing means exporting data, massaging it in Excel, cleaning data, and so on. Those are all for separate episodes.
Hopefully, that helped measure productivity for revenue cycle management teams, again, whether that’s in-house billing or an external billing company.
Recent Comments