Sean Nolan has announced that Microsoft has placed the HealthVault API specification, under the Microsoft Community Promise (CP) at the time of the writing, this page has not been updated to list the HealthVault API, but the text is provided in the specification download. This may allow for FOSS implementations of HealthVault.
The Microsoft CP is not the same as Microsofts Open Specification Promise (OSP). That is problematic because the Open Specification Promise is already doubted by the larger FOSS community, and the CP seems even more limiting.
Most notably the CP is different from the OS (from the CP FAQ):
The CP requires that implementations conform to all of required parts of the mandatory portions of the specification. Also, in specified cases (such as where the specifications have uses that exceed those needed to achieve the interoperability needs for which the release under the CP is being made), the CP may have special terms concerning what kinds of implementations are covered.
and
The CP applies only if the implementation conforms fully to required portions of the specification. Partial implementations are not covered.
The CP for Healthvault does have special terms (from the specification download)
Community Promise Restrictions on the Field of Use for the HealthVault Service Specification
HealthVault Service Specification is intended to support personalized healthcare. This technology is designed to be used by individuals to manage their health information, and is not intended to be provider-centric or health enterprise-centric.
That is a problem for projects like Tolven, which is a combined PHR/EHR system. If the PHR component of Tolven were to implement the HealthVault API,would the CP still be ineffect? In Tolvens architecture, the PHR and EHR are based on the same database. While Tolvens PHR is patient centric, the EHR is user centric.
Further it is not defined, as far as I can tell, what a ‘full’ vs. ‘partial’ implementation means. I could create an implementation of the web service calls for HealthVault over a long weekend, by stubbing everything. Now, my system would be a complete implementation from the protocol perspective, every call made to HealthVault would also work on my system, but nothing my system did would have any meaning. It would be much harder to implement things so that they conformed to the specification and actually worked (as opposed to merely appearing to). We might call an implementation that had no stubs and instead contained attempts at real working parts a ‘robust implementation’. But even a robust implementation would have bugs. It would typically work just like HealthVault, but sometimes it would behave differently, mysteriously.
Those ‘differences’ are what programmers like me might call a ‘bug’. But would an implementation with bugs fall under the Microsoft CP?
More importantly, who decides if an implementation is buggy? HealthVault is still labelled as ‘beta’ and it is entirely possible that if HealthVault and a FOSS implementation of the HealthVault API worked differently, it would be because HealthVault had moved past its own specification.
At this point, I cannot recommend that anyone implement this API. There are too many unanswered questions here.
Having said that, Microsoft is obviously trying to open up with HealthVault. I hope to convice them that the OSP is a better vehicle, but this is a step in the right direction. So far Google has released no information on the rules for re-implementing the Google Health API. At this point, Microsoft is (surprisingly) more open than Google.
-FT