This article was initially available on our podcast. Click here to listen.
This is a follow-up podcast concerning OpenPM, a product by Open Practice Solutions. In a previous podcast, we discussed an issue with essentially remittance information getting smushed together. That means that if you would typically have an adjustment group and code like a CO133 or a CO109 and then a remark code like an N220, what OpenPM does is give you the adjustment group and code and then the remark code. Further, it just smashes some of that together, and you lose some of that information.
In that example I gave (a CO133 and an N220), we would get from OpenPM, in output, in a report, a CON220. So we get the adjustment group, not the adjustment code. Yes, the remark code. Adjustment group – yes, adjustment code – no, remark code – yes but smushed together. We might get a COMA27 like somebody is in a “COMA” 27. Again, that’s missing some information. It’s also a little misleading because it looks like it’s an adjustment group of a CON, but it’s not an adjustment code. It’s a remark code.
Why do we care about that? In the old-school way of billing, it wouldn’t have made any difference. A biller or collector would go into the billing system, go through their work queue, and slog through every individual claim. They would pull up the remittance information. In addition, they would see the adjustment group and code. Also, they would know the remark code. They would see the description in the remittance information within the billing system when they look at that individual claim to work that claim, fix that individual claim, overturn the denial, get it paid, get it written off, or something else.
So that’s the “slogging away at each claim” process, which most billing companies still do. This doesn’t impact that because this is really taking that information in the ERA and smashing it together when you’re outputting a report to aggregate and show you a list of all of those at once.
What analytics is all about
The purpose of analytics is to allow an organization or individual to be more productive and, ultimately, proactive to prevent problems, especially when it comes to denials. You can identify patterns and large aggregate numbers of claims and work them all simultaneously. If there’s a provider enrollment problem, or there’s an EDI problem, or whatever it might be, you can stop slogging through individual claim after claim, after the claim, after a claim. You can work them in one giant block, or you could fix a problem with eligibility at the front desk or whatever it might be to prevent these types of issues.
Those are valuable things, but this requires analytics. And analytics requires that the data be complete and accurate. Otherwise, it will be misleading or cause some types of problems. That means if we’re missing adjustment codes, which is often the top level that people use to analyze their denials, there is only a remark code. Then you may get erroneous conclusions. You may miss significant issues because they’re underrepresented, or it’s split up into seemingly a bunch of different buckets when, in fact, they’re all the same problem. That will reduce the efficacy if somebody’s trying to do analytics to solve problems, get claims paid, prevent issues, and so on, as we discussed.
Why OpenPM is better
The net of all this is that OpenPM is way better than most systems regarding reporting. We’re overall very positive about them. They’re better at reporting on denials precisely than most other organizations as well. We’ve talked about other issues other times in the past about how some of that information is stored in a notes field and other things that you have to parse out the information. Still, they tend to be way better than most systems. We would put them in the top quartile at the very least or even higher than that. Still, there are significant holes in their reporting for denials. That means it makes doing analytics a lot more complicated.
The net of that is not “Don’t use OpenPM.” We highly recommend OpenPM. They’re great to work with regarding access to information, customized reports, and things like that. But know that those issues are going on as there may be with any billing system provider you’re going to use or analytic system and create a solution workaround some way to deal with that. What we would suggest is, access all your 835s, parse all of them and drop them into a giant analytics data warehousing or analytic solution, denial management solution to overcome that problem.
It’s still helpful to have good reporting and analytics coming out of OpenPM. It’s good to have them work with you, but you’re not going to be able to do incredible denials analytics. Why? Because even with a lot of the customization they tried to do. That’s our conclusion of OpenPM and its analytics capabilities, especially for denials.