How Soon Is Now?

Relational Data And The Lagging Healthcare Revolution

For over two decades we’ve been told about a coming revolution in healthcare – but it never seems to arrive. Relational databases may play more of a role in preventing the revolution than anyone suspects.

Part II: A Technical Problem With Business (and Clinical) Impact

In Part I, I wrote about healthcare IT’s reliance on decades-old relational database technology. In Part II, we look at why the relational database makes integrating healthcare data so difficult.

Because databases are buried at the bottom of the application stack, business sponsors tend to view database issues as implementation details that are outside their scope. But when an entire organization is using relational databases, the schedule and cost impacts on single projects, as well as the overall drag on the organization as a whole, are staggering. You may have heard developers talk about the “impedance mismatch” between object-oriented applications and relational databases. This probably sounds like a low-level technical concern – until you actually understand what it entails.

Figure 1: The splitting imposed by the relational data model

To make the impedance mismatch concrete: Suppose you have a stack of paper medical records. Each document represents patient information and medical history for a single individual. Say that instead of simply leaving these records in a pile on your desk or filing them, you instead get out a pair of scissors and cut them all apart. You then take all the patient names and put them in one pile, all the patient street names and put them in a second pile, all the town names and put them in a third pile, and so on, until you’ve worked through the entire form down to every last visit, reported symptom and treatment (Figure 1). To keep the original documents straight, you assign a number to each piece you cut out so you can associate it with pieces in other piles. Then, suppose one of your patients comes in for a visit. You then go fishing through the piles, starting with the patient’s name, then finding all the associated pieces of the cut-apart medical record so you can reassemble it and meet with the patient.

Sounds insane, doesn’t it? Yet this is exactly the sort of practice that relational databases force on developers. Data that is entered at the application layer is shredded and rearranged at the database layer, then reassembled when it is retrieved again at the application layer. To perform these operations, a modern object-oriented application has to speak to a relational database through a translator – an “object-relational mapper.”

The object-relational mapping process works. But it comes at a high cost. Every time there are changes – in the data, in the application, in the requirements – there are associated mapping and ETL changes that cascade throughout the organization’s systems. Each change brings additional expense in the form of coding, testing, communication, and of course, time. Worst of all, this mapping and remapping takes place in the background, adding time and cost that business and clinical sponsors cannot see, understand, or perceive any value in.

Given the cost impacts of relational data, it’s no wonder that healthcare IT departments have become famous primarily for saying “No” – no to new requests, no to incremental change, and most certainly no to the sweeping change required to support the planned revolution in healthcare.

Relational data is a significant source of project risk in an industry that is already risk-averse by nature. Overcoming its limitations won’t be sufficient, in itself, to finally accelerate the healthcare data revolution. But it will be necessary.

Marklogic and The Healthcare Revolution

MarkLogic makes use of data in its original form. Incoming data is stored and indexed in the same format in which it is received, and is searchable as soon as it is loaded. Applications transform data stored in MarkLogic only if and when they need to. There is no need to create a single, shared data model up-front or anticipate every single use of that data in the modeling process. Returning to our metaphor of the paper records for a moment: there is no need to cut the records to pieces or assemble them into an artificial scheme of rows and columns.

This fundamentally different model has a huge impact on costs and risk. A healthcare payer client of ours recently took a complex data integration project that a relational team estimated would require 40,000 hours of effort. They decided to do the project on MarkLogic instead, and delivered it successfully with just 5,000 hours of effort. That’s a saving of 87.5 percent. To put it in financial terms, if you estimate labor at a ridiculously conservative $100 per hour, an estimated $4,000,000 project is now a very reasonable $500,000 project instead. Not to mention the project can be rolled out before it is obsolete!

Figure 2: MarkLogic unifies data and makes it easily accessible

We have noticed something happens when healthcare client teams start delivering projects on MarkLogic for about one-eighth of their original estimated relational cost. Namely: They stop thinking about what they can’t do and start thinking about what they can. And of course, so do their sponsors. Shorter timelines, reduced effort and reduced risk shift their collective focus from risk to creativity. And creativity – the audacity to say “Why not?” or, even better, “Why not now?” – is the soul of revolution.

That is why we believe MarkLogic is going to be a key player in the healthcare data revolution. We believe that in the future, when people are actually finally using data to improve clinical outcomes, to enable smart healthcare consumers, and support outcome-based payments, that data is going to be stored in our database. And we don’t see any reason why everyone shouldn’t get started. How soon is now? Now is now.