Google Buzz & Your Digital Health Doppelganger

A Couple Meeting Their Doppelgangers - Painting by Dante Gabriel Rossetti entitled "How They Met Themselves", Courtesy of The Athenaeum

At this point, it is fair to say that everyone has either heard or read about how Google’s latest foray into social networking, Google Buzz, has gotten off to a bumpy start due to privacy concerns. We can only speculate as to why Google failed to appreciate Buzz’s underwhelming privacy protections. Maybe Google was aware of the privacy issues but felt that they were outweighed by the “turn key” social network that would automatically be created by leveraging the user’s own Gmail contact list. Alternatively, Google may have simply not appreciated the privacy issues. Whether Buzz’s threats to privacy justified the immense firestorm that has occurred is besides the point. Regardless of whether the privacy issues are justified or not, as consumers utilize social networking tools to a greater degree, they are becoming more aware of the potential privacy problems, and are becoming more vocal when they disapprove.

One of the more troubling aspects of Google Buzz was that  it automatically created a network of users in your Buzz social network based on the addresses you emailed most in Gmail. Buzz would then automatically start following those contacts. The issue was compounded by the fact that Google made the list of people you were following on Buzz public by default. This automatic follow-and-tell-the-world approach that piggybacked off of Gmail users’ contact list has since been tweaked. Currently, a user joining Buzz is offered suggestions of who to follow, and those whom they choose to follow are not broadcast for the world to see.

A hypothetical within the health care setting may serve to illustrate why this approach was problematic, and will also illustrate why social networking may have profound implications for our “digital health doppelganger.” Under the initial iteration of Buzz, physicians using Buzz who were following the Buzz feeds of their patients would, simply by using the service, make the names of who they were following public to all their other followers.  In other words, a patient could see the names of all the individuals that their physician was following, including any who happen to be patients.  This situation could be disastrous both personally and economically if the individual was being treated by a physician specializing in schizophrenia or HIV/AIDS–diseases that have, for whatever reason, become highly stigmatized and prone to various discriminatory responses. It is therefore clear that myriad privacy and confidentiality issues arise, including questions of whether such information would be considered protected health information under HIPAA. That the disclosure of fiduciary relationships is troublesome is nothing unique to health care: in the legal profession, the mere existence of an  attorney-client relationship can be considered privileged information.

But back to Health IT, an area where  our digital health doppelganger is progressing through its adolescence in a landscape of social networks, electronic health records, and a highly fragmented health care delivery system. A number of general areas of concern arise. Including:

1) the online storage of our personal sensitive health information (e.g. in EHR and PHR databases, and Law Enforcement and “Fusion Centers”).

2) current modes of interfacing with our online health data (e.g. access viz. home computer, mobile phone, kiosks).

3) future modes of interfacing with our online health data (e.g. increasing mobile use, RFID, Smartcards, video playback of encounters).

4) how others will access and use our online health data (e.g. Primary care physician accessing our PHR, Site-wide access by Accountable Care Organizations, targeted advertising in PHRs based on the content found within the PHR service or services it can connect to).

5) how we will interact with the health data of others (e.g. PatientsLikeMe.com, increasing meta-analysis of health data available through future nationwide interoperable EHR systems).

6) how our increasingly digitized health care persona will exist alongside our professional and social personas.

Google and  Microsoft offer immensely useful services, but which concomitantly force us to more deeply analyze these issues, particularly the last issue, which both feeds back, and is affected by, each of the other issues. More than any other company, Google has sought to integrate their products to make communication and organization as seamless as possible. For example, The to-do list in Google Tasks is, not surprisingly, symbiotic with Google Calendar, while the latter service interfaces with Gmail by scanning the content of a user’s email for the tell tale signs of future events, and and offering to add a calendar entry.  For those of you not using Google, the right portion of the picture below illustrates how Google recognizes the contents of the email message, and asks the Gmail user if she wants to add the event to their Google Calendar.

An Example of Google's Integration of Services. Notice how Gmail has scanned the content of the message, and on the right, asked the user if they would like to import it into Google Calendar. Photo From Google Operating System Blog

The simple example above makes it easy to imagine similar features being offered in PHRs like Google Health and Microsoft HealthVault–PHRs that are provided by entities that either offer social networking tools alongside their PHRs, or who plan to somehow utilize outside data that is available through other means.  As consumers, we must determine how precocious we want our online health persona to be. It must be noted that there is nothing intrinsically wrong with this integration, and such integration certainly offers many benefits to providing better information to patients and physicians.

However, both Google and Microsoft are unique in that they are introducing personal health records to their users who have already ceded to them an extraordinary amount of highly personal information.  This raises interesting questions that will test our willingness to integrate our social network with our health identity. For example, how should Google Wave–Google’s new hybrid email/chat service–be interfaced with Google Health? Furthermore, what status will a physician-patient conversation thread on Google Wave or Google Buzz be provided? Is it more like a health record or a phone conversation? Would it be acceptable for Google Health to utilize health related information that it recognizes within your Gmail messages? Even though Google has refrained from displaying targeted ads within Google Health, would the reverse be acceptable, whereby Gmail advertisements are determined based on Google Health data?  Would it be inappropriate for Google Health to utilize information about your newly diagnosed diseases  to connect you to health-related social networks such PatientsLikeMe?

Users are likely to forget about Google Buzz’s initial oversights, especially in the short-attention span sphere that is the Internet. This is okay, so long as changes are made to appropriately address such glaring issues. We must, however, ensure that we tackle the much more difficult question of what limits to place on the subtle, yet no less powerful, forces that are altering the breadth of our increasingly digitized and integrated online persona.  For many of us, the personality of our digital health doppelganger is taking shape on our screens and our smartphones. Are we going to like what we see? And perhaps more importantly, will others?

HIPAA, The HITECH Act, and How Google May Still Be Able to Distribute, and Profit From, Your Personal Health Info

Photo by Jonathunder

Below I will explore what seems to be a gaping hole in the HITECH Act. However, as with any new legislation, it is often necessary to reexamine the laws that preceded it, which in this case is HIPAA.  This is particularly true given that the HITECH Act does not replace HIPAA. Rather, it provides–amongst other things–additional security and privacy safeguards with respect to health information. To that extent,  at least a cursory reexamination of HIPAA is required before understanding HITECH and the importance of comprehensive legislation.

HIPAA was a product of the 1990’s–an era triggering nostalgic memories of grunge music  for some, and the (in)famous Macarena dance for others. For a large part of this period, the Internet was accessed by a handful of tech savvy individuals who dialed into services like CompuServ, Prodigy, and AOL.  It was during this transition that Congress felt the need to make health insurance more portable, as well as standardize the variegated electronic systems that were conducting nonstandard healthcare-related transactions. There was a concomitant concern that health information needed better protection. Thus, in 1996 Congress adopted the Health Insurance Portability and Accountability Act (HIPAA), providing HHS with the responsibility to enforce it. However, the regulation enforcing privacy and security of health information would not be implemented until years later.

HIPAA’s Privacy Rule, which describes the appropriate use and disclosure of certain health information, came into force on April 14th, 2001, updated in 2002, with compliance required by April of 2003. The Security Rule, which establishes the policies and best practices for securing health information, came into force in 2003. Thus, the Privacy and Security Rules (referred to below as HIPAA) came to life in a period of technological transition. New technologies like residential broadband Internet access and Wi-Fi networks were becoming the norm. Electronic Health Record (EHR) systems had been developed, but had only marginal penetration within certain academic medical centers and government entities. Consequently, the threats to patient privacy from early EHRs was much smaller than it is today, since these systems were not widespread and did not often share data over disparate regions. Thus, access to the systems was not necessarily available outside of the intranets where the servers were located.

Acronyms of HIPAA & HITECH

d

Given the historical context of HIPAA’s passage, it is easy to appreciate HIPAA’s missteps in not specifically  focusing on EHRs or PHRs.  Rather, HIPAA regulates protected health information at a broader level, focusing primarily on the “use and disclosure” of PHI by CEs, and the best practices and policies for securing the PHI itself.   To be fair, the Security Rule does focus on PHI that is stored and transmitted electronically. However, even the most stringent best practices and policies are useless if the corresponding privacy regulations are inadequate.

But the times they are a-changin’–sort of.

Buried on page 112 of the American Recovery and Reinvestment Act (ARRA)–also known as the Stimulus Bill–is Title VIII of the bill, known as the Health Information Technology for Economic and Clinical Health Act, or more commonly, the HITECH Act. One (of the many) purposes of the HITECH Act is to fill in the gaps that have emerged since the Privacy and Security rules came into force.  But like before, we are in a transition period. Whereas HIPAA’s passage coincided with a period of generalized transition towards digital information, HITECH has coincided with its own transition: the implementation of personal health records (PHRs). Unfortunately, the current HITECH Bill and regulations have serious flaws in how they protect patient information stored in PHRs. However, before discussing the problems, it is only fair to discuss the benefits to privacy and security that HITECH’s passage has provided.

Specifically, HITECH introduces breach notification requirements. HITECH’s provisions govern the procedures which CEs and BAs must follow if health information has been compromised. HITECH also empowers the FTC to promulgate regulations pertaining to the notification procedures of PHR vendors (as well as those who offer services to PHR vendors). The FTC’s proposed breach notification requirements can be found here. Thus, CEs, BAs, and PHR vendors are, for the first time, required by law to notify individuals if their unsecured PHI has been accessed by unauthorized individuals.  Surprisingly, this was not required under HIPAA. CEs were obligated to notify individuals only insofar as the CEs were required by HIPAA to mitigate damages. But now, with the passage of HITECH, breach notification is no longer amorphous, but is spelled out in detail in HITECH’s regulations.

Additionally, HITECH requires BAs to abide by many of the same privacy and security requirements that CEs have had to abide by. Before HITECH, a BA, such as an attorney reviewing the PHI of a CE, was required to sign an agreement promising to protect the PHI that they were accessing, but were not themselves regulated by HIPAA. Thus, BAs had only contractual liability to the CE if the BA violated the rules of the agreement. On the other hand, if a CE violated HIPAA, it was subject to specific penalties and fines by the government.

Under HITECH, BAs must now comply with much of the Privacy and Security Rule, and face many of the same penalties and fines if they violate HIPAA regulations. That is, BAs are now accountable to the government if they improperly use or disclose PHI, or fail to adequately secure PHI.

HITECH also offers other benefits, such as increased enforcement of violations, a strengthening of the requirement that only the minimum necessary information is disclosed to other CEs or BAs, a more thorough framework of accounting for uses and disclosures, as well as a certain prohibitions on the sale of PHI.

The last benefit of HITECH–the prohibition on the sale of PHI–is a perfect springboard for discussing the potential pitfalls of HITECH. The benefits of HITECH may well be sufficient to shore up HIPAA’s gaps when it comes to regulating CEs and BAs. However, as HITECH’s regulatory language makes clear, there remains a gaping hole:

(d) Prohibition on Sale of Electronic Health Records or Protected Health Information-

(1) IN GENERAL- Except as provided in paragraph (2), a covered entity or business associate shall not directly or indirectly receive remuneration in exchange for any protected health information of an individual unless the covered entity obtained from the individual, in accordance with section 164.508 of title 45, Code of Federal Regulations, a valid authorization

The emphasis is added to underscore that PHRs are not included in this provision. There is no corresponding provisions in the FTC’s proposed regulations which concern breach notification. The upshot of this is that, as of the date of this posting, PHR services like Google Health and Microsoft HealthVault are not subject to this prohibition, nor is there a provision in HITECH mandating that PHRs comply with HIPAA’s Privacy and Security Rule. Therefore, PHR vendors can use, disclose–and possibly even sell–an individual’s health information outside of the HIPAA and HITECH regulations. This problem underscores a larger issue: PHRs are not regulated by HIPAA, and only regulated by HITECH insofar as the FTC’s interim rule requires certain breach notification procedures. Read more