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:

**

• No 3rd-party applications may automatically read or write data to my record, except for my physician’s EHR, and that application may only write medication prescriptions and records of my office visits. (Note: this level of access control would be available for optional data items)
• Regardless of what 3rd-party application is used, only myself, my family members and physicians may read the contents of my record. Only my daughter and myself may write contents to my record. (this level of access control would not be available for optional data items either)

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.