Oops! The input is malformed!
Originally published May 25, 2011
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.
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.
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