Can Suspicious Activity Reports Trigger Health Data Gathering?

In an article entitled “Monitoring America,” Dana Priest and William Arkin describe an extraordinary pattern of governmental surveillance. To be sure, in the wake of the attacks of 9/11, there are important reasons to increase the government’s ability to understand threats to order. However, the persistence, replicability, and searchability of the databases now being compiled for intelligence purposes raise very difficult questions about the use and abuse of profiles, particularly in cases where health data informs the classification of individuals as threats.

First, a little background. We traditionally think of law enforcement as needing some kind of probable cause to ground or justify the pursuit of an investigation. However, with the rise of the new Information Sharing Environment (often enacted by fusion centers, which provide one-stop shopping for access to data), a much broader set of law enforcement prerogatives is emerging. Fusion centers have promoted a domestic intelligence apparatus, which is designed not merely to solve crimes but also to generate a wide range of knowledge which could lead to the deterrence and detection of “all threats, all crimes, all hazards.”

The Department of Homeland Security has taken a number of innovative steps to deputize monitoring of individuals, asking personnel ranging from local law enforcement to cable repairmen to hotel cleaners to be on the alert for suspicious activity. Once such activity is detected, the detector can in some cases file a persistent Suspicious Activity Report. These SARs are entered into an FBI database, and quite possibly inform many other counterterror, intelligence, and even private sector initiatives. Arkin & Priest’s story gives a sample Suspicious Activity Report, and speculates about how its creation may affect the object of the profile:

The FBI is building a vast repository controlled by people who work in a top-secret vault on the fourth floor of the J. Edgar Hoover FBI Building in Washington. This one stores the profiles of tens of thousands of Americans and legal residents who are not accused of any crime. What they have done is appear to be acting suspiciously to a town sheriff, a traffic cop or even a neighbor.

[For an example of what might go in the database, consider] Suspicious Activity Report N03821 says a local law enforcement officer observed “a suspicious subject . . . taking photographs of the Orange County Sheriff Department Fire Boat and the Balboa Ferry with a cellular phone camera.” The confidential report, marked “For Official Use Only,” noted that the subject next made a phone call, walked to his car and returned five minutes later to take more pictures. He was then met by another person, both of whom stood and “observed the boat traffic in the harbor.” Next another adult with two small children joined them, and then they all boarded the ferry and crossed the channel.

All of this information was forwarded to the Los Angeles fusion center for further investigation after the local officer ran information about the vehicle and its owner through several crime databases and found nothing. Authorities would not say what happened to it from there, but there are several paths a suspicious activity report can take:

At the fusion center, an officer would decide to either dismiss the suspicious activity as harmless or forward the report to the nearest FBI terrorism unit for further investigation. At that unit, it would immediately be entered into the Guardian database, at which point one of three things could happen:

The FBI could collect more information, find no connection to terrorism and mark the file closed, though leaving it in the database. It could find a possible connection and turn it into a full-fledged case. Or, as most often happens, it could make no specific determination, which would mean that Suspicious Activity Report N03821 would sit in limbo for as long as five years, during which time many other pieces of information about the man photographing a boat on a Sunday morning could be added to his file[.]

[That data includes] employment, financial and residential histories; multiple phone numbers; audio files; video from the dashboard-mounted camera in the police cruiser at the harbor where he took pictures; and anything else in government or commercial databases “that adds value,” as the FBI agent in charge of the database described it. That could soon include biometric data, if it existed; the FBI is working on a way to attach such information to files. Meanwhile, the bureau will also soon have software that allows local agencies to map all suspicious incidents in their jurisdiction.

Given the expansive reservoirs of data already accessible to fusion centers, I would not be surprised if they took the position that health records “add value” to the data gathering. Civil libertarians can object to many types of data gathering, but for purposes of this post, I would like to focus on healthcare data. First, to what extent can a health condition itself give rise to a Suspicious Activity Report? Secondly, are there any concerted efforts to deputize medical personnel to report on suspicious activity? Finally, and I believe most importantly, how is the vast store of healthcare data presently associated with individuals utilized by the data mining programs of the surveillance state?

We daily learn of troubling data gathering practices online. For example, Arvind Narayanan has described rather indiscriminate data gathering by third parties:

The Facebook “like” button is a prominent . . . example[] of third-party tracking not directly related to behavioral advertising. . . . Facebook can keep track of all the pages you visit that incorporate the button, whether or not you click it. Did you know, for example, that the UK National Health Services website has the like button, among other trackers, on all their disease pages?

One need only visit the Wall Street Journal’s recent series on privacy to realize that all manner of health-related data can be generated about an individual with little to no restrictions imposed by HIPAA or effectively enforced by the FTC. To take one example, consider the scraping (copying) of data at a site called PatientsLikeMe:

At 1 a.m. on May 7, the website PatientsLikeMe.com noticed suspicious activity on its “Mood” discussion board. There, people exchange highly personal stories about their emotional disorders, ranging from bipolar disease to a desire to cut themselves. It was a break-in. A new member of the site, using sophisticated software, was “scraping,” or copying, every single message off PatientsLikeMe’s private online forums.

Who knows how many incidents like this go unreported each year? Finally, the government itself is keeping a record of prescription drug use, which apparently was used after the Virginia Tech shooting. Law enforcement exceptions to HIPAA (and, presumably, HITECH) may give an official imprimatur for similar activities even if they involve “covered entities.”

The clash of intelligence prerogatives and health privacy always raises difficult issues. For now, I would just like to make one claim about the need for the government to be forthright about whether it is collecting health care data while profiling citizens. Such data gathering should not be what David Pozen calls a “deep secret;” that is, citizens should not be “in the dark about the fact that they are being kept in the dark.” Rather, we need to understand whether this very personal and important data is being commandeered to fight an “enemy within.”

There are broader principles for fair disclosure of the workings of the surveillance state. First, people are all too eager to sign up for new health “apps” and affinity groups without having any sense of how these activities and affiliations can affect their future. There is still a lazy public/private distinction affecting far too much of consumer conduct; I hear so-called internet experts wondering why anyone would worry about data stored by a private company because “they’re not the government.” Arkin & Priest have consistently shown that the public/private distinction is evanescent at best, a confounding development in social affairs that leaves libertarians sounding like communists.

Julie Cohen’s recent article in Social Research observes that there is a much larger political economy of surveillance that has accelerated both data gathering and profiling:

Devaluation of privacy is bound up with our political economy and with our public discourse about information policy in important ways that have little or nothing to do with official conduct. . . . Flows of data are facilitated by corporate data brokers like ChoicePoint, Experian, and Axciom. To help companies (and governments) make the most of the information they purchase, an industry devoted to “data mining” and “behavioral advertising” has arisen; firms in this industry compete with one another to develop more profitable methods of sorting and classifying individual consumers.

In the United States, a number of federal agencies have awarded multimillion dollar contracts to corporate data brokers to supply them with personal information about both citizens and foreign nationals. Privacy restrictions that limit the extent to which the government can itself collect personal information generally do not apply to such purchases at all. The government has deployed secrecy to great effect where these initiatives are concerned, with the result that we still understand too little about many of them. Legal regimes purporting to guarantee official transparency are in fact indeterminate on how much openness to require.

These processes let important decisionmakers in both the private and public sectors exist behind a “one way mirror.” Even if full transparency would compromise data gathering, citizens must know whether certain critical information (including health data) is being commandeered by the domestic intelligence apparatus.

Patient Autonomy and Personal Health Records

I recently gave remarks as part of a panel at the roundtable “Personal Health Records: Understanding the Evolving Landscape,” sponsored by the Office of the National Coordinator for Health Information Technology (ONC). There were many interesting speakers, including some of the leading businesses in the PHR space and regulators from FTC, HHS, and the California state Office of Privacy Protection. The roundtable exposed the promise–and limits–of a personalized health record model. Databases may help both public health and patient care, but the many stakeholders in PHR’s may have very different views about how much control patients should have over the presentation of their medical selves in everyday life.

Discussions about health records can get forbiddingly abstract and technical, but a real-world dilemma can help concretize the problem. As Lisa Wangsness’s Boston Globe article shows, at least one individual feels “burned” by his effort to quickly port past data into a PHR:

When Dave deBronkart, a tech-savvy kidney cancer survivor, tried to transfer his medical records from Beth Israel Deaconess Medical Center to Google Health, a new free service that lets patients keep all their health records in one place and easily share them with new doctors, he was stunned at what he found. Google said his cancer had spread to either his brain or spine — a frightening diagnosis deBronkart had never gotten from his doctors — and listed an array of other conditions that he never had, as far as he knew, like chronic lung disease and aortic aneurysm. A warning announced his blood pressure medication required “immediate attention.” “I wondered, ‘What are they talking about?’ ” said deBronkart . . .[He] eventually discovered the problem: Some of the information in his Google Health record was drawn from billing records, which sometimes reflect imprecise information plugged into codes required by insurers.

According to one doctor consulted by the Globe, “an inaccurate diagnosis of gastrointestinal bleeding on a heart attack patient’s personal health record could stop an emergency room doctor from administering a life-saving drug.” For the critically or chronically ill, the record is literally a life-or-death matter.

Admittedly, the level of personal control an individual has over a PHR also offers a solution to this problem. If we follow the same model as credit reporting, patients should be able to review their reports without charge, and make corrections. The Markle Foundation has done a superb job highlighting the importance of accountable health technology. But, as the Center for Democracy and Technology argues, rulemaking on EHRs will need to build in a number of consumer safeguards to assure that other stakeholder interests do not trump patients’ interests.

The CDT recommends that HHS require “PHR providers to provide opportunities for consumers to amend, correct or annotate information in a PHR,” and “to have policies for handling disputes concerning information in the PHR.” CDT expands on the obligation in these paragraphs:

Many PHRs contain data from two categories of sources: copies of information obtained from members of the traditional health system (including health care providers, insurers, etc.) and data generated or acquired by consumers themselves, whether directly entered by them, or fed into the PHR by devices or
other sources that are not part of the traditional health care system (including data from a monitoring device that the consumer operates, from a commercial Web site, or from a consumerʼs own health-related observations).

Policies governing disputes about the validity of data should draw a distinction between these different categories of data. With respect to copies of data that users might not be permitted to change directly (including but not limited to data that originates with members of the traditional health system), users should be given a way to attach notes or complaints to the PHR disputing the validity of the data – and the note should remain appended to the data any time it is disclosed from the PHR. (This is similar to how the HIPAA Privacy Rule treats patient amendment of data in covered entity records.) PHR vendors also should consider mechanisms for communicating patient disputes about data back to the original source for consideration.

Even in a world where PHR’s are ubiquitous, there’s almost certainly going to be some “objective health record” in the medical system about any individual. (And, if key software engineers get their way, there will be a unique “personal health identifier” for everyone once health records systems are up and running.) So why should the integrity of PHRs matter to anyone other than the person recording them?

First, the more legible, portable, and useful PHRs are, the more they may displace other records of patient information. Emergency rooms may only have a chance to look at one HR–the one given to them by the patient they are treating.

Second, we can assume that as PHR’s become a bigger part of larger employers’ cost-control programs, they are going to want to make sure that “quantified selves” are accurately reporting their health efforts and achievements. Health reform has taken a “preventive turn,” and the ACA gives employers new latitude to reward and punish employees:

Although it prohibits insurers from charging higher premiums based on an individual’s health risks, it allows them to charge a smoker as much as 50 percent more than a nonsmoker. It also permits employers to increase rewards for participation in wellness and disease-prevention programs from 20 percent to 30 percent of the costs of insurance premiums.

To verify participation, an employer may want access to an employee’s PHR, particularly if it is much easier for its own computer systems to read and understand than the “objective health record” existing in the health care system itself. Yet the employer may also want to ensure that the PHR is populated by materials validated by third parties (such as doctors’ offices, fitness clubs, scales, or blood sugar monitors). Presently, this is not a major issue; as Nicolas Terry warns, “sharing or exchange of data between PHRs and providers or their EMRs is as speculative as it is controversial.” However, technological advances could promote PHRs with inputs from providers, apps, and even RFID chips. What happens if the employer tries to condition participation in a wellness program on an employee’s agreement not to try to change whatever is reported by those “trusted” third parties?

The CDT suggests some principles that should guide this situation as well. They recommend that:

Employers, health plans, and others should be explicitly prohibited from requiring individuals to open PHR accounts as a condition of employment, membership, or for any other reason. PHR accounts should also not be routinely opened for consumers who do not explicitly activate them, as this can expose personal data to uses not necessarily anticipated by the consumer. Similarly, consumers should not be compelled to disclose the information held within the PHR, or whether they are using a PHR, without due process of law.

I believe these “compulsion” points should go beyond the decision to open a PHR, to the more granular rights and responsibilities associated with the maintenance of one. However many times employers sing the praises of contract law, the truth remains that employees in this tight labor market have very little bargaining power. That’s one reason why Nicholas P. Terry’s recommendation of inalienable rights to control data in the PHR context was one of the most provocative and compelling comments at the roundtable.

I am not here advocating for complete autonomy of the patient over records in all contexts. As Sharona Hoffman has argued, in the realm of treatment, there are important rationales for prioritizing the independent medical judgment of professionals whose first obligation is to maintain health:

If patients are empowered to opt out of EHR use or to disallow treating physicians’ access to their records, they may lose much of the benefit of computerization. Many clinicians would continue to care for patients in ignorance of essential facts that could make the difference between appropriate and inappropriate treatment decisions. For example, it might seem at first blush that most physicians would not need access to a patient’s psychiatric records. However, a psychiatric diagnosis may help other specialists better understand the patient’s symptoms, and the patient’s complete drug list, including psychiatric drugs, is vital for purposes of safely prescribing additional medications.

Some commentators at the roundtable also offered creative solutions for the “sensitive health data” conundrum raised by Hoffman; for example, a patient could include an “envelope” in their EHR or PHR that would only be opened in case of emergency, or when authorized directly by the patient. Regardless of how one feels about this issue, outside the treatment context, it is critical for consumers to have reasonable opportunities to review, correct, and withhold their personal health records.

When all is said and done, people have to “buy in” to EHR for it to work effectively, and rational individuals are going to avoid any system where medical history can be as effective as credit history at denying them opportunities. One commentator at the roundtable said that her patients “didn’t care” about health data or security; they just wanted some quick and dirty method of digitizing their records. However compelling this perspective may seem for those “on the front lines,” the perils of “wikileaked world” should end any complacency about the use and misuse of computer records. We should avoid the temptation of letting cut-rate or subpar EHR and PHR systems develop, especially since they are likely to target the most vulnerable patients. Robust regulatory requirements can spark a race to the top for data privacy and security.

In the film Sleep Dealer, a laborer encounters a “memory recorder,” a computerized transcription machine that translates past experiences into video re-enactments. The machine occasionally blanks out as the laborer narrates his story, and its operator chides him to “be more truthful,” to hew closer to the actual truth of the matter. The film is ambiguous as to whether the machine, its operator, or the laborer himself have real access to what actually happened. In the treatment context, best practices may inevitably consign us to a messy, multi-stakeholder effort to set forth the “real truth” of a health record. However, the personal health record should be primarily a project of the person it describes, with no undue influence from the growing number of reputation raters and shapers with a pecuniary interest in particular representations of that person.

Things You Wanted to Know About the New HIT Standards But Were Too Afraid to Ask

In a previous post I discussed the interim final rule (IFR) that was recently promulgated by the Office of the National Coordinator for Health Information Technology (ONC).  The previous post discussed two of the four categories of standards in the IFR. This post will look at the final two categories. In order to appreciate the purpose of the final two standards, it is worth recapitulating the basic framework upon which the IFR is based.

The ONC’s framework for the standards is to first start with the meaningful use objectives. From the broad objectives of meaningful use, the ONC establishes certification criteria for these objectives. Based on the certification criteria, the ONC has adopted standards that would allow for an objective determination of whether the criteria has been met.

An example will help: One of the meaningful use objectives is “the capability to exchange key clinical information among providers of care and patient authorized entities electronically.”  To achieve this objective, “Certified EHRs” will have to meet the following criteria: “[The EHR system must] electronically receive a patient summary record, from other providers and organizations including, at a minimum, diagnostic test results, problem list, medication list, immunizations, and procedures and upon receipt of a patient summary record formatted in an alternative standard specified in Table 2A row 1, displaying it in human readable format.”

In order to guide EHR vendors (and purchasers) in fulfilling the above criteria–and likewise the larger meaningful use objective–the ONC has adopted a number of standards that EHRs must utilize in order to be certified. These standards fall into 4 general categories.

1. Vocabulary Standards — The standardized nomenclatures and code sets used to describe clinical problems and procedures, medications and allergies.
2. Content Exchange Standards –  The standards used to share clinical information such as clinical summaries, prescriptions, and structured electronic documents.
3. Transport Standards — The standards used to establish a common, predictable, secure communication protocol between systems.
4. Privacy and Security Standards — Standards relating to authentication, access control, transmission security which relate to and span across all of the other types of standards.

My previous post provided a general overview of the first two standards, the first of which specifies the language of “EHR speak,” while the second specifies standards giving that EHR vocabulary a predictable organization so as to ensure that different EHR systems can interpret the data.

In the previous post I used the analogy of the Bluebook style of citation to explain the content exchange standard and vocabulary standard. As you can see, the following two citations share the same basic organization (e.g. case name in italics, followed by the reporter volume number, name of the reporter, starting page of case, etc).

Wilson v. Mar. Overseas Corp., 150 F.3d 1 (1st Cir. 1998)

Orange County Agric. Soc’y, Inc. v. Comm’r, 893 F.2d 529 (2d Cir. 1990).

The content exchange standard is analogous to the order of the different elements of the citation. Regardless of the case, all Bluebook citations to federal court of appeals cases have this same basic organization. The part that changes is the vocabulary. As you can see in the cases above, two different reporters (publishers) have been used: F.3d and F.2d.  There are still only limited options for the vocabulary of court reporters.  Likewise, even though the organization of a patient’s record will remain constant, it will obviously consist of different terms depending on, among other things, the patient’s diagnosis and test results. The possible terms within the chart are determined by the vocabulary standards.

Essentially, the signifier and syntax standards are meant to save us from constructing a costly high-tech Tower of Babel. A sign (word, letter, number, symbol) displayed in a particular way must have an agreed to and discernible meaning.

With these two standards in mind, a brief overview of the latter two standards is possible.

Transport Standards

Though the data is sitting on server A in a structured format–governed by the content exchange and vocabulary standards discussed above–there is more that needs to occur for the data to be useful. For example, Computer A must “know” how to send a request for that data in a way that Computer B can understand. Likewise, Computer B must “know” how to respond to Computer A’s request, i.e., how to structure the response it will give to Computer A. This is where the third category of “transport standards” becomes important.

Luckily for us, one of the transport standards (SOAP) adopted by the ONC is the same standard used by LexisNexis. This allows us to continue our analogy.

When I log onto LexisNexis, I have the opportunity to enter a citation. The citation must be entered in the same basic order that the Bluebook citation provides. Therefore, utilizing the first case cited above, I would type in:

150 F.3d 1

The name of the parties in the case is not necessary since only one case occurs at a given page (page 1) of a reporter’s (F.3d) volume (150). If I submit that citation and Lexis recognizes it, Lexis will then display the case. The beautiful thing about Lexis (and Westlaw) is that the case data, like the citations, has a specified organization–analogous to the organization specified by content exchange standards. One discrete element common to all Lexis cases is a field listing the parties’ counsel. Let’s say that I am an iPhone application developer and I want to create a simple application that would allow a user with a Lexis account to type in a citation like the one above, and in response the program would output the opposing counsel field (as opposed to the whole case). My application would need to know how to trigger Lexis’s server to go and find that information in the database. Likewise, the Lexis database must know how to package and send that data back to the client application. Thus, the fact that Lexis organizes data like citations and counsel into organized fields with specific vocabulary is not sufficient. Rather, there must be a standard governing the requests of specific information, as well as how that information should be formatted and transmitted. This is the role of the “transport standards.”

The ONC adopted two alternative standards–the SOAP standard and the REST standard–to govern requests and responses between client and server computers. As stated above, the SOAP standard is used by Lexis (and other Internet sites) to allow other applications and services to be able to interact with it. That Lexis uses the same standard as that adopted in the HIT interim final rule helps to illustrate the broad nature of  transport standards. Unlike the content exchange and vocabulary standards that are unique to the practice of health care, the transport standards ensure that services wishing to interact with a server have an agreed upon framework by which to accomplish the interaction.  As becomes obvious from this discussion, ensuring the proper implementation of the transport standards is critical to meeting the meaningful use objective described earlier that dealt with exchanging clinical information among providers. Additionally, having a specified standard for requesting and receiving the data is crucial for personal health record (PHR) services that seek to interface with the databases of health care providers in order to retrieve and display certain information to the consumer of the PHR.

Privacy and Security Standards

The fourth group of standards deals with privacy and security, and for the most part, this part of the IFR is straightforward. The reason for the straightforwardness is that the ONC has decided to model their privacy and security criteria off of HIPAA’s Privacy and Security Rules. Therefore, there are no real surprises. With that said, the HITECH Act does direct the various HIT committees as well as the ONC to look at capabilities beyond those specified in the HIPAA Security Rule. Thus, even though the IFR does not change the privacy and security landscape in any major way, there is no promise that things won’t change in the future.

Specifically,  the ONC has adopted standards for certain aspects of HIPAA but not others. For example, standards have been adopted for the encryption of data, but not for “access control” measures that are used to prevent unauthorized access at computer terminals connected to EHR systems. The ONC’s rationale is that the methods of regulating access are evolving at a rapid pace, whereas there are industry best practices available for encrypting information. As a result, the ONC requires all certified EHR systems to be capable of encrypting their data. This is somewhat remarkable given that HIPAA and HITECH do not require all entities to use encryption. The ONC believes that this capability will spur the use of encryption by making it available to all consumers of certified EHR systems. Furthermore, the implementation of encryption by HIPAA covered entities is important because it acts as a safe harbor, relieving them of the responsibility of having to report a data breach.

As Table 2B shows, the ONC distinguishes between the general encryption of stored data on the one hand and the encryption of transmitted data on the other hand. Please click on the thumbnail below to enlarge the table.

Table 2B - Click to Enlarge

The ONC has stated numerous times that the IFR in no way changes the responsibilities of covered entities or business associates under HIPAA (and HITECH). Rather, it solely concerns the capabilities of certified EHR systems.

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