More Designing for Privacy: Microsoft HealthVault

Similar to my recent probes and interactions with the designers of the social networking site Moli, I recently enjoyed the opportunity to discuss privacy-related design issues with the product manager for Microsoft’s HealthVault platform.

HealthVault is Microsoft’s attempt to provide an online platform where personal electronic health records can be stored, managed, and shared with various healthcare providers. HealthVault also features a topical search engine allowing users to search specifically for health-related information (Microsoft will use sponsored search ads on the search engine to monetize the HealthVault platform). Microsoft’s press release launching the service last fall can be found here; it has been covered by the New York Times, Washington Post, BusinessWeek, etc.

Any attempt to aggregate and store personal medical data online is fraught with privacy issues, and HealthVault has attracted its fair share of criticism and concern (especially given the bad taste Miscrosoft’s Passport/Hailstorm efforts left in privacy advocates mouths).

Some of the privacy concerns that immediately come to mind include:

• How secure are the personal health records stored online?
• Who has access to the data and under what conditions?
• Will users’ data be aggregated, data-mined, monetized, or sold?
• Are users’ health-related search queries logged?
• Are users’ clickstream activities on HealthVault logged?

Microsoft, of course, has been paying attention to all of this, and they’ve been trying to address HealthVault’s privacy-related issues through various policy, marketing, and design decisions. It was under this auspice that I met with HealthVault platform’s Product Manager George Scriban to share ideas about health privacy generally, and HealthVault specifically. Here’s some of what I learned Microsoft is doing to address the privacy issues surrounding HealthVault:

• To help protect user privacy, all search activity on HealthVault’s search engine is encrypted via HTTPS. This helps provide some security from having health-related searches viewable by employers or other network providers, in much the same way passwords are encrypted as they move across the Internet.
• Compared to many traditional search engines, where the sponsored ads are personalized and/or contextually tied to the specific search terms, the sponsored ads that subsidize HealthVault searches are only “bluntly targeted.” This is done by mapping the concepts that appear on top search result pages, and then targeting the ads to those concepts. For example, a search for “HIV and pregnancy” might provide results dealing with the broader concepts of sexual health and prevention. It is these concepts that trigger certain ads to be displayed, not the original search term. As a result, there is less motivation to track and log the specific search terms that might be more personally sensitive.
• Traditional search engines often go to great lengths to help understand the purpose and intent of ambiguous search queries, typically through the logging of search activities. For example, a simple search for the term “cold” could refer to an upper respiratory infection, a climate condition, or an emotional stance. By logging and comparing previous search activity, search engines can try to predict what the user actually was looking for. But with a health-specific search engine, it is much more likely the user is seeking medical information about the common cold. Given this drop in search term ambiguity, HealthVault’s search engine cookie only retains query data per session (the tracking cookie expiries if you close your browser or visit a different web page).
• Similarly, the more persistent cookies related to the search engine in HealthVault expire after 90 days. And their server logs, which might also contain clickstream data they store (to monitor interface usability, clicking of sponsored ads, etc), are destroyed after 90 days.
• Regarding users’ health records, they are given full control over what information is stored on the system, who can access it, and what they can do with it. Microsoft wil make themselves available for audits to ensure compliance with their privacy policies.
• Given that third-party applications will be built on top of the HealthVault platform, Microsoft’s goal is to make this much more transparent than similar execution on sites like Facebook, where users don’t really know what information applications are accessing or what they are doing with it. HealthVault provides the ability to see how a users’ individual health records have been accessed and used. If a user uploads a piece of health information, they can use a control panel to see who has accessed the data (only people they authorize can do so), when they accessed it, and what was done with it, whether it was modified, and so on.

I must note that I haven’t been able to verify these technical claims, and my research in this area is only beginning — many other harms could remain even if all the above are fully implemented. But if the above steps can be validated, it appears the developers of HealthVault have taken Microsoft’s “Privacy Guidelines for Developing Software Products and Services” to heart, and have consciously designed HealthVault to protect user privacy.

::

UPDATE: Fred Trotter provides the right kind of push-back on Microsoft’s claims I detail above. He also notes that my fellowship at the Yale ISP is funded by Microsoft. I should have provided this disclaimer earlier:

Microsoft is a funder of the Information Society Project (ISP) at Yale Law School, and their grant pays for my fellowship there. I can safely say that I have not personally felt any pressure or influence by Microsoft on my scholarship (or my blog posts).

Also, I don’t know if my being the “Microsoft Fellow” actually granted me any special access. The invitation I received from Robin Bender Ginn, from MSFT’s PR firm Edelman, seemed quite generic, identifying me as a “recognized technology privacy leader,” was sent to my blog e-mail (not my Yale account), and didn’t mention the relationship between ISP and MSFT. It honestly felt like the kind of invitation they probably sent to a dozen like-minded scholars/bloggers. I noted the connection between MSFT and the ISP in my reply, but I don’t know if they were aware of it beforehand.