Repeat after me: Healthcare Data Models Matter

Shahid, host of the Healthcare IT Guy blog, has also launched a fine new "metablog," HITsphere that aggregates posts from across the eHealth ecosystem, and enables searches in this growing community. Here he reminds us how important it is to  structure data today for future uses such as electronic healthcare.

Guest Blogger
Shahid N. Shah, Chief Architect, Netspective

As we all know, healthcare applications come and go but data lives on forever. We’ve seen that since the beginning of the computer industry; when we move from legacy systems into more “modern” architectures, we often leave behind applications but we almost always take along the data into the future. Even though data is so important, we in health IT don’t seem to spend the quality time necessary to structure our schemas and databases in such a way as to make it easier to maintain in the future. We often don’t design our data models solidly and we don’t test it well. Although things should have improved when we got to object oriented programming (OOP), object-oriented technology has actually caused data management principles to be unintentionally compromised.

Large-scale object-oriented applications development, which is fairly new to healthcare, has not improved our ability to manage data using sound data management principles. This is because in the world of objects, data is simply considered part of the state of an object. For example, a person object’s demographics are considered the state of the person object. An encounter’s data is considered state of a transaction object. Most modern object-relational mapping (ORM) tools try to hide SQL and the underlying relationships of the database. This is great if the data model is designed from the ground up by a relational modeler and then the ORM is applied on top of it. More often than not, though, the ORM is used to generate the schema – which means that an application programmer is determining the data model, not a data modeler. What’s wrong with that? Simple: if the application were the most important thing, that’s fine but if we want the data to live forever we need to define the data, its usage, how it’s structured, etc before we design the application and not the other way around.

Our friends in the health IT applications development community need to be taught that data modeling is not just a technical exercise. You can’t define a data model with a bunch of engineers and other “geeks” sitting around a table. Data modeling is about understanding all the uses of the data, the relationships and attributes involved in the data, and most importantly how the data management approach will grow and change in the future. It’s the last part (extensibility of the database) that is often forgotten in most systems. All this involves direct communication with end users, stakeholders, and other non-technical personnel. This seems pretty obvious but in my 15 years of experience I’ve learned that databases are treated as a file cabinet – just let your application toss whatever is necessary in there and then we’ll deal with organizing it later. When you do that, it’s a recipe for disaster.

When you’re building your own systems, you should attempt to use tried and true data models from existing sources. If you don’t have hotshot data modelers, look at Len Silverson’s two-volume work: “The Data Model Resource Book: A Library of Universal Data Models”. Buy the two books, try to comprehend what an extensible data model looks and works like, and then hold your developers and database administrators accountable for it. If you’re building a healthcare meta model, there are even books available that cover universal meta models. Unlike a few years ago, there are books which provide de facto, well designed, data models so you’re not on your own. If a developer comes to you with a data model but can’t provide references and patterns for how he arrived at his model, tell him to use one of the ones described in a book. There’s no time to keep reinventing the wheel.

When you’re buying new systems, spend more time evaluating the database design than the application’s user interface (UI). The UI can easily be changed in the future but the data model is not a trivial change (and when the vendor changes the data model you’ll be in a world of hurt). If a vendor does not let you analyze or study their data model, don’t buy from them. That’s like a car deal selling you a car without you being able to check the engine. When you’re evaluating a data management system (and in health IT almost all systems are data management systems) then focus on the data, not the applications. You could even use the Silverston type books referenced above to make your vendor compare their data models against other well known designs.

With all the talk around “patient-centric” architecture you’d think that the vendors have a data model to support it. Of course, we all know that they don’t and we need to hold them accountable for it. And, with all the new integration needs being identified by RHIOs, NHIN, PHRs, and EHRs, data models are even more crucial. Applications will continue to be chopped up in a service oriented architecture, making the central database even more powerful.

The lesson here is simple: because applications come and go but data lives on forever, don’t ignore the data model.

IBMHealthNex

Comments

[Shahid N. Shah]

A data architect friend of mine sent me a link from DMReview that has a good overview of the Silverston book I referenced in the article (written by Len himself). If you don't have the book and don't want to buy it without finding out more about what's in there check out

http://www.dmreview.com/article_sub.cfm?articleId=5170.

After you read the article, pay the $60 so Len can feed his family :-).

[Charles Bess]

I does make me wonder a little about the emphasis on service oriented architectures and model based development in the market today. Isn't the interface to the data as important as the data itself? Data is something you hide and protect. The interface (and the process) are how you generate value and make the data useful.
Granted processes change, but in reality the data needs to change as well in order to remain useful. In your document you mention:
"Data modeling is about understanding all the uses of the data..." that seems to me to have as much to do with process modeling and business modeling as it does with just data modeling. Data is part of the story.

[Shahid N. Shah]

Charles, well put. You are, of course, correct that data is merely part of the story. However, my general complaint with many health IT vendors is that their applications have inadequately designed databases. I didn't mean to imply that SOA, MDA, process modeling, etc aren't important. However, in order to get any database-centric systems to be successful the database has to be treated as the one of the most aspects of the system. Most HIT systems today are very database centric but don't act like it -- which is why most HIT applications are not extensible. You can't really put service enable current HIT systems because you'd have to rip apart applications to do so.

[William Oliver]

"When you’re buying new systems, spend more time evaluating the database design than the application’s user interface (UI). The UI can easily be changed in the future but the data model is not a trivial change (and when the vendor changes the data model you’ll be in a world of hurt). If a vendor does not let you analyze or study their data model, don’t buy from them. That’s like a car deal selling you a car without you being able to check the engine. When you’re evaluating a data management system (and in health IT almost all systems are data management systems) then focus on the data, not the applications. You could even use the Silverston type books referenced above to make your vendor compare their data models against other well known designs."

I couldn't agree more. There are many open discussions on my boards about this exact topic. I saw a need for a community to discuss this and other issues several months ago. I started Healthcare Information Technology Forum as a place to do that. I'm going to add this as one of the discussion points.

Soupcan
Healthcare IT Forum
www.healthcareitforum.com

[William Oliver]

"When you’re buying new systems, spend more time evaluating the database design than the application’s user interface (UI). The UI can easily be changed in the future but the data model is not a trivial change (and when the vendor changes the data model you’ll be in a world of hurt). If a vendor does not let you analyze or study their data model, don’t buy from them. That’s like a car deal selling you a car without you being able to check the engine. When you’re evaluating a data management system (and in health IT almost all systems are data management systems) then focus on the data, not the applications. You could even use the Silverston type books referenced above to make your vendor compare their data models against other well known designs."

I couldn't agree more. There are many open discussions on my boards about this exact topic. I saw a need for a community to discuss this and other issues several months ago. I started Healthcare Information Technology Forum as a place to do that. I'm going to add this as one of the discussion points.

Soupcan
Healthcare IT Forum
www.healthcareitforum.com