Could everybody’s ADT system use the same database schema?

Tim at HISTalk poses a poingnant question: Could Everybody’s ADT System Use the Same Database Schema? Some excerpts:

What I was really thinking about is the idea that the database design tells you how the application works. If that’s true, then what technical functions of the vendor add the most value? Is it database design, GUI design, algorithms, content, or something else? If our vendor’s competitor got a copy of the schema I was looking at, would it really reveal any proprietary secrets or otherwise turn on their lightbulbs with great ideas to change their own app? Or, would they be as lost as the clients who called me for elaboration? Maybe they wouldn’t even be interested.

Tim elaborates:

Why can’t every vendor voluntarily or mandatorily use the same database layout for core information? How many ways can you express and repose standard elements such as date of birth, gender, address, etc.? Vendors can, when under duress, feed their data to a standard interface. Why can’t all systems just use an approved core set of tables, updated by the same core set of business rules, and then add their value through additional related tables, GUIs, business rules, etc.? Everyone’s patient database could look and work the same. Seen one, seen ’em all.

Tim’s concept of “one schema to rule them all” is actually going to be close to reality eventually, but only if we can agree on common business rules as well as data. The idea of “universal data models” that guys like Silverston and I promote is exactly to Tim’s point: don’t reinvent the schema wheel.

The reason why we won’t see a universal schema in healthcare anytime soon is that the it’s very difficult to create one that is extensible enough. I’ve been building extensible schemas for years, but they require a great deal of effort, time, and expertise. All of that adds up to expensive. Doing the right thing is always a bit more costly. The schemas that are thrown together by many health IT vendors these days would be laughed at by non-healthcare folks. Outside the health IT community, where I still spend a good deal of technical time, data models have been steadily improving and becoming standardized. See the cases of SAP, PeopleSoft, ORACLE apps, etc. Those are large-scale ERP solutions designed to have applications attached to them so their data models are designed to handle it. They’re certainly not perfect, but certainly more extensible because these applications have to play well with others and are designed to do so.

I hope Tim’s post, along with mine, starts a real debate among buyers of healthcare about how transparent they want their vendors to be about the database schemas in their products. In our new service-oriented world we need to make sure that vendors are providing software that can plug and play and that starts with extensible schemas that can manage data properly.

It’s a joke to think we’ll have an NHIN, RHIOs, CPOE, EHRs, PHRs, EMRs, etc without a basic understanding of data and relationships.