Time Capsule: The Best Time to Build a Data Warehouse Was 20 Years Ago: Why Someone Should Create a Standard Clinical Data Warehouse for Providers to Populate
I wrote weekly editorials for a boutique industry newsletter for several years, anxious for both audience and income. I learned a lot about coming up with ideas for the weekly grind, trying to be simultaneously opinionated and entertaining in a few hundred words, and not sleeping much because I was working all the time. They’re fun to read as a look back at what was important then (and often still important now).
I wrote this piece in October 2009.
The Best Time to Build a Data Warehouse Was 20 Years Ago: Why Someone Should Create a Standard Clinical Data Warehouse for Providers to Populate
By Mr. HIStalk
No matter what you do, it’s never enough. We healthcare IT geniuses have advanced the industry all the way into the early 1990s with our proprietary software applications, portals, and wireless infrastructure. Job well done, right?
Now all of a sudden, nobody’s happy with just capturing data electronically. They actually want to use that information for other stuff, moving the finish line right as we’re about to win the race.
All those state-of-the-art MUMPS and COBOL applications aren’t good enough for government work any longer. Automating for efficiency is yesterday’s news. It’s the information we’re capturing that’s important – for getting paid, for improving outcomes, or maybe even for keeping doctors and hospitals out of the red by selling data to those rich drug and device companies who need to conduct medical research or outcomes studies.
My hospital, for example, has a homegrown data warehouse. It’s useful (as it ought to be for what it costs to develop and maintain). It’s still only as good as the systems that feed it, though, and the analysts who work on those feeder systems always have a ton of "yes, but" cautions about the data they can provide, the kind of caveats that egghead data consumers hate to hear.
A common question: what bed was the patient in when a given item was ordered? Our answer: our systems don’t capture that. What’s their weight history? Same answer. Who ordered the treatment? Maybe we know, maybe not (it depends how far you want to go back in our CPOE journey). What time was the surgical incision made? Don’t know. What was the condition for which a drug was ordered? Only your doctor knows for sure.
The bottom line is that the information we have is pretty good, but we’re always running up against useful pieces of data that we don’t have. We can answer questions, but some only with an asterisk.
It is highly satisfying (not to mention enlightening) to be able to assemble complex electronic data elements into a reformatted database that will support some research project. It’s depressing, though, that our vendor systems simply don’t capture everything we need (and that the vendors, at least in our case, have zero interest in providing those capabilities).
My hospital’s IT resources and vendor are certainly average or better. If we have gaps and compromises in our data, I’m sure those are nearly universal (and even worse if you’re talking about physician practice EMRs).
Write this down: if your organization doesn’t already have a rich warehouse of query-capable data, it needs one. It’s a tough, expensive, and technically tedious effort to figure out all the what-ifs with your current transaction processing systems (What happens if you change a drug name? Can you handle merged patient records? How can erroneous information be fixed or deleted?)
It’s worth the effort for two reasons. First, it will help you get paid. Second, you’re sitting on a treasure trove of data that could be anonymized and licensed to big companies that have a lot more money than the average provider, some of which might even use it to conduct patient-benefiting research. Everybody wins.
Academic medical centers have blazed the trail. It’s time for community hospitals and physician practices (and their systems vendors) to follow.
It would be easier if someone would simply design an off-the-shelf data warehouse known to work well for clinical and population-based inquiries, and then simply give the input specs to the provider and their vendors. That’s great for interoperability. Maybe more importantly, it’s a clear target for providers to shoot for.
I know it’s annoying that everybody’s suddenly pontificating on the importance and economic value of encounter data. Trouble is, they’re right.