Everything I Ever Really Needed to Know about Healthcare Data I learned the Hard Way

I started my career as an analyst for Indiana Medicaid. We had no data. We had a file cabinet full of reports on microfiche, but that did not become data until I compiled it into a useful format. Having spent half my career as a Medicaid employee in charge of data analysis and the other half working for or with decision support vendors, I’ve particpated in a lot of implementations from both sides of the table. Here are some of the lessons I’ve learned:

1. Getting the right information to the right people at the right time is all that matters. Ultimately, the decision support system and data warehouse only exist to help manage the healthcare system. RFPs and proposals focus on delivering a certain number of reports in a certain way. This helps the bidders propose prices that are comparable. It does not help the client get value. I’ve spent months with clients making sure they get their 50 reports. They want me to create 70 reports, then let them pick the best 50. Instead, we should both be focusing on meeting their needs. Can they find fraud, monitor the budget, maintain access to care, improve quality and evaluate policy changes? If not, we’ve failed, whether they have 50 reports or 2,000.

2. One size does not fit all and nobody likes to admit what size they really wear. I’ve never worked with a system that would work for all types of users. One system interface often doesn’t even work very well for two people with the same job description working right next to each other. Different people have different skills and interests. Most staff who need data use the data in the same way again and again. They need a simple interface that allows them to quickly pull together this information. However, somebody who wants to be able to quickly write a program that can get them any information they want will not be happy with an graphical interface that makes them pick from a limited number of functions. Both types of users are important.

In The Inmates are Running the Asylum Alan Cooper says that the key to good design is designing for one prototypical user, making sure that your software perfectly meets the needs of one kind of user, rather than meeting half the needs of most of the users. Too often we fail to heed his advice. By trying to please all users with one interface, we fail to meet anyone’s needs completely. Everyone is frustrated. The super-geek is frustrated by the system limitations and having to push buttons rather than write queries. The casual user is frustrated by too much functionality that they don’t adequately understand. Their learning curve becomes too great, and they give up.
We need different interfaces for different people, but we often also need different data models for different people and for different uses. Some users just need instant access (10 seconds) to summary data, while others need fast access (10 minutes) to a wide range of detailed data using complex queries.

3. Everyone has to be on the same team. Trust is the most important element to a good implementation. This requires complete honesty, informing the client immediately of any problem and working together to solve all problems. When the client and vendor don’t trust each other, every decision becomes a battle. Each side fights to hold their ground, without thinking about what is best for the project.

4. Getting good source data is harder than the hardest thing I can imagine. Here’s where the biggest delay happens. The first time the data warehouse vendor asks for the legacy data, it arrives weeks late and is nothing like the data feed that was specified. If anyone has ever gotten correct data the first try, please let me know—I’ve never seen it happen. Eventually, the data warehouse vendor gets the legacy data in the correct format and starts processing it. At which point, you find out the format is correct, but the data is still junk. The next tape or feed isn’t in the right format again. You finally get the data into the warehouse, only to find out that the billing provider is missing 90% of the time, because the billing provider was sent in the performing provider field, and the performing provider is only entered when it is different from the billing provider. This whole process seems to take a year longer than anyone ever expects.

5. Delays compound. The delays start before the RFP ever hits the streets. For one reason or another, the RFP is issued later than originally intended. As a result, states often decide to reduce the time vendors have to reply to the RFP. They do not change the planned implementation date, even though the RFP is late. Once a vendor is chosen, the contract process takes forever. By the time the contract is in place, the project is already behind schedule.

I usually work on preparing the reports that clients will use on a regular basis. This step necessarily comes at the end of the process, after the data model has been finalized and there is real data to work with. Once the data has all been tested and we’ve decided what reports the client wants, it usually only takes me a few weeks to create all the content. Unfortunately, to save time, we usually start the process too early. In the end, this takes more time, because the data isn’t really ready. Reports have to be reworked every time the data model is changed.