Opening up the Vault

  • Article

I've been looking forward to writing this entry for quite awhile.

We have been frankly thrilled by the reception that HealthVault has enjoyed since our launch just a few months ago. We've taken a few legitimate lumps over "v1" usability issues (fixes coming!) -- but almost universally what we're hearing is that folks see HealthVault and the kind of consumer-centric healthcare it enables as positive, exciting, liberating and inevitable. Even better, partners are backing up these words with actions -- the HealthVault partner team is handling hundreds of projects representing every corner of the healthcare ecosystem. I'll have a lot more to say about these partners in the coming weeks and months -- some really exciting stuff.

Of course, there are questions too -- one of the biggest that comes up is about "lock-in." We get this question in a few ways from different quarters. Consumers want to know that they really control their information -- and this means being able to get it out when they want, in a format they can use. We have a great story here: you can pull out all your data at any time. We provide interfaces to download documents and extract structured data in tabular format, we are doing work to exchange information using standard healthcare protocols such as CCR and CCD, and we have more features in the works to make this even easier for consumers. And really, the bottom line is that we're a service -- anybody can write a HealthVault application that, with the consumer's consent, can extract a full copy of all their information and render it in whatever format they like.

Developers and industry partners ask about a different kind of "lock-in." Choosing to develop on top of HealthVault is a big deal for these folks -- it means real commitment and real cost in the form of time and code. Of course, people need to believe this is a smart choice. What happens if HealthVault goes away? What happens if I don't want to develop on a Microsoft platform? What about other consumer health platforms that may come along? These are real questions that deserve real answers.

That's what this entry is all about. Today, I get to announce a set of three concrete steps we are taking to prove to our partners that they have made a smart and safe choice by betting on HealthVault.

First, we are demonstrating our commitment to cross-platform development by establishing a set of open "wrapper" libraries that facilitate HealthVault development across a broad set of environments. This week we created a Codeplex project to house the first of these libraries under the Microsoft Public License, for the Java environment. As we continue to engage with partners on other platforms, we will continue to create similar projects and solicit active participation from the HealthVault community.

Second, over the next few months (late Spring) we will be releasing our complete .NET SDK on Codeplex* under the Microsoft Reference License -- meaning that full source code will be available, but that Microsoft retains control over updates to this specific project. We have heard from partners that they want to have one place to go to understand the "official" way of interacting with HealthVault, so ensuring that only we make updates to this project makes sense. But by making the full and complete source code for the .NET SDK available, there will never be any question about how Microsoft has implemented HealthVault functionality, nor will there be any fear that developers will miss out on particular HealthVault capabilities by choosing an alternate development platform.

Finally -- and most importantly -- we will release the HealthVault platform XML interface protocols -- the stuff required to recreate and reimplement the HealthVault service -- under the Microsoft Open Specification Promise (OSP). There is a reasonable amount of work for us to do to "clean up" our documentation to make this possible -- but it will be complete by the Fall of this year.

This is a big deal, so let me reiterate:

  • Microsoft will make the complete HealthVault XML interface protocol specification public.
  • With this information, developers will be able to reimplement the HealthVault service and run their own versions of the system.
  • Microsoft will irrevocably promise that we will not make patent claims against you for implementing the specification, subject to the terms of the OSP.

You can read about the OSP here -- for the skeptics, the page also includes feedback from diverse representatives of the community. The OSP works, and it is a perfect way for us to be clear that "lock-in" is not part of our HealthVault strategy.

Will others take us up on this promise? I hope so -- we are working hard to help partners build HealthVault applications, and it just makes sense for others who want to offer consumer-controlled health records to start from an established, accepted starting point and leverage all that functionality. For those that take a different path, we will do our best to make sure that consumers can move data back and forth.

This is about putting consumers in control and making a real difference in healthcare. We believe strongly that we will all benefit as consumer-centric healthcare becomes a reality. Someday I'm sure we'll be competing for market share with other players -- but for the next few years anything that solidifies the space is great for everybody. I'm proud of what we're doing to get things moving.

* Added 5/14/2008 - As we work to make all of this real -- it appears that this will not actually be on Codeplex. The Codeplex site is only for true "public" licenses, so we will be finding another home for the .NET SDK reference package. No change in plan, just a clarification on delivery vehicle.

* Added 5/18/2009 - Mission accomplished! We've finally finished all three items we started talking about with this post. See this entry for details.