Could Everybody's ADT System Use the Same Database Schema?

I was thinking about databases a few days ago, even before Shahid wrote his thoughtful HIStalk guest article. I was looking at a vendor's database schema on the wall at work, wondering if the vendor was concerned that it could fall into the hands of competitors. You can understand most of an application just by inspecting its database, I reasoned. Anyone peering into these inner workings (like me) could purloin all of that hard-won intellectual property, if so inclined. Did that ever happen, I wondered? Did spies in trenchcoats lurk around with microfilm cameras, hoping to document all of those secrets plastered on the wall in front of me?

I recalled my vendor days. Our database (including the data) could be examined with minimal effort. Would that examination alone provide the key to the mint? Well, I used to handle lots of customer questions about our tables, rows, and columns (only we called them files, records, and fields back then.) They could query the database. They could sort, select, display, and manipulate data to their heart's content. They could, if adequately brave or stupid, even update or append our tables using their own programs or third-party utilities. So why did they need to talk to me? Reason: the database told them a great deal, but not enough to even extract the information they wanted, much less to design something new around it.

You had to know how our programs wrote and read data. Simply looking at the data wasn't enough. In fact, even our own programmers struggled with that issue since no one ever took the time to document anything properly (we were too busy trying not to go bust before an even more clueless company could acquire us.) Often it was a non-programmer who'd been around enough to know the rules and help a programmer write his or her program: "Orders are written immediately to both the order file and the order history, but are updated only in the order file until discharge ..." and so on. You could look at a ton of source code and still not figure out something like that.

Of course, embarrasing quirks added obfuscation. Certain fields had differing types even though they held the same information (one being alpha and the other being numeric, for example, due to some programmer screw-up a long time ago.) Fields were often mislabeled, containing different information than indicated just because the programmer was too lazy to change the database and instead re-used an obsolete field to meed a pressing need. Result: we had problems with data integrity, purging, referential integrity, system performance, and data inconsistency that would have been fairly obvious to anyone who cared to peer into our database.

This isn't my point, however. 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 the wouldn't even be interested.

From that feet-on-the-desk musing came a wild hair of a thought. Vendor's products work pretty much the same because it's easy for them to spy on each other. The arms race of features ensures parity. So, shouldn't their respective databases look almost identical? Is any other vendor's schema really all that different than the one on my wall? If so, why?

This is where my noodling got out of hand. 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.

Customers would be as thrilled by this idea as vendors would be appalled by it. Standard reports would work for every hospital, not just those of a particular vendor. Data translation for third-party reporting would be a no-brainer. Conversion of one system to another would be a piece of cake. Hospitals could easily merge and un-merge with each other to their heart's content, with data conversion and extraction being assured. You might even have your choice of database software, given an Internet-like abstraction layer that supports everything from Oracle to Cache'. Talk about your interoperability!

That's where I could envision no more. What would be the downside of a single database structure for the basic information used by all hospital applications? Would innovation really be compromised? Would vendors really gain or lose? Could it work technically? Knowing that vendors are generally recalcitrant, would customers be savvy enough to demand standardization? Would a vast army of suddenly unemployed consultants trigger economic chaos?

Then I had to go to lunch.