Family Health Guy

Things are Pretty OK

I've been having an email discussion this weekend with some folks on the team about what "success" looks like for HealthVault ... kind of like those freshman-year-of-college things where you stay up all night and have pretentious debates about the impacts of Keynesian economics on individual property rights. I love a good email soapbox, as I am sure my long-suffering colleagues will confirm.

But here's the thing ... philosophy aside, there is real, concrete evidence popping up all over the place that says -- we are really getting there with this HealthVault thing. And watching all that momentum leaves me feeling pretty peppy, so I thought I'd share a few cool items with you all:

Hospitals!

Last Monday, Beth Israel Deaconess Medical Center in Boston announced that their HealthVault connectivity was live. Patients can now copy their clinical information from BIDMC's PatientSite portal into a HealthVault record, where they can use it when they see providers away from the hospital or when they take advantage of other applications in the HealthVault ecosystem.

Beyond the pure utility to real patients, this was super-cool because Dr. Halamka of BIDMC has also connected to Google Health and serves on their advisory board. By adding HealthVault connectivity, he is reinforcing the reality that it's crazy for us to be competing right now - we have too much work to do before we get there.

Consultants!

I've gotten really excited lately watching the emergence of a community of motivated third-party consultancies that are making HealthVault connectivity a key part of their practices. These folks fill a critical need in the ecosystem --- and the fact that they are beginning to establish real businesses around HealthVault says volumes about how far we've come.

• Netsoft USA offers services based on their HealthVault Connector framework, and just released a fantastic, in-depth tutorial for developers on working with HealthVault.
• CitiusTech has done a great deal of work integrating registration systems, HL7 feeds and other healthcare systems using their VaultAssist framework.
• Get Real Consulting offers not just consulting services for HealthVault, but developer training as well. They've also contributed an incredible developer tool to the ecosystem with HealthVault X-ray, which is quickly becoming an indispensible part of developing apps.

These are just a few examples - we're keeping up a list of third-party consultants on MSDN as well. Now we just need to get some hosting providers into the mix and we'll be in great shape.

Devices!

A few weeks ago we announced our device certification and logo program for HealthVault. As more and more HealthVault-compatible home monitoring devices come online, we've reached a point of critical mass where a consistent testing experience is an important piece of the puzzle. I'm looking forward to seeing those HealthVault logos show up on store shelves!

Clinical Trials!

One of my favorite new HealthVault applications to go live recently is Trial X - a service that helps match consumers up with relevant clinical trials. The initial integration is clean and simple, using conditions stored in your HealthVault profile to help identify potential matches. But what is really exciting here is the potential for what Trial X - and other services like it - could become.

Imagine the advancements we could make if people - in a completely opt-in and transparent way - could participate in research and trials not just as passive test subjects, but as an integral part of the team. Researchers could source from millions of potential subjects at a fraction of the cost involved today. Even better, they could stay connected with those participants throughout the life of their study, asking follow-up questions and easily tracking results over the course of years and years.

The issues of privacy and control are critical here, of course ... and using the HealthVault authorization engine we can guarantee that people share only what they want, when they want, with who they want ... on a completely opt-in basis. It's a win all the way around --- patients in control and researchers better armed. Wooo hoo!

OK --- there's more, but it's time to go to bed. Stay tuned for more developments --- we have some neat stuff coming out in our September releases, and I'm trying to get a new sample app together for some of our Employer-focused features. Things are, indeed, pretty OK.

Credit to the always-awesome XKCD for the contented protester image!

Anybody want to build a fun app?

This morning in the shower, I was trying to think up with new ways to motivate folks to do little things to increase the amount of physical activity in their daily lives. As anybody who reads this blog knows, I am in love with RouteTracker, and credit my "castle-to-castle" virtual trip (current location: Cloverleaf, Texas; next stop Houston) with much of my success in losing weight over the last few months. And I can't say enough good things about my Wii Fit ... so what else can we do in this space?

Anyways, I came up with what I think would be a really fun idea, and figured that by talking about it here maybe somebody will be inspired to build it. It's on my list too, but that list is about seventeen applications deep right now -- so the reality is -- not happening from me anytime soon.

"CubeFit" is a group game intended to be played in an environment like a dorm or office building where people are reasonably spread out as they go about their workday. The objective is to score points by racing to accomplish brief exercise challenges received randomly during the day through text messaging -- a combination of flash mobs, basic office chaos and just a bit of exercise. A game may last anywhere from a few days to months. Here's how it works:

Game Setup

First, somebody starts a game at the CubeFit web site by logging in with HealthVault credentials and providing the overall game parameters:

• Which time blocks during the week are eligible for challenges, and how many challenges should be issued during each block. Challenges are issued at random times within the blocks. For example, some groups may choose to allow challenges any weekday during lunch hour, while others may have them appear at any time of day, but only on Fridays.
• A selection of challenges to be used in the game. Challenges involve some level of physical activity; for example, doing 10 pushups, 20 sit-ups, 30 jumping jacks or running to the kitchen to fetch a cup of water.

Next, people sign up to participate in the game. You could worry a lot about invitations and security here, but that seems like overkill. Instead, I'd just let anybody who knows the game URL sign themselves up to play. Each player supplies a nickname and their mobile phone number and carrier, so they can receive text messages.

Game Play

Now - the game is on.  During the active game blocks, the CubeFit application randomly selects a time to issue a challenge, picks a challenge from the configured set, chooses one player to be the "judge," and creates a challenge password. The judge then receives a text message like the following:

The judge does not perform in the challenge, but automatically receives 2 points accepting the job. If the judge is able to play, they reply to the text message with their location: an office/room number or some other description that players will recognize. If for some reason they cannot, they simply reply "no" and the system will randomly select a different judge and new password. Similarly, if the system does not receive any reply within two minutes it will move on to a new judge.

Once the judge has accepted their role, the system sends out a text message to every other player in the game:

As soon as they receive the challenge message, each player must try to get to the judge's location as quickly as possible. Once at the location, they must perform the challenge in the presence of the judge. The judge then takes the player's phone and replies to their challenge message with the. In addition, the first person to finish the challenge should have one "*" character added after the password; the second-place player gets two stars; third-place gets three. The system is thus able to award points to each player:

• First place = 5 points
• Second place = 3 points
• Third place = 2 points
• All others that successfully complete the challenge within 30 minutes = 1 point

Additionally, the system records completed challenges as exercise objects in HealthVault - so users can keep a permanent record of activities over time and correlate them with other health information like weight or caloric intake.

Leaderboard

Of course, a game like this is only fun if you can crow about your place on the Leaderboard. So the application will provide a "widget" that can be placed on sites like Facebook or blogs, showing the point leaders of a game and a particular players ranking.

And that's it ... pretty simple, but I am thinking that in an environment like ours at Microsoft, it would make for a lot of fun (not to mention great spectacle) to suddenly have people burst out of their offices and meetings to run across the building , trying to be the first one to do a bunch of jumping jacks in front of one of their co-workers. Just silly enough, but with real value at the end of the day as well.

What do you think? Want to build it? No IP protection here, babe -- go ahead and steal it, change it, whatever you want. But if you do put something together -- let me know so I can play!

Comparative Analysis with Respect to the Comparative Analysis

The good folks at Project HealthDesign just published a pretty comprehensive analysis of the state of the art in personal health record technology. There's a lot of information in the report, and despite having a truly hilariously long title at twenty-two words, most of it is quite well done. However, there are a few points, at least with respect to HealthVault, that really need to be corrected -- so here goes.

Not surprisingly, the place where Mr. Sujansky has the most trouble is the HealthVault authorization model. We've done our best to make the consumer's experience through the authorization process as painless as we can -- but the underlying concepts from a capabilities point of view are very rich and, ok, complicated. Frankly, I really would rather walk you through it with a whiteboard between us, but a blog entry will have to do for now.

The fundamental misunderstanding is the idea that somehow access rules are "distributed" between HealthVault and third-party applications. This is simply not the case. The rules about what information may be shared with other people, and with all of the applications being used by those people, are completely managed by the HealthVault platform. This is compounded by a misunderstanding of the implications of the "required" and "optional" access privileges requested by HealthVault applications. As a result of these, the document concludes that there are certain scenarios we cannot support:

In fact, we absolutely support these scenarios -- and many more. But I think the only way to really get through it clearly is to start at the top. Buyer beware here, unless you're an authorization geek this can get pretty dry. And forgive the overdose of bullets; it's how I try to organize this kind of thing in my head.

1. Authentication
   • Users identify themselves to HealthVault by using Windows LiveID or a limited set of OpenID providers. This is how HealthVault knows what USER is accessing the platform.
   • Applications, including the HealthVault Shell, identify themselves to HealthVault by demonstrating knowledge of a private key that has been pre-registered with the platform. Once this is accomplished, the application exchanges a symmetric key which is used for the duration of the session to encrypt messages and prove identity. This is how HealthVault knows what APPLICATION is making API calls into it.
2. Authorization: User sharing of records
   • Users have access to zero or more RECORDS, which contain actual health information. The access that a user has is controlled by a set of permissions, including (a) which TYPES of data the user may access in the record and with what actions -- create/read/update/delete; (b) during which time period the user has this access; and (c) whether or not the user is a custodian of the record.
   • Each record has one or more custodians associated with it. A custodian has the ability to grant privileges to other users. Initially, the creator of a record is the sole custodian, but he/she may choose to grant other users custodianship as well, and may revoke their own custodianship at any time. In this way control of records can, for example, pass from parent to child as the child becomes an adult and assumes responsibility for her own care.
   • We often refer to a user's rights on a record as their "maximal auth" -- this is the set of rights they will have when they use the HealthVault Shell. The user will never have access to more than this information, regardless of what application they use.
3. Authorization: Application access to records on behalf of a user, in the context of a record
   • Applications may only access a record on behalf of a user who has access to that record. The user may grant "online" permissions -- meaning that they must log in and receive a token each time the application wants to access their record; or they may grant "offline" permissions -- meaning that the application can access the record at any time. Offline access is useful, for example, in cases where an application offers "guardian angel" services, monitoring a record on a regular basis and alerting a user to gaps in care.
   • Applications must register with HealthVault the types of data they need access to in order to work, as well as the actions required on those types (create/read/update/delete). Some of these types are required, and others are optional. The PHD document makes a big deal of this, but it misses the point. The difference between required and optional rules simply reflect what the particular application is coded to support. That is, when I write an application, in order to do what I want it to do, some access is required.
     • For example -- if I want to correlate your blood pressure with your weight, my application must have access to both types in order to function properly -- it simply is useless as an application without those rights. So I would set my application to have required types of blood pressure and weight. The user can choose if they want the functionality of the application or not, in exchange for that access -- a very clear and obvious choice. To grant the app only one type would be pointless.
     • On the other hand -- I may have an application that allows you to chart your blood pressure AND/OR your weight -- there is no dependency between these two features, and the application can work properly with just one or the other or both. In this case, the application would register each type as optional ... meaning that the user can still use the application usefully even if only access to one type is granted.
   • Also -- application rights to a record are always intersected with the "maximal rights" that the user has ... and the user always explicitly grants a subset of their rights on a per-record basis. So, if I have only read-only rights to blood pressure items in a record, no application working on my behalf can do anything but read those items ... and even that only if I grant that access for that particular record.

In short -- BOTH of the bullets that the document says we "can't do" we CAN DO -- except that in the first case (the physician EMR), it is correct that if the application is coded to require write access to both medications and visit summaries ... then you would not be able to use the application AND allow only one type. The key thing here is that this reflects the features of the EMR application, not the HealthVault auth model -- and we believe the market will favor applications that are coded flexibly to require only minimal auth.

I have a few other quibbles with the analysis -- for example, I would claim that our API is no more "non-standard" that Google's or Indivo's. And I would love to see a more complete description of the evolutionary nature of our data model, as I know of no other system around that can represent types as richly as we can while still providing compatibility across versions. But the most important issue to clarify is auth, so I will leave these others alone for now.

All up, I'm glad to see this kind of analysis out there. It's important and necessary work as we strive to get the whole ecosystem on board. So thanks to PHD for taking the time, and I'll look forward to seeing a next revision soon.

Super-simple connectivity with DOPU

Our operations team is in the final stages of releasing one of my favorite new HealthVault features to the production systems. "Drop-off / Pick-up" (DOPU for short) is live in the partner environment now and will be ready for public consumption next week.

The idea behind DOPU is that sometimes it's just not necessary or appropriate (or convenient!) to create an ongoing, trusted relationship between a HealthVault record and a clinical system. There are many totally reasonable cases where an institution, laboratory, state agency, or whatever just has some information they want to give their patients -- and be done with it.

That's what DOPU is all about... simply create a file and "drop it off" at HealthVault. Later, the patient visits HealthVault and "picks up" the information using a secret code and challenge question. No muss, no fuss. If the file you create is a CCR, that's fantastic. But if it's not, no problem. We can take images, text or HTML files, Word documents ... pretty much anything will work.

Because there is no ongoing relationship, the integration model is much simpler than in other scenarios -- something most folks can easily implement in a few days. It has the potential to be a real accelerant for clinical connectivity -- I am totally excited to get it out there.

In order to help things along, I've written some fully-functional sample code that you're welcome to use as a starting point. Actually, the sample creates a small console application that you can even use exactly as-is to implement DOPU -- this means that you can now securely send information to HealthVault without writing a single line of code.

How it Works: Drop-off

To start with, the clinical system needs to obtain a HealthVault application id and install a certificate that is used to identify the system in calls to HealthVault. For my sample application, I've included a certificate that is pre-configured to work in our partner environment. Simply import the file "Drop-off Sample.pfx" using the HealthVault Application Manager that comes with our SDK.

Next, the clinical system has to generate a file they want to send. Ideally this is in a packaged format such as a Continuity of Care Record, but it can also be a file like an image, text, PDF, HTML or Word document. How this is done of course depends on your source systems -- one super-simple way to get started is to use "print-to-pdf" software to generate Adobe PDF files. The system also needs to collect a name and email address for the patient, and a "challenge" question and answer that the patient will remember (for example, "What was the name of your first pet?" = "Seeds the parakeet").

Finally, the system needs to run the DOPU application with a bunch of command-line parameters to make it do the right thing. The "test-dopu-ccr.bat" and "test-dopu-file.bat" files in the zip package demonstrate how to use the DOPU command line. I've also put together a more complete description of each parameter here.

And that's it. The data has been safely tucked away, and the patient will receive an email with instructions for picking it up. The original file can be deleted or archived as appropriate for the institution.

How it Works: Pick-up

When the patient arrives home, they will have an email waiting for them. The sample application uses the following text; a real-life application would provide more context. However, it is important to remember that email is a fundamentally insecure channel -- so no personally-identifiable information should be included in the email text.

When the user clicks the link, they are guided through a set of pages:

1. Signing into HealthVault, creating an account if needed.
2. Providing the secret code from the email.
3. Answering the previously-agreed-upon challenge question.
4. Picking the correct record to add information to.

After this, they're done. The information has been moved into their HealthVault record and is ready to be shared with other providers or family members, used with other HealthVault applications -- whatever makes sense for the patient.

What about privacy?

When the data is added to the HealthVault "holding pen", it is encrypted using a key derived from the answer to the user's challenge question. Because that answer/key is not sent to HealthVault along with the information, there is no way for HealthVault (or anyone else for that matter) to see what is in the package -- so no disclosure from the institution has occurred at that point.

Only when the patient goes through the "pickup" process and provides the answer to that question can HealthVault decrypt the package -- successful decryption indicates that the answer is correct, and together with the valid secret code confirms that the patient has rights to the information.

This is a pretty neat twist, one that allows HealthVault to manage virtually all of the "heavy lifting" for the institution while still preserving patient privacy and supporting the institution in its HIPAA obligations. Too awesome.

Which model is right for me?

At this point, we've developed three models for clincial connectivity, and each makes sense in a different context. DOPU is ideal when you're not establishing a long-term relationship with your patients. It can also be a perfect "first step" into connectivity that has a much lower technical barrier to entry than other models.

If you already have a patient portal, then using that as the connection point with HealthVault almost always makes the most sense. Without that portal -- if you want to support ongoing or bi-directional exchange of data (for example, reading home monitoring information into the institution on a regular basis) -- direct-to-clinical is the way to go.

Having a lot of choices means that almost certainly there's a natural way for you to integrate with HealthVault. Our partner team is always ready to help you figure out the right path forward -- best way to get started with that is a post on our MSDN forum. I can't wait to see us all connected.

Download Sean's DOPU Sample Application

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.

Complete

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.

Computable

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.

Interoperable

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.

Durable

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!

HealthVault and Identity Choice

My plan had been to blog about this when the feature goes live later in the week. But there's been some online discussion already, and I'm sitting here at the horse show in waiting mode anyway, so it seems like now is as good a time as any to join the conversation.

The deal is -- as of our next release in the next few days, users will have a new way to identify themselves to HealthVault. In addition to Windows Live ID, they will be given the option of using OpenID accounts from Verisign or TrustBearer.

As we've always said, HealthVault is about consumer control -- empowering individuals with tools that let them choose how to share and safeguard their personal health information. OpenID support is a natural fit for this approach, because it allows users to choose the "locksmith" that they are most comfortable with.

You can certainly expect to see more such options in the future. For example, we are in the process of building in native support for Information Cards, which provide some unique advantages, in particular around foiling phishing attempts.

But why just two providers? When we were making our plans here, Chris on our partner team asked me, "Isn't this more like sort-of-OpenID?" The same question has come up online as well.*** Really, there's a very simple answer here. OpenID is a new and maturing technology, and HealthVault is frankly the most sensitive relying party in the OpenID ecosystem. It just makes sense for us to take our first steps carefully.

Both TrustBearer and Verisign have taken their obligations very seriously with their OpenID implementations. Beyond basic must-have safeguards like SSL, each offers a variety of second-factor options that provide a step up over traditional passwords -- through the use of physical tokens or, in Verisign's case, the ability to associate an Information Card with an OpenID. This isn't meant to imply that there aren't other great providers out there -- there are. This is just a start.

As we learn more, and as OpenID continues to mature, we fully expect to broaden the set of providers that work with HealthVault. We believe that a critical part of that expansion is the formalization and adoption of PAPE, which gives relying parties a richer set of tools to determine if they are comfortable with the policies of an identity provider.

This is exciting stuff -- in a geeky way perhaps, but anything that begins to put strong identity technology in the hands of real users is a good thing, not just for those users, but for HealthVault and the Internet overall. Woo hoo!

*** BTW, I am clearly all about being cool and buzzword-compliant! :)

25 Tubs of Crisco

Today is the first day of our 2008 HealthVault Solutions Conference. I am pretty lucky at these things ... Our partner and business teams carry the brunt of the load and, except for a presentation tomorrow and a few Q&A sessions, I just get to sit here in the back corner of the ballroom and enjoy the show. The most exciting thing about it for me is to see the cross-section of folks attending. From doctors to entrepreneurs to executives to geeks like me ... there is real energy around doing something that matters.

However, that's not the point of this entry. As I alluded to a couple of months ago, I've been on my own journey to lose some weight and overall get myself into better shape. I hit a milestone of sorts the other day, and figured I'd share a bit about the process.

Twenty-five tubs of Crisco. That was the goal -- from 190 pounds to 165 in whatever time it took. Let's go.

Phase 1 - Fit but Fat

My first approach, starting late last year, was to get myself going with some aerobic activity. I picked up a simple rowing machine and lugged the treadmill in from the garage -- a good workout just moving all that junk around! After a tough start with pretty painful metatarsalgia, I got myself some high-tech running shoes and I was off to the races.

Since I was putting in all this effort running, I figured I ought to at least track what I was doing. So I started using the AHA application on a regular basis. And despite -- as I have said before -- the fact that running sucks, I did start to feel a lot better.

With the bump in energy I was getting, I decided to add in some mild strength work. My son is determined to play for the Red Sox, and right now that means building up his strength to throw faster and pop out of his catcher's crouch more quickly. So we started doing some leg work, pushups and pullups together at night before he went to sleep.

All great stuff -- but I sure wasn't losing any weight.

Phase 2 - OK, I get it

It was clear that if I was going to make any progress here, I was going to have to just quit eating, well, so much food. Which is a bummer, because I really quite like food. But ... time to get serious.

Back when I was in college, I had the greatest little diet tool ever. I did some calculations to figure out out that, given my body makeup, I would consistently lose weight if I ate no more than 1,440 calories a day. No magic here, just have to eat less than I use.

Then I had this little pocket-sized reference book with calorie counts for all kinds of common foods. It had a little dial on it, and as I ate during the day I could just keep track using the dial of where I was against my quota. Super-simple, and super-effective.

Unfortunately, I lost my little book -- and since it's out of print it seemed a bit pricey. So instead, I looked to my trusty smartphone to see what my options are. It's not HealthVault-enabled, but I found what I was looking for in Iambic's Health and Diet Manager. It has a lot of bells and whistles I didn't need --- but it was the most effective tool I could find to get the job done. Be a simple reference, and keep track of calories each day.

While I couldn't keep track of my caloric intake in HealthVault, I could keep track of my weight -- which I did with a combination of the AHA application and the Vista Weight Gadget.

Phase 3 - Sticking with it

Finally I was making progress ... losing a few pounds a week and feeling pretty good about it. But I noticed that my enthusiasm for the exercise was flagging, and that was clearly helping keep the momentum going on the weight loss front. Not by itself, but together with the calories I was doing well.

Enter RouteTracker -- my favorite HealthVault application out there so far (although I may have to do another survey ... we announced a bunch of new ones today and PodFitness in particular looks pretty sweet). I wrote a bunch about RouteTracker already, so I won't do that again.

But I will update you on my DisneyWorld-to-Disneyland progress ...I am currently in Denham Springs, Louisiana ... just passed by Lake Pontchartrain of Hurricane Katrina infamy. It looks like a beautiful place -- named for the mineral springs nearby that folks used to use to try to cure Yellow Fever.

I continue to be impressed with the ability of this application to keep me engaged ... the whole time I'm running, I'm looking forward to seeing where I'll end up next. The hardest part is not spoiling things by peeking ahead.

Phase 4 - Hey, I made it!

So, a few months later here I am at 165 pounds ... pretty cool, except that I had to buy new pants which was a pain. Realistically -- in 3-4 years I'm probably back where I started. But hey, better to yo-yo a bit than just stay huge.

Three main conclusions: First, counting calories works way better than crazy stuff about carbs or grapefruit or whatever. It's pretty easy once you get into a routine, and it just makes sense ... energy in, energy out.

Second, exercise does help. Doesn't make me lose weight, but does keep up momentum and definitely makes me feel better. Still hate it though.

Last ... the real key for me? Measure everything! Use my stable of HealthVault applications, see progress (good and bad), use my data across applications, and just be cognizant of where I stand. This seems to have been the real thing. Otherwise, it's really easy to let a few days go by on the exercise, have a few extra snacks, and just not really notice.

Not world-changing observations perhaps -- but twenty-five tubs of Crisco later, they worked for me!

Nice Problems to Have

A couple of days ago, we announced that we've expanded the size of the Be Well fund to $4.5 Million ... a 50% increase over what we had planned. We received almost 200 entries, making Be Well one of the most successful programs in Microsoft Research history. Too cool!

Be Well is a search for "champions" -- folks who have a vision of how HealthVault can be used to create something really transformative. We discovered that there are tons of folks out there with great ideas -- using mobile technology, devices, doctor-to-patient connectivity, collaborative analysis, you name it. The judges are going to have their hands full picking winners, even with the expanded grant pool -- a nice problem to have!

We'll be announcing the winners at the second annual HealthVault Solutions Conference in a couple of weeks. I'd encourage you to sign up and come in person, but that's our second "nice to have" problem -- we are way overbooked. Enthusiasm and momentum for HealthVault is huge and growing ... it is hard to keep up. Still haven't finished my slides for the architecture session -- Melissa, I swear I'm almost done!

As the ecosystem matures, we're also starting to see a talented set of third party development consultants add HealthVault to their portfolios -- so more of those "champions" can connect to HealthVault, even if they don't have the in-house technical resources to do so on their own. All of the folks in the directory have shipped HealthVault code, so you can be confident you're working with a partner who has "been there" before.

Lastly --- another turn of the HealthVault crank is on tap for late June ... we'll be announcing a number of new features at the partner conference, and more will make their way quietly into our development docs and Eric's great blog. I'm particularly excited about some new stuff targeted at employers and other groups that want to help their memberships get and stay healthy... ssshhh!

Get Educated!

I realized the other day that I haven't ever focused much on our search application here. But Live Search Health is a super-important part of the HealthVault ecosystem -- and something we've spent a bunch of time working on.

It's inescapable that pretty much everything online starts with search today. The same goes for health -- but when we started thinking about the problem a couple of years ago, the results for health searches really didn't deliver. We saw two things happening, neither optimal.

On the Google side, you got all the great breadth of content that the web offers. And this is key stuff, because the best health information is super-personalized ... not just how to live with lupus, but how to live with lupus when you like to ride horses and eat out a lot. But people felt overwhelmed. What to trust? How to get started? These are complicated topics that need some context.

WebMD is the flip side of this picture. They provide great context -- their "walled garden" of content keeps the chaos at bay, and the information is clearly attributed and vetted. But when we talked to people -- they were left wanting more. Once they felt grounded in topics, the walled garden simply didn't provide the breadth to get to that super-personalized content.

We specifically designed Live Search Health to deliver the best of both of these approaches. First, we help give people the context they need. The technology we acquired from Medstory automatically creates a "dashboard" of concepts related to a search. The dashboard allows people to quickly refine their query, but we also found that it had an even more powerful effect. Just seeing the landscape of related concepts help people feel more grounded and gave them a sense of "place" to get started.

Armed with that landscape, we deliver a small set of key "overview" articles right on the results page. These articles serve a very specific purpose: get you educated about the basics of your search topic, without having to click away from your results. We've chosen content providers from a number of different perspectives, ranging from the Mayo Clinic, to the National Library of Medicine, to alternative medicine experts like NCCAM and community-oriented sources like Wikipedia -- so users can pick the sources they're comfortable with.

Next on the path is web results -- the full breadth of the web, with all of that personalized content. The Medstory technology helps suppress commercial spam from the results, but we're not censors here. We believe that by the time the user gets to web results at Live Search Health, they're ready to dig in.

Finally, we realized that health searchers don't just need to learn about their conditions -- they need to do something about them. So we're working really hard to build connections to relevant HealthVault applications and services. This is where we really change the game -- helping people learn, and then giving them tools and options to take real action.

There's all kinds of other things to talk about with Live Search Health -- our great privacy policies that make it safe to search about the most sensitive topics without worrying about who's watching over your shoulder, and the HealthVault Scrapbook that lets you securely store and share the results of research. But I'll leave those for another post because it's late and I'm running out of steam.

Next time, I'll talk a bit about the fun search widget I just put together -- you can see it running on the right side of my blog where it says "get educated about..." -- I'll describe how you can easily add the widget to your own blog or sites, and help your users learn more about the topics that matter to them.

As always, thanks for reading ... there's just so much great stuff to talk about.

HIPAA-potamus

In one of those classic if I had a nickel things ... you have no idea how many times I get asked if HealthVault is "covered" under HIPAA.

The short answer to that question is, very simply, NO. HealthVault is neither a covered entity or business associate as defined by HIPAA. But the more complete answer requires a few more words.

HIPAA was designed to regulate the flow of health information when it is out of the patient's direct control -- for example, when it is forwarded to third-party billing services by a provider. At the same time, the HIPAA authors recognized clearly that patients have a right to a copy of their own information, and they built into the legislation an explicit mechanism that allows for patients to request and receive that copy.

The obligations that HIPAA places on covered entities and business associates do not apply to the copy under the patient's control, because the patient is in the best position to decide which parts of their information they want to share, and with whom they want to share it.

HealthVault is, very simply, a tool for individual patients to manage health information that is under their control. The rules and choices around how that information is shared are under the exclusive control of the patient. When information is sent from a covered entity into a HealthVault record, it is done at the explicit request of the individual.

We believe strongly that not only is this approach completely in line with the intent of HIPAA regulation, but it is essential in order for patients to truly be empowered with their own information.

So is this a "get out of jail free" card for HealthVault? No way -- the obligations we have taken on around patient privacy, data security and third party audits are frankly far more stringent than those that HIPAA-covered entities are required to adhere to. And if we don't deliver on those obligations -- we're out of business. That's a pretty strong motivation for us to do a good job.

Together with our legal team, we finally got our act together to publish a position paper that describes in detail why our assessment here is correct. If patient privacy is your thing, I encourage you to check it out.

Once again, our cards are on the table -- and we are confident we are doing the right thing. If you have any questions, ask them here and I will do my best to get a clear answer.

King of the Road

My Dad was a big runner for most of his adult life. When I was pretty small, I stood at the Boston Marathon finish line watching him come into sight -- he had this wobbly-armed gait that was unmistakable even from a huge distance. These days his knees keep him from running, so he's just shifted to his bike, both in the real world and these insane spinning classes he loves.

And that's the weird thing -- he really loves exercising hard. For a few years as a kid I would get up before school and run with him. I liked spending time with my dad, but mostly I remember thinking that running really, really sucked.

Fast forward to 2008. I'm working long hours on a new product, solving hard problems and generally having a great time. As always happens to me in this mode, I eat lousy, don't get the sleep I should and basically don't exercise at all. So I start packing on the pounds -- but unlike at my other startups, with this one I'm continually reminded of how this behavior is going to kill me.

So OK, a few months ago I decided that despite my inclinations to the contrary, it was time to get in shape, push down my blood pressure and lose at least some of my pot belly. And I've been pretty good about it, using my treadmill and rowing machine a few times a week and adding in some strength training. And yes, I feel better for doing so.

But the fact is, it still sucks. I am just not wired for the "runner's high" or whatever those nut jobs call it. So I welcome anything that breaks the monotony and distracts me from the reality that I am forcing myself to work really hard for no immediate benefit.

Enter Route Tracker -- quietly launched a couple of weeks ago by MSN Health & Fitness, it is one of the coolest examples yet of the kind of innovation that HealthVault makes possible. I absolutely am in love with this thing.

Route Tracker is all about giving you a fun payoff for sticking to an exercise program. First you define a virtual trip -- you can pick from a list of preset trips or create your own using the "driving directions" feature of Virtual Earth. I created a trip from the castle at Disney World to the castle at Disneyland -- 2,595 miles across the country East to West.

Now, every time I travel a mile in the real world, I travel five miles on my virtual trip (I used a "boost factor" of 5x to move along the route a bit more quickly). Route Tracker maps my progress, and along the way shows me pictures, news and web results from all of the places I travel. Because it's integrated with Virtual Earth, I can see where I "am" with satellite imagery, birds-eye photography and even 3D visualizations. Check out these totally cool screenshots from my "castle-to-castle" trip!

Currently I am in Malbis, Alabama ... which I now know is home to a beautiful Greek Orthodox church. My next run should take me most of the way across the bridge over Mobile Bay.

This is one of the neat things about HealthVault. I am tracking my exercise, weight and such in the American Heart Association application and with the HealthVault Weight Gadget. But because these are all HealthVault applications, I automatically can use that same information in Route Tracker to travel along my virtual journey.

Pran and Matt did a great job on this application -- I have been waiting for it to go live for a long time, and it is just a whole bunch of fun. Lots of new features are in the works too -- including the ability to create virtual competitions where you can challenge friends from across the country to join in.

Give it a try yourself -- and let me know where you're travelling!

Totally Wicked

Having lived away from Boston now for about twenty years, I've slowly lost most of my Boston habits. I signal when I change lanes, and even caught myself calling Fluff "marshmallow creme" the other day. But the one thing I've never shaken is an affinity for the word "wicked" ... too often used in the embarassing combination "wicked awesome".

Last week Frost & Sullivan announced that HealthVault is being named their 2008 Global Healthcare Information Product of the Year, saying that the information sharing we enable is "slated to revolutionize the future;" that we have the potential to "improve doctor-patient relationships;" and that "HealthVault ensures complete control over personal health management and provides the consumer with a long term solution to improving overall wellness."

This is
totally
WICKED!

And Now for a Little Usability

It took a lot of people coordinating a whole bunch of different efforts to get the first release of HealthVault out the door. On top of the core platform, we were creating an SDK and developer experience, integrating with the LiveID system, building a desktop application, establishing a new driver model for devices, buiding a new search application (and integrating it into Live Search), crafting an effective privacy policy together with consumer advocates, and working with dozens of external partners to help create their own applications. Just another day at the office.

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.

Digital Signatures

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.

You let marketing host your blog?

OK, this is not my shining moment. But yes, when we set up Family Health Guy, the HealthVault marketing team offered to get it going, and I was kind of busy. So everything got put together and I happily posted away for a couple of months ... until this weekend when the server went DOA. I felt it better not to ask for too many specifics about what happened.

Suffice to say that I have moved to a new home here at MSDN. For now, the template is pretty uninspired, but I will sleep better at night with it set up this way. I would certainly appreciate it if you'd update your newsreaders to use the new RSS or Atom feeds over to the right ... thanks for sticking with me during the transition.

And now, back to business!

Springtime in Seattle: check out the 2008 HealthVault Solutions Conference!

Way back when I was a Microsoft intern working on a precursor to the Jet database engine, my then-girlfriend-now-wife came out from Florida to visit for a few days. This was a big deal as I was hoping to convince her that Washington would be an "awesome" place to live, despite her knowing exactly nobody within about two thousand miles. So I splurged and we stayed over the weekend at the Bellevue Hyatt. At the time the Bellevue Square Mall was about the only entertainment in town, but it must have worked to some extent because here we are almost twenty years later.

I haven't stayed at the Hyatt since (I don't think... there may have been one time the power was out in the winter but I'm not sure). But in a couple of months I'll be back, and I'm hoping you'll come and join me.

June 9-10 of this year, we're hosting our 2nd annual HealthVault Solutions Conference ... the first one was pre-launch and so had to be done under NDA, but this time it's wide open (Google, are you listening? Jerry? Bueller? Bueller?). You can register online and find out more details here using the code MSHV08. As they say, space is limited so get registered and come on down.

Totally cool --- Dr. Mehmet Oz is going to keynote the conference. Dr. Oz has written a bunch of great books, appears reguarly on the Oprah Winfrey show, does incredibly innovative work at New York Presbyterian Hospital and Columbia University, and ... way too much for me to list here. We are honored and excited to have him come and talk about his vision for healthcare.

We're going to run a business and a technical track (details are all here) -- I will be doing an architecture overview on the technical side Tuesday morning (another chance to face my agoraphobia). There will also be plenty of time to talk to both the HealthVault team and other folks that are building great stuff as part of the HealthVault ecosystem, see a bunch of demos, hear more about the Be Well Fund, and lots more.

It is shaping up to be a really great event -- I'm hoping to answer a lot of questions and learn a lot about what our partners need to be successful. I hope you'll come by and say hey.