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.
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.