Again with the Standards Thing
David Cerino (General Manager for HealthVault) told me a funny story the other day. He was on a panel at the (very cool, I was told) Healthcare Unbound conference with folks from Dossia and Google, and the conversation turned, as it often does, to "standards." Jerry Lin spoke to the decision to use a modified CCR as the underpinnings of the Google product, and then the moderator turned to David and asked him why HealthVault chose to support the CCD instead.
Of course, David responded that there must be some misunderstanding, because HealthVault supports both the CCR and the CCD -- that our approach is to be as inclusive as possible in order to create a comprehensive record. To which the moderator responded (I like to imagine a dramatic courtroom flourish at this point) --- "that's not what David Kibbe says!"
Now, David is a pretty level-headed guy -- which is one reason why they send him to these things rather than me. Rather than take the bait, he simply reiterated his (true) statement and let the conversation move on from there. But here's the thing -- co-creator of the CCR Dr. Kibbe is what I generally refer to as a Smart Dude. If he is confused about this key principle, then others likely are as well -- and it's critical we all get this right if we want to make real progress around personal health.
I'm not going to try to dissect Dr. Kibbe's posts on the topic here. They are what they are, and in general I believe he is doing an excellent job of making the point that a combination of consumer control, distributed innovation and a drive for structured data are the key ingredients necessary to make a difference.
Instead I am simply going to talk about how we at HealthVault think about health data. And we think about it a lot -- we have a whole team working with our partners and the community to make sure that we are representing information in a way that will stimulate exchange and stand the test of time.
One of the first lessons I learned from Amalga (nee Azyxxi) founder Dr. Craig Feied is that in health it is far more important to be complete than perfect. Why does Amalga flourish, easily integrating new data feeds and sources when other, multi-million dollar projects fail? Because those systems place unrealistic demands on structure and perfection in the data they can work with. Why do clinicians trust that a look at Amalga gives them the information they need to make decisions? Because Amalga is built to incorporate all the data, not just the scraps that fit an inflexible schema.
Being generous, let's say that 20% of ambulatory doctors have electronic records at all. In hospitals that number is far higher, but I've had the opportunity to talk to folks from many of the best institutions in the world -- and even they often struggle to put together visit summaries as anything but blobs of unstructured text.
The reality is -- lots of data is unstructured. If all we can do is capture the tiny fraction that fits a perfect schema, we might as well go home now. This means that HealthVault will take your data as best as you have it: CCR, CCD, fax or scan, PDF, Word, text, whatever. Our first goal is to give you a complete record.
Of course, it's not just about completeness. In order to build a truly useful record and encourage distributed innovation, we have to move towards computable structure over time. Every one of the HealthVault data types allows for rich, detailed coding and structure. These types have been developed in conjunction with our domain expert partners, and wherever possible are derived from existing standards. We encourage the use of common vocabularies, and provide APIs and controls to help applications filter and interact with data that is as rich and structured as possible.
Even a casual look at our data dictionary will confirm that this is the case -- and that the extensible HealthVault data model can represent far more health-related information than is contained in any single standard. A good example is our rich set of fitness-related types, which make it possible for motivational applications such as Route Tracker to share data with clinical partners such as the American Heart Assocation and devices like those built by Polar.
We actually took a great deal of wisdom about encouraging structure but allowing flexibility from the CCR itself. For example, it allows many dates to be entered as simple strings, such as "as a child" for immunizations. The truth is, HealthVault is just as "computable" -- and I would claim far more so -- than systems that rely on any single standard.
Insisting on the One True Standard is usually a recipe for failure. Instead, the trick is to represent data in ways that can be transformed into whatever formats and standards are meaningful to those that want to use it.
This is where the CCR, and the CCD, come into play. Because we can accept information in many diferent formats, we are able to interact with the largest possible set of data sources and consumers -- and that, after all, is the point of doing all of this work!
Our message to partners is simply this: send us data in the highest-fidelity format you can. That might be a CCR, or a CCD, or "native" HealthVault XML, or just documents. Whatever you have, we'll take it. And then -- this is the magic -- we will keep working forever to make that information more and more useful. When we launched, we couldn't even take a CCR. Then we could, but you couldn't really do anything but store it. Now you can view it as rich HTML and print it out. Later this summer you'll be able to break that CCR down into its constituent items (medications, etc.) and integrate them into your record in a much more useful way. In the future -- maybe we'll be able to do the same using OCR to transform a fax containing immunization records into structured data.
The point is, by accepting the best information we can from everyone, we can say that you'll always have the most useful, complete and computable information possible -- and it will just get better and better over time.
Within this context, would it make any sense at all to NOT accept CCDs? Of course not.
This post is getting pretty long ... but I really want folks to understand what we mean when we say we are thinking hard about the problems involved with storing health information.
Given the tiny fraction of the world that uses electronic health information today, it seems fair to assert that we probably haven't figured out everything we need to about what the best way to represent that information is. Even the best standards evolve and change over time -- you need only look at your old stack of LPs or cassette tapes to see this in action.
But health information isn't the same as that Blondie album I bought in fifth grade -- for personal health information to be useful, it needs to remain computable from the time we're born to the time we die ... and even longer if we want to really understand family-wide trends. What can we do to ensure that the information I create today remains useful in the medical world of tomorrow? This isn't throwing spaghetti on the wall to see what sticks -- it matters. So we've built the HealthVault interfaces to automatically transform types from version to version. This means that the data that comes off of your Omron Blood Pressure device today will morph and evolve with the state of the art -- and continue to be a useful part of your record throughout your life.
Wrapping it up
At the end of the day, I think we're all rowing the same way, trying to build tools and systems that will help people get and stay healthier. But there are differences in the way we think about representing and exchanging information, and it is critical that we talk about those differences now, when the game is just beginning.
We absolutely support the CCR. And we support the CDA and CCD, whether it's at level 2 or the far more computable HITSP C32. We support interoperability between Google Health, Dossia and HealthVault, and are putting our money where our mouths are to prove it (in particular check out slide 22 here). We are here to play.
Let's just get moving --- OK?
Edited on 7/15 to fix two typos ... can't believe I spelled Azyxxi wrong after all this time!