We were recently working with a client where we needed to gather data from many different places, one of which was a clearinghouse. But why do we need data from a clearinghouse? Why can’t we get it from a practice management system, billing system, or EHR? Well, most billing systems, regardless of the brand, typically aren’t very good at providing data, whether through APIs, reporting, or other means. In particular, they tend to be poor at giving denials information. Denials can reside within 835 files, also known as ERAs (Electronic Remittance Advice), and most of these systems don’t make it easy to extract these structured data files, the ANSI X12 and EDI files, from their systems.
The Benefits of Using a Clearinghouse
It’s often easier to go to the clearinghouse to get that information, then match it up with what’s in the billing system. This allows you to have complete revenue cycle management, practice analytics, denials management, and other capabilities in one place. The specific clearinghouse doesn’t matter—whether it’s Availity, Waystar, or another provider—the point is that none of them are particularly better or worse.
Issues with Data Transfer and Accuracy
In this case, we were working with a clearinghouse to get daily batches of 837s and 835s. Focusing on the 835s for a moment, they gave us a huge historical dump of thousands of these files. We parsed all those files, processed them, joined them to other charge and payment records, and loaded all that information into an analytics system.
When we conducted QA, we discovered that a lot of information was missing, meaning it was clear they hadn’t given us all the 835s they had. We went back to them and said, “Hey, this isn’t all of them.” They insisted that it was, but we knew it wasn’t. We provided some sample 835s where we knew those records existed because we could see them in their system. When we looked for individual records, we found those 835s in their system via their portal, but they had not provided them to us through the secure FTP.
The Endless Cycle of Miscommunication
After presenting these examples, they finally admitted, “Ah, whoops, those aren’t in there.” We asked them to give us the rest, but they claimed that only those couple of records were missing. There’s no way we randomly found just a few missing ones—we knew that wasn’t right. We went back, found more missing files, and sent them more examples. They continued to insist it wasn’t a systemic problem, and that they had given us everything. This back-and-forth went on forever.
Eventually, we got fed up and told them, “You have no idea what you’re doing. You don’t even know how to get information out of your own system. We’re going to take it out of your system directly because you can’t figure out how to do it and provide it to us.” So we did, and this happened some time ago. Once we did that, we could replicate the process in the future.
The Lesson Learned
This is a consistent problem we run into with systems. The system vendor often has no idea what they’re doing and lacks the capability—or even the understanding—of how to extract and provide information from their own system to the provider or revenue cycle management company.
So, what’s the moral of the story? It’s not about any particular technology solution. The takeaway is that you shouldn’t trust the information a system vendor or service provider generates. Unfortunately, the old quote from Ronald Reagan, “Trust but verify,” doesn’t apply here. You should definitely not trust data without verifying it yourself. Go to the original source data, extract it, and then use that to build or construct analytics, reports, or whatever else you need to run your business effectively. But sadly, you cannot trust and verify, because almost always, verification will show that you shouldn’t have trusted them in the first place.
