I’m constantly impressed by how bad the data is in healthcare IT systems. We’re encountering one of these clinix data integrity issues again today, and they seem to pop up all over the place. You could consider these to be metadata issues, but in reality, they are data integrity issues. For example, there are some strange problems in the system Clinix, which is now owned by, I believe, Harris. It’s an older system, but that doesn’t excuse this problem. This isn’t a technology issue—this is something that should be obvious no matter when the system was built.
The Problem with Missing First Submission Dates
There’s no first submission date; there’s only a last filing date. This means you can’t know when you first submitted a claim—you can only know when you most recently submitted it. So, if you submitted a claim, waited a few months, worked on the claim, fixed something, and then resubmitted it 90 days later, it looks like you just submitted the claim. This can be really confusing in various ways. and is a common example of Clinix data integrity issues.
If you’re trying to run accounts receivable (AR) and aging, you would have to do it based on the date of service because you can’t rely on the first submission date—it doesn’t exist. However, if it takes you 30 days to get the data or to enter and submit it, that can create misleading data. For instance, it might look like you submitted the claim just a day ago, but the claim actually looks 31 days old due to these Clinix data integrity issues.
Impact on Workflow and AR Teams
This also impacts workflow for claims and accounts receivable teams. Collectors who work those claims may prioritize based on the date of service, which could be problematic. If they prioritize based on the last submission date, they may not work on something that was recently submitted. However, you still need to know what’s really old and has been outstanding for a long time—you need to track those things. If the AR clock is constantly resetting for benchmarking purposes, it makes you look a lot better than you’re actually performing.
For example, if you keep resubmitting a claim over and over, it might appear as though the claim is only seven days old. That must be nice, right? We thought maybe we just couldn’t find that field in their system or reports because of the poor documentation in the reporting. But apparently, it doesn’t exist. We seem to have gotten confirmation that it doesn’t exist, which is another example of Clinix data integrity issues.
Fundamental Issues with System Design
Now, another really weird thing—before I move on, let me just emphasize that this isn’t a technology issue. This isn’t some newfangled thing. As long as billing has existed, you should know when you first submitted a claim and when you last submitted it. Basic dates like the date of service and check date are fundamental and have nothing to do with technology. I really don’t understand why this problem exists.
Another issue with Clinix
We see all kinds of weird things like this in various systems. We found another strange issue, also related to Clinix. When looking at the last filing date or the most recent billing date, along with other dates like service date or date of service (which, by the way, are sometimes called different things in different parts of the system—that’s another issue altogether), we noticed something odd.
There’s a charge post date, which we would understand to be when you posted the charge—when you entered the charge. The problem is that in Clinix, this date is frequently after the last filing date. Let that sink in for a second. In other words, the claim was entered after it was submitted. I don’t even know how that’s possible.
The Issue of Charge Posting Dates
Even worse, sometimes the charge is entered after it was paid. Time travel again? I mean, this is just incomprehensible. What were the developers thinking when they built these systems? Did nobody ever QA this? How long has the system been around? It seems like forever, and someone should have noticed this by now. A charge posting date being after the last filing date is clearly a problem, but nobody seems to have noticed.
The Broader Issue of System Idiosyncrasies
We find that every single system has these idiosyncrasies—they’re all a mess, just in different ways.
