It was a huge effort, and we did a bunch of things right -- but all those parallel efforts had one big downside. Our consumer experience was fractured and in many ways downright unusable for all but the most motivated users. For example, creating an account was a tedious journey through up to eleven pages, with no consistent branding or explanation of where you were in the process.
I am super-excited to say that we've just released an update to HealthVault that really starts us down a path to correct some of these issues. Still lots to do before we're satisfied with where we are, but my hat is off to Mike, Tien and all the rest of the Shell team that has been focused on this over the last few months.
That eleven-page signup? Down to five -- and all five share common branding elements and a consistent approach to partner co-branding to help folks understand what is happening and where they are.
The "application auth" experience -- where a user authorizes an application to work with HealthVault data -- has gone from an impenetrable block of bold run-on-sentence craziness to a crisp table of requirements. Even better, users can quickly and easily see exactly why an application needs each type of information.
We've made a bunch of other usability-driven tweaks and fixes as well. We'll continue to push on this into the Summer. Some great new stuff is on tap for Connection Center and the way folks discover and navigate in and between HealthVault applications... can't wait for the next wave.
In addition to the usability work, this release includes some great new features that continue to deepen and enrich the set of tools available to HealthVault users and partners.
One of the things we heard from doctors was that they really wanted a way to verify the "pedigree" of HealthVault data -- something that could help them make a judgment about the accuracy of information they receive. Other systems have tried to address this need by limiting users' ability to alter or delete information in their record -- but this was a non-starter for us. Remember principle #1 -- these records are controlled by the consumer -- not Microsoft, not the doctor, just the consumer.
I love the solution we came up with. With our new release, a partner adding data to HealthVault can "sign" it using a digital certificate owned by the source provider. For example, Overlake Hospital here in Bellevue could obtain a digital certificate from a company like Verisign and use it to "sign" all data they send to HealthVault. When a primary care doctor receives that information, she can verify that the signature is valid, and can make a trust judgment based on a strong assurance that the data did indeed originate at Overlake and has not been altered in any way.
No control is taken away from the consumer here -- they can change the data -- but if they do, the signature will "break" and no longer validate. So we get the best of both worlds ... consumers of HealthVault data have a powerful new tool to verify the source of information, without any impact to our fundamental principle of consumer control. Bing!
But wait, there's more!
We've also now gotten to the finish line with direct-to-clinical, so you can expect to start seeing partners integrating along the lines of the demos at http://healthvault.com/hospitals in the very near future.
We've made a number of new "vocabularies" such as the FDA Nutrition database and RxNorm drug codes available for use by partner applications, and exposed these through a new JSON interface that makes it super-easy for partners to create "word wheel" style entry forms for easier data entry.
Custodians can now mark individual HealthVault items as "private" -- which makes them visible only to other custodians of the record. This really allows people to fine-tune the way their data is shared, even beyond our existing type-based mechanisms.
There's more, but time to take a breath. Suffice to say it's a great release, and we're really excited to have it out there. As I've grown fond of saying... one more turn of the crank.
This is pretty exciting. As a user, I was certainly having to see through the UI issues before to understand the heart of HealthVault.
I'll be very interested to have a look at what is new for the user in the newest release. Is there a plan to have educational components within HealthVault that would become available, or made active, according to the patient's records or indications of -for example- chronic conditions? It seems like having that on the web side would be fantastic for patient education. I imagine a set of modules that relate specifically to the patient information to provide timely and relevant educational content inside HealthVault, though I suppose it would have to be authored third party. The Community Health Center model is highly integrated with patient education and the HealthVault model has me pretty excited to discover new ways to achieve these goals.
David, we are currently thinking about this mostly in the context of providing tools that allow applications to integrate links to (and content from) our Live Search Health product into their interfaces.
Right now, it's pretty early for this, mostly just "hotlinks" from terms to search. I can't add one here in the comments, but if you look at my recent post on our Solutions Conference, you'll see the word "agoraphobia" embedded in that post with a double-underline. If you click on that, you're shown a contextual popup that allows you to dive into our search application to learn more.
We are working to figure out how to pull more of the search interface forward into the applications themselves ... this is of course a tradeoff; we will never be able to represent the richness of a full-page search page in a popup, so we will instead try to answer a few key questions quickly, with links back to search as the way to dig in.
Hope that helps ... I would love to hear your thoughts and other ideas as to how else you'd like to see content integrated into the platform.
Thanks again ...
Search is one thing, but custom user-specific content, well that is another. One thing I am working on here is a website that allows students who are interested in health careers to hook-up with professionals who are in that career field online. Its sort of a healthcareers specific social network. The goal is to get students the information they need in a relevant and 'powerful way - by having real healthcare professionals provide that info in realtime. Its very new, and I am writing it myself. You can see it at myhealthcareer.net(it is really new and not yet populated with much, it is really just a framework...).
I wonder about how my site could be used in HealthVault later on. Say the system identifies a student aged user. Or even a user who has self-identified (maybe through a poll) that they are interested in healthcareers. I wonder what sort of mechanisms could be developed to encourage education on health and health careers and even to get info from my site into that user's account.
As an AHEC, we really want to increase health and health career information and outcomes. So, to me, though integrating links is super key (or even rss subscriptions to relevant sites), it might be even more remarkable to be able to add the ability for the system to identify key markers in the users in order to provide information from sites/education programs that would matter to the user, that they may never even know about. Making this information regionally, ethnically, or say even disease specific would make it very powerful.
However, pushing this info at the user might be obtrusive. Just trying to think about extending the idea of an HIE into one that uses the existing system to also provide health information suited to the user...
David, makes great sense. The twist I might put on it is that HealthVault data (in the form of demographics, information about conditions, interests etc.) can be a driver for content selection algorithms in a lot of different contexts and applications. So for example, we may add features to our Health Search that allow the user to (with their explicit opt-in) customize the results they get based on information in their profile. And that same pattern works in other contexts/applications as well.
The question of being obtrusive is I think a bit of a red herring --- so long as the user has expressed an interest in receiving information, and can easily tune what is sent or stop it altogether, and the information is truly relevant, it will not be perceived as a problem -- of course, relevant is the magic that isn't always easy to get right. :)
I will look forward to tracking your progress on this. It's the really cool thing about creating an ecosystem build around partners -- far, far more innovation than we could ever hope to engender just within our little group.
Thanks for the comments!