Data Modeling for Healthcare Business Intelligence

Data modeling horror stories and different pieces of advice heard over the years make it seem that data modeling for healthcare is impossible to do well. Within the last year I have heard two conflicting approaches to modeling healthcare data – from very well-respected data modelers. One piece of advice was to focus on delivering business value, typically in the form of reports. I was told there is no way that you could ever consider every possible relationship or change that can occur in any business. So, model what you know today, and create ”hooks” into your data that allow for flexible changes over time. The second approach was in an article I read recently. The author advised that because healthcare data is so complex and business rules vary so drastically, 100% of the data should be modeled.
 
I always tell people that they are lucky to model 80% of their data because of the dynamic nature of the healthcare industry. A recent example of rapid change: the push for electronic health records (EHRs) and the resultant Meaningful Use requirements in 2009. We all knew change was coming, but the degree and rapidity of change took many of us by surprise.

So, as I consider the topic of data modeling for healthcare, I wonder how these data modeling decisions are being made at healthcare organizations that are tackling this work for the first time.

In this article, I will identify the top 10 things that any healthcare organization should consider as they start a data modeling project. This article will not solve complex data modeling questions, such as resolving many-to-many relationships or slowly changing dimensions, but it will provide a framework for making decisions.

Current State of Data Modeling in Healthcare

First, let’s briefly review the current state of data modeling in healthcare. Most efforts at data modeling fall into three categories.

The first is the organization that attempts to do all data modeling in-house with existing resources. Of course, there are many potential outcomes as a result, but using internal resources is generally a good choice. Data models, when done well, represent the business as the business sees itself. The only people that really understand your business are the people that work for you. However, that doesn’t mean that this category isn’t fraught with risk. Many internal resources may end up doing data modeling not because it’s their expertise, but because that’s how their job evolved. Many people think they can do data modeling because they understand the data and data relationships. But, there is a bit more to modeling data for broad usage. Not understanding the implications can have a wide-reaching effect, as discussed later in the article.

The second category that many organizations fall under is the hopeful but challenging option of buying a data model. There are a number of options to do this, and on the surface it seems like a reasonable choice. Maybe you make the choice because you recognize that your staff doesn’t have the skills required to do data modeling. You reach out to the vendors that have created these models based on participation from multiple healthcare organizations. After all, 60% to 75% of the work that we do in healthcare is repeatable, right? True, we all deal with patients, encounters, diagnosis, admissions, etc. But, when I started in healthcare more than a decade ago, someone said to me, “Remember, if you’ve seen one health plan, you’ve seen one health plan,” and health plans (payers) have the easier side of the data modeling coin. How do vendors standardize when we all use different codes and definitions? Most organizations can’t agree on how to define a patient, an admission, or LOS internally, let alone outside of the organization. Adding complexity is the fact that we have customized our EHRs to work for us, creating specific terms, codes and dates that aren’t standardized against any other entity. At the end of the day, the planned 25% to 40% customization of these products is usually much higher than you anticipate. Particularly challenging in this scenario is if you are waiting for the vendor to make the changes that will make the product usable for you. You will have to get in line behind every other client they have. These restrictions aren’t all bad – just know that customizations will be more than you anticipate and make sure that you have the ability to make those customizations in house and not have to stand in line.

Finally, there are the organizations that hire consultants to do their data modeling. This happens less than you might think, primarily because it is often very difficult to make the case to senior managers about why it is necessary to spend money on a highly experienced (and therefore expensive) data modeler.

Well, remember when I said, “Not understanding the implications can have a wide-reaching effect?” I became a fan of data modelers in 2000. Back then I was working at a healthcare organization that had decided to extend its healthcare offering beyond its core business model. Without getting into too much detail, the business focused a great deal on training staff but very little time in the back-office operations of reporting the data (sound familiar?). Unfortunately, one of the primary deliverables of this product was the reports back to the clients and the FDA. I was responsible for all the reporting and analytics for this product line. My phone rang at 11:00 p.m.; the analyst (not a data modeler by training or experience) missed a join. It seemed so innocuous, yet that missed join meant that we were not reporting critical, potentially life-threatening incidents to the FDA. After countless days without sleep, a series of rather uncomfortable meetings, I was told that we were going to get sued by our clients and audited by the FDA. I spent the next few weeks behind a closed door with our corporate attorneys. All of my documentation was officially labeled and sealed. All of this was blamed exclusively on a data model that didn’t really exist. Our data model supported our primary business, not the new extension. When we asked leadership for time and support to be able to report this data, they told us that they already sold it and we didn’t have time for a big data project. Had we done any due diligence, we wouldn’t have found ourselves being interviewed by lawyers.

Top Ten Things to Consider as You Take On a Healthcare Data Model

1. Train the Trainer
   
   If you decide to do this work in house, make sure that your staff is properly trained. Don’t just rely on their “smarts” or knowledge of your data. That’s important and critical, but you can’t expect the best result without giving your staff the right tools, and in this case, it’s training.
   
   
2. It’s Logical
   
   If you do some research in data modeling, you will likely read a lot about the importance, or irrelevance, of a logical model. Many agile teams won’t spend time documenting a traditional logical model because they would rather focus time on delivering, not writing. My advice is this: If you have never modeled your data before, presenting your data in a logical model to your business partners can help validate your model and even catch wrong assumptions. Don’t take the time to update documentation for documentation’s sake, but when so much is relying on this foundation, take the time to get it right.
   
   
3. Do Some Research!
   
   Maybe you have decided that you really don’t want to buy a product but do feel that much of what you do is similar to the other healthcare organizations that have attempted to model healthcare data. That’s probably a safe assumption, and lucky for you there are a number of resources that can help you. My recommendation for this is Len Silverston’s book The Data Model Resource Book, Volume 2. In this book, the author draws out a basic data model for healthcare, and it’s a great starting point.
   
   
4. Leverage Products
   
   If your choice is to go with a product delivered by a vendor, there are a couple of things that I recommend. First, talk with their other healthcare customers that are as similar to you as possible. Ask them how much customization they really ended up doing versus how much they thought they would do. Make sure you know and understand the rules associated with changing the product. Typically, once it’s yours you are able to make all the changes needed, but you need to know what is required for support or upgrades (i.e., ICD-10, which will likely drive base product changes for these products). Any customizations that you do may have to be reapplied after a big release.
   
   
5. Team Effort
   
   No man is an island and no data modeling effort should be taken on solitarily. Create a team that is made up of business analysts, data analysts and business owners. You will likely have to get some education on how to read a data model (What do those chicken feet mean again?) but the effort will be well worth it. Not only will it help your final product, it will increase buy-in from your business as well.
   
   
6. Recommended Resource
   
   Training and research is great, but if you need some day-to-day reference for how to do this work, then I highly recommend The Data Warehouse Lifecycle Toolkit, Volume 2. The people I know in this business have at least one copy that’s dog-eared and coffee stained. It’s like having a highly experienced data modeling consultant in your back pocket.
   
   
7. Hiring a Consultant
   
   Hiring a consultant to do your data model is a reasonable option, if you can get leadership to fund it. As you consider this option, make sure you do your research. Call their previous clients (talk to clients who have had the data model in use for at least one year). Ask the consultant if they have experience with healthcare; if not, ask how long they have been doing data modeling. The theory goes that even if they don’t have specific experience in healthcare they will have likely run into very complicated modeling scenarios in their years of experience.
   
   
8. It’s a Journey, Not a Destination
   
   I am going to put a line in the sand here and say that I really believe that you can’t model everything all at once. This “big bang” approach to data modeling usually means that some smart people lock themselves in a room modeling the data for your business the way it was and the second they close that door, your business has already changed. You will always be doing some type of data modeling, so get accustomed to the journey.
   
   
9. Make Sure You Have the Right Tools
   
   Data modeling tools are vast and varied. I have no specific recommendation for you on a product, but make sure you use something. It’s tempting to just use Microsoft Word with all of the boxes and lines that are available, but making updates just changes the documentation, which isn’t really where the work is. The more capable modeling tools can aid your version control and release strategy, save your team hours and hours of effort (and is less expensive than another full-time employee), and reduce the risk of a missed update.
   
   
10. Hybrid
    
    There is no one right answer. You will have to commit to data modeling in your organization within the terms and risk your organization is willing to assume. Although I have outlined three categories, it is reasonable to assume that you will use some or all of these methods for your data modeling efforts. Taking the best of each option will increase your likelihood of success.

Data modeling is foundational. Without it, I can guarantee failure, but with an ill-advised model (as you have read) failure is also possible. If you follow these ten considerations, you will be in a much better position to tackle the next phase of your business intelligence effort, and the best part is that with a good data model, you can define what that will be.

Recent articles by Laura Madsen

• Business Intelligence Programs for Healthcare
• ETL for Healthcare Business Intelligence
• The State of Healthcare Business Intelligence
• Navigating Cultural Considerations in Business Intelligence Deployments