Difference between revisions of "Microsoft HealthVault"

From Clinfowiki
Jump to: navigation, search
(References)
(Integration with PHAs, medical devices, and electronic health records (EHRs))
Line 2: Line 2:
  
 
== Integration with PHAs, medical devices, and electronic health records (EHRs) ==
 
== Integration with PHAs, medical devices, and electronic health records (EHRs) ==
To encourage integration of PHAs and medical devices with HealthVault, Microsoft provides developers with a free software development kit (SDK) and has published the APIs for HealthVault.  The HealthVault API is accessible from programming environments including  Microsoft .NET, Win32, Java, and PHP. HealthVault currently supports only Web applications, but support for client applicaions is being considered for the future.  Microsoft does not host third-party applications that have HealthVault interfaces.  Instead, developers host their own applications and create their own business models.
+
To encourage integration of PHAs and medical devices with HealthVault, Microsoft provides developers with a free software development kit (SDK) and has published the APIs for HealthVault.  The HealthVault API is accessible from programming environments including  Microsoft .NET, Win32, Java, and PHP [4]. HealthVault currently supports only Web applications, but support for client applicaions is being considered for the future.  Microsoft does not host third-party applications that have HealthVault interfaces.  Instead, developers host their own applications and create their own business models.
  
 
Microsoft has already partnered with a number of medical device vendors to allow information to be uploaded to HealthVault.  The end user achieves device integration by going to the Connection Center on the HealthVault website. Devices include monitors for blood pressure, heart rate, and glucose from manufactures including Omron, Microlife, Lifescan, and Polar.
 
Microsoft has already partnered with a number of medical device vendors to allow information to be uploaded to HealthVault.  The end user achieves device integration by going to the Connection Center on the HealthVault website. Devices include monitors for blood pressure, heart rate, and glucose from manufactures including Omron, Microlife, Lifescan, and Polar.

Revision as of 11:56, 13 November 2007

On October 4, 2007, Microsoft(R) Corporation released Microsoft HealthVault [1,2]. Microsoft has taken pains to clarify that HealthVault is not intended to be a personal health record (PHR), but instead will be a platform that could service numerous personal health applications (PHAs). Microsoft's clout has generated a great deal of excitement (mixed with some concern) in the PHR community. Microsoft's plan for a secure, interoperabile plan appears more robust than previous failed efforts from vendors, but broad user and developer acceptance of the platform remains to be seen. The upcoming announcement of Google Health in early 2008 [3] may also disrupt Microsoft's plans.

Integration with PHAs, medical devices, and electronic health records (EHRs)

To encourage integration of PHAs and medical devices with HealthVault, Microsoft provides developers with a free software development kit (SDK) and has published the APIs for HealthVault. The HealthVault API is accessible from programming environments including Microsoft .NET, Win32, Java, and PHP [4]. HealthVault currently supports only Web applications, but support for client applicaions is being considered for the future. Microsoft does not host third-party applications that have HealthVault interfaces. Instead, developers host their own applications and create their own business models.

Microsoft has already partnered with a number of medical device vendors to allow information to be uploaded to HealthVault. The end user achieves device integration by going to the Connection Center on the HealthVault website. Devices include monitors for blood pressure, heart rate, and glucose from manufactures including Omron, Microlife, Lifescan, and Polar.

One of the most exciting aspects of HealthVault is Microsoft's explicit commitment to creating data exchange interfaces that are compliant with standards such as the HL7 Continutiy of Care Document (CCD) and the related ASTM Continutiy of Care Record (CCR). This provides the potential for true interoperability among PHAs and electronic health records (EHRs). However, it is well recognized that standards such as these accomodate a great deal of latitude in encoding data. Thus, two systems can be entirely compliant with CCD and CCR and still have very limited ability to parse each other's content.

Microsoft's entry into the arena is likely to set more restrictive de facto standards for encoding data, much as Microsoft Word has become a de facto standard for encoding word processing data. This is a double edged sword. Microsoft's more restictive standard could become a lingua franca among PHAs, devices, and even EHRs. On the other hand, Microsoft's history of incorporating, then modifying, extending, and co-opting standards (such as Java) brings Microsoft's ongoing commitment to community-derived terminologies and messaging framerworks into question.

Security issues

To ensure private and secure storage, Microsoft houses HealthVault "in the same secure data centers that run other Microsoft online services, but ...HealthVault traffic [is isolated] onto a virtually separate network servers [are located] in physically separate, locked cages" [4]. All data is encrypted on transmission, even inside the data center. A "minimal access data model" is used to constrain the data that is shared with other people, PHAs, and devices.'

Authentication is provided by Microsoft LiveID (the successor to Microsoft Passport). Third-party applications can use the software development kit (SDK) to inherit authtentication-protected pages. The authorization configuration of applications must be approved by Microsoft before the application goes live, to ensure that the data exchange is limited to the minimal set of data required by the application.

Authentication is relatively straightforward when HealthVault is used as a standalone PHR. It is straightforward to see how a patient can enter his or her own medical history, supplement it with data from a monitoring device such as a blood pressure montior, and use a third-party application registered with Microsoft to get personalized advice based on these data.

Authentication necessarily becomes more complicated for true interoperability, such as exchanging data with a health care organizations's electronic health record (EHR). The health care organization would need patient users to register their HealthVault with their own systems in some manner. Interaction could then occur in one of several ways:

  • the health care organization could accept LiveID as authentication
  • the health care organization could require its own authentication for patient users and require a seperate sign-in to LiveId for online access to HealthVault information
  • the health care organization could require its own authentication for patient users, and arrange for offline access to HealthVault information

Business model

Microsoft plans to monetize HealthVault based on its search engine (HealthVault Search). Queries may be directed based on personal health content stored in HealthVault. However, since some patients will be sensitive about receiving disease-targeted commerical content, users will be given the option of not passing on health information to HealthVault search.

HealthVault is currently only available for users in the United States.

Benefits and concerns

Microsoft reports a commitment to interoperability with a multitude of applications and devices by creating interfaces that are compliant with standards such as the ASTM Continuity of Care Record (CCR) and HL7 Clinical Document Architecture (CDA). However, it is well recognized that standards such as these incorporate a great deal of latitude in encoding data. Thus, two systems can be entirely compliant with these standards without being able to parse each other's content.

Microsoft's entry into the arena is likely to set more restrictive de facto standards for encoding data, much as Microsoft Word has become a de facto standard for encoding word processing data. This is a double edged sword. Microsoft's more restictive standard could become a lingua franca among PHAs, devices, and even EHRs. On the other hand, Microsoft's history of incorporating, then modifying and co-opting standards (such as Java) creates concern about Microsoft's commitment to interoperability using community-derived terminologies and messaging functions.

References

(1) HealthVault site: http://www.healthvault.com/

(2) HealthVault press release: http://www.microsoft.com/presspass/events/healthvault/default.mspx

(3) http://www.microsoft.com/presspass/events/healthvault/docs/HealthVaultFS.doc

(4) http://blog.seattlepi.nwsource.com/microsoft/archives/123039.asp

(5) http://www.informationweek.com/news/showArticle.jhtml?articleID=202404027


Stephen E. Ross MD University of Colorado - Denver School of Medicine