This article was initially available on our podcast. Click here to listen.
Where you get your data from does make a big difference. Suppose I look at the progression of how we accessed data from our clients. In that case, we’d initially had the idea that we could go into the billing system, whether it’s a practice management system, EMR, or laboratory information system. If it were a system that had good reporting or analytics capability, we would be able to take information from that system. We could also parse that data, analyze it, do data warehousing, and more. Moreover, even combine it with some input from other sources so that we could run those analytics for our clients.
Reporting systems
In the early instances that we set up, we did that for those systems that had, for example, denials information available within their reporting. I can think of a couple of examples are systems like AdvancedMD and OpenPM (also known as Open Practice Solutions). When you access the reporting, those systems have denials information, denial codes, and more located somewhere within their system, whether or not it is broken out separately or whether or not it’s embedded in the note field.
These are all separate issues of “How do you extract that information? How do you parse that information out?” But the information was available in reports. We extracted that information from those systems, cleaned it up, parsed it, did all of the stuff we had to do, and then ran the analytics for our clients.
Remittance data
The problem with pulling data out of a system like that (not charges data, but remittance information effectively, and this is the crucial difference) is denials are part of remittance information. Overall, when you look at remittance information, most billing systems.
I’m generalizing because, again, I’ll call anything that includes billing information (radiology information, laboratory, EMR, billing system, practice management system) billing systems. After all, they contain the billing information.
Even if they have a separate “analytics module” or a separate reporting tool, whatever it might be, when we get that data out, it’s not just that it is ugly and messy and complicated to clean up that data, parse that data, and get the information out of it. That is the case. It’s also a lot more work to set that up for each system because doing that for a thousand different billing systems is much more complicated than doing it for the 835s because 835s is a standard format.
That’s not even what I’m talking about. There’s a separate issue not just in terms of the work of the economies of scale. It’s also about setting those up. In addition, purely in terms of the data we get and what we can do to analyze that.
Data retrieval
Suppose we’re getting this ugly information out, and we’re cleaning it up through an ETL tool. In that case, essentially, we’re going through and running it through a series of steps. For instance, that are automated. Further, once you build that infrastructure that says, “When there’s this information, split this, add this, change this to this, combine this with this, join it with this,” and more.
Slice and dice
You might be doing all that work in the ETL instead of in the analytics tool, call it the presentation layer, whether it’s Power BI, Sisense, or Tableau. If you do it in the ETL rather than in the reporting, you don’t have the same ability to slice and dice things. You might want to do change and essentially not just be reporting but be analytics. I think that’s the critical difference between reporting and analytics.
Reporting just presents some information. Analysis means you’re not just drilling down and slicing and dicing. Still, you’re navigating through things and looking at things with different lenses and in other ways so that you can identify and, ideally, solve problems.
The only way to do that is frequently if the discrete data all reside effectively. Use just in the raw data format, in the BI tool. Then, you can slice and dice in any way that you want to to be able to do this.
We’re seeing that now between the folks that we landed a year ago for our denials management tool versus those that have gone live in the last month or two. There’s a radical difference in the ability to drill down and slice and dice. Why? Because of how the data has been processed.
Check the fields
The key difference there is we’ve got to the point where we now only take 835 data to get that because there is so much more information located within that 835. There are a lot more fields. It’s separated. It’s not only standardized, but we can process it quickly and easily. It also means that we’re not doing all of the analytics in the ETL tool and loading those reports into BI, but we’re doing all of the analysis in the BI tool instead. That means that people are more effective at identifying and solving problems when presented that way and when they can slice and dice directly in the BI tool.
I know this is detailed. I’m hoping that that was sufficiently explanatory to help guide you in what you do on your path of what’s going to work better for doing analysis. Excuse me! I’m still recovering from COVID, by the way. Sneezes aren’t symptoms, but the cough is.
To summarize
If you have any questions, please feel free to get in touch with us. We’re happy to help guide people on their path. Even if you’re slogging away at something and you’re stuck, don’t hesitate to get in touch with us. Let us know. We’re happy to help. We want to share the love.
