The folks at Google Health have been taking it on the chin this week, after the Boston Globe ran an article about a super-engaged patient named Dave who found a number of pretty nasty surprises when he imported his health information from Beth Israel into Google. From what I have read there were really three key issues at play:

1. BIDMC is sending condition information based on billing codes. Inferring good clinical data from billing codes is a notoriously tough thing to do - the codes are vague and dated, and it's just assumed that people will jam whatever seems kind of close in order to keep the dollars moving. And at a more basic level, things that get billed are often exploratory - just because I got an HIV test doesn't mean I have HIV.
   
   
2. A lack of proper date tagging resulted in data mush. For example, he received warnings about "critical" medication/condition interactions where the problematic condition was resolved years ago.
   
   
3. Only a small subset of the record was actually transferred. BIDMC has only implemented sharing of conditions, meds and allergies --- so Dave didn't get everything he expected/wanted in the exchange. 

People are having a grand time drawing conclusions from all from this, mostly trying to decide "who sucks" --- is it Google, or BIDMC, or the insurance companies, or lousy doctors, or all PHRs? Maybe the government? One guy actually suggests, seemingly in seriousness, that we should all just give up.

Jeez --- settle down, Beavis.

Yes, there is great learning here as to what can be done better --- Dr. Halamka has already posted about steps they're taking at BIDMC to make things better (as an aside, how many other medical institutions out there display this kind of transparency? Kudos are deserved here.). But the reality is, there is a bunch of dirty data out there in the world, and it is being used not just for billing but to make clinical decisions. Providing transparency and letting people see the mess inside --- that is the first real step to getting it fixed.

Anyways, the question I keep getting asked is --- is HealthVault vulnerable to this as well? As is all too often the case, the answer is yes and no. I think we are in a much better position than Google, but we are definitely not completely immune.

The bottom line is, if I authorize a provider to add data to my record, and they add an item that says "Sean has cancer," then indeed my record will say just that. There is no magic truth detector in HealthVault that knows that I actually don't have cancer (nobody would question our business model if we could do that!). And sometimes the data coming from providers --- especially those that rely on billing codes for clinical information --- will be wrong. So what can we do about it?

This is where our approach to data really helps. When we accept information from hospitals and other providers, we almost always get it in the form of a "package" --- either a CCD or CCR document. Within these documents can be many different individual data elements, all bound together as a snapshot of what that source believes to be true at a given point in time. These snapshots remain in HealthVault as distinct items, and can be digitally signed by the creator so recipients can trust where they came from and that they have not been tampered with in any way.

The user then has another choice - they can "reconcile" the package by looking at the individual items and choosing which ones should be extracted into their record. Only those items that the user chooses to copy out become part of their canonical list of conditions, allergies, medications, and so forth.  There are a few really nice things about this approach:

• Users have a well-defined place to make decisions about what elements they want to accept and which they believe are wrong. Right now our "reconciliation" process is pretty manual, but as we go forward we expect to do smarter things. One great idea that William Crawford put forth was --- in an interface like this, call out conditions that are associated with billing codes with a special warning icon --- to suggest that the user may want to take a closer look at these.
  
  
• It puts a fence around the "dirty data" problem so that users can benefit from all sources without worrying that their records are going to become polluted with errors.
  
  
• It turns out that retaining both the individual items and the package can be really useful - for some use cases the package itself is what a recipient really wants. For example, a referring doctor that wants to see the results of a surgery at NYP probably wants the digitally-signed CCR from that visit, not the user's all-up history.

You can see some screenshots and more detail on our reconciliation interface as part of the HealthVault Nickel Tour ... look for the "integrating information" part of the post.

No matter how you slice it, building and maintaining a quality health record is just a tough problem. I spend a lot of time with hospitals and other providers trying to help them figure out how to start sharing data with patients. So I can't help it --- I have to put in another plug here for New York Presbyterian, which launched their new patient portal at HIMSS last week (I am now officially two days late on my tech details follow-up post about NYP ... working on it!).

NYP uses our Amalga UIS toolkit to create a comprehensive, quality "data asset" that is the foundation driving the visit summaries they send to HealthVault in CCR form. Amalga is a really, really neat piece of software --- its sole purpose in life is to collect data from wherever it is in the institution, aggregate it together, and use it to perform real-time or retrospective analysis, drive internal workflows, or (as in the case of their patient portal) share it with other people or systems. Because they put in so much work up front to create a great data asset --- the information that NYP patients receive in their visit summary is really, really impressive and useful.

All up, I am super-glad that we have folks like Dave out there pushing the envelope. I know that the issues he uncovered are only the first ones we'll have to deal with. I think that with HealthVault we've done a good job laying a foundation that has the right fundamentals to help get us through successfully ... but it will take commitment from everybody involved to really make it work. The good news is, the payoff really matters and will totally be worth it.