Subscribe if you want to be notified of new blog posts. You will receive an email confirming your subscription.

Please enter your name.
Please enter a valid email address.

Please check the captcha to verify you are not a robot.

Something went wrong. Please check your entries and try again.

Privacy Law Showdown? Legal and Policy Analysis.

#2 in a series — Modifications to HIPAA Privacy Laws: Impact on Microsoft HealthVault, Google Health, and other PHRs

by Deven McGraw JD, MPH, Center for Democracy & Technology

Deven.mcgraw.highres-1Introduction

There has been considerable discussion lately about whether or not the stimulus legislation (ARRA) extends HIPAA coverage to commercial vendors of personal health records (PHRs) any time they contract with entities already covered by HIPAA like hospitals, health plans or physicians groups.  (For those of you who don’t know, HIPAA is the Health Insurance Portability and Accountability Act of 1996.  The HIPAA privacy and security regulations form our national health privacy and security rules.)

The provision in question (Section 13408) states that “each vendor that contracts with a covered entity to allow that covered entity to offer a personal health record to patients as part of its electronic health record” is required to enter into a business associate agreement with the covered entity.   Under ARRA, business associates must comply with key provisions of the HIPAA privacy and security regulations. 

In this post, I argue that PHR vendors should be covered under HIPAA only under certain circumstances.  PHRs should be governed by a comprehensive framework of privacy and security protections, but HIPAA would provide inadequate privacy protection for people using these tools (at least as the HIPAA rules are currently structured).  As a result, I argue that this provision in ARRA should not be read to require the automatic application of HIPAA to PHR vendors any time they contract with covered entities to offer a PHR.   Instead, I suggest that HIPAA should cover a PHR vendor’s activities when the nature of the relationship between the vendor and the covered entity (hospital, health plan, physician office) primarily concerns the vendor performing a service for the covered entity. 

However, where the contractual relationship is primarily about improving the value of the PHR to the consumer, HIPAA should not apply.  (I know, not an easy line to draw – but I do suggest some factors that should influence the decision.) 

Finally, I urge the prompt adoption of separate, targeted privacy provisions to protect consumers using PHRs so that the choice is not HIPAA or limited protections under other federal laws. 

Why Not HIPAA – Isn’t it Better Than Nothing?

Much of the anxiety surrounding the question of whether HIPAA does or doesn’t apply to PHRs is driven by the lack of strong federal privacy protections in circumstances where HIPAA does not apply, which is motivating many to advocate that HIPAA apply to PHR vendors in all or most cases. (Such entities can be subject to action by the FTC under the Federal Trade Commission Act (FTCA) if they do not abide by their privacy policies, but the FTCA does not provide a comprehensive framework of privacy protections for consumers.)   It is not our goal to exempt PHR vendors from federal regulation.  The lack of federal privacy and security rules governing most PHR vendors concerns the Center for Democracy & Technology (CDT) — but as mentioned above, making them subject to HIPAA across the board is not the answer.  HIPAA was designed to regulate the flow of health information among health care entities and health plans.  As a result, the HIPAA regulations permit broad use of personal health information without patient consent for purposes of treatment, to obtain payment from a health plan, for administration of health plan benefits (including underwriting), and for a range of routine administrative tasks known as health care operations.  In addition, the HIPAA privacy provisions allow data to be used for  marketing and research purposes without patient consent in a number of circumstances. Government access to records is also permitted (subject to certain constraints) under HIPAA. 

PHRs should be primarily designed for individual use, to give individuals access to copies of their health data and allow them to use it and move it as they see fit.  The permissive information-sharing approach of the HIPAA rules is the right one for entities within the health care system accessing and sharing information from their records; but it’s the wrong regulatory fit for products that were designed with a different business model and that are designed primarily for consumer use.  Regulations governing PHRs should reinforce the strong role for consumer consent but also provide greater protections than HIPAA currently does regarding the use of health data for certain marketing and commercial activities. (For a more detailed summary of why the current HIPAA rules are inadequate to protect consumers using most commercially available PHRs, see http://www.cdt.org/healthprivacy/HIPAA-PHRs.pdf.)

Suggestions for How to Interpret the New Provision

The ARRA provision in question states that PHR vendors must be business associates when they contract with a covered entity to allow that covered entity to offer its patients a PHR as part of that covered entity’s electronic health record.  (For those of you new to this, HIPAA “covered entities” are most of the entities in the traditional health care system, including hospitals, physicians, and health plans.  These entities all keep their own records of patient care or health care claims.)   Whether a PHR is “part of the covered entity’s electronic health record” should depend on the nature of the relationship between the vendor and the covered entity and the terms under which the PHR is offered to consumers or patients. 

At the two ends of the spectrum, the analysis is fairly easy to apply. 

Use Case Category 1: PHRs Primarily for Patient Benefit. Where the contract between the PHR vendor and the covered entity primarily facilitates the efficient transmission of data into (or out of) an individual’s PHR per his or her express authorization and perhaps performs other functions that primarily benefit the individual (such as facilitating secure electronic communications with a health provider), and the PHR’s terms of use give individuals sole control over their data, that PHR is arguably independent of the covered entity’s electronic health record.  If a patient has the ability to unlink the PHR from one covered entity and “tether” it to another (or to hold the PHR as a free-standing record), this further supports a conclusion that the PHR is independent and thus the vendor should not be considered to be a business associate under HIPAA. 

Use Case Category 2: PHRs Primarily for Others’ Benefit. At the other end of the spectrum are arrangements where the PHR is offered as an adjunct to the covered entity hospital or health plan’s electronic health record, or the PHR is just a patient portal into the hospital or health plan’s record, and the hospital or health plan treats the PHR as an extension of its own record and can routinely access the data for some or all treatment, payment or health care operations purposes consistent with HIPAA rules.  Patients may benefit from using the PHR, but much of the functionality is designed to benefit the provider or plan.  In such a case, the PHR is offered as part of the covered entity’s electronic health record, and the vendor should be considered to be a business associate.  This conclusion is strengthened if the PHR “belongs” to the covered entity and cannot be moved by the individual from one entity to another. 

This interpretation is consistent with the way that “business associates” are viewed under HIPAA.  HHS created the “business associate” concept in the HIPAA regulations because the agency recognized that covered entities contract with outside companies to perform functions on their behalf using identifiable health information.  HHS wanted to extend the protections of HIPAA to these contractors, but the agency could not regulate them directly because the HIPAA statute applies only to covered entities.  So HHS required covered entities to enter into contracts with their business associates to set parameters for information access and use and ensure adoption of security safeguards.

But What About Circumstances Where the Hospital-Vendor Relationship is a Mix of Benefit to Patient/Benefit to Facility?

Use Case Category 3: PHRs for Patient and Others’ Benefit. Although this analysis is easy to apply at the two ends of the spectrum, the waters quickly muddy in the middle. 

What if the relationship between the vendor and the covered entity is a mix of the two (for example, individual has control but cannot move the record from one provider to another)?  Which factors are dispositive in determining whether a business associate agreement is or isn’t required?  Although we at CDT are still sketching out a workable regulatory framework to implement this interpretation, I am inclined to prioritize the ability of individuals to control information flows into and out of the PHR and to easily move the record to any provider or plan.  As I explained in a bit more detail above, consumers would be ill served by having those PHR products regulated under current HIPAA rules. 

Although the legislative language is less than clear, it is capable of being interpreted using the functions test I briefly sketch out in this post.   If Congress was trying to cover the major PHR vendors under HIPAA across the board, they could have done so more explicitly.  In fact, other provisions of ARRA suggest that Congress recognized that these entities in many cases should be regulated under different rules.  For example, there are separate provisions for breach notification that apply to PHR vendors and are overseen by the FTC (not HHS).  In addition, HHS and FTC are required to report to Congress on privacy and security recommendations to govern PHR vendors.  This report is supposed to include a recommendation for which agency should regulate these vendors going forward and a timetable for regulation.  There would be little need for such a study if Congress intended these entities to be covered by HIPAA each and every time they enter into a contract with a covered entity.

So What Happens Next?

CDT will urge HHS to adopt the construction described in this post, and in the coming weeks we will work to put some more flesh on the bones set forth here. Such an interpretation could mean that most of the activities of the most popular PHR vendors will not be covered under HIPAA.   It also likely means that the same PHR vendor could be covered by HIPAA under some circumstances and not covered under others.  We acknowledge that a potential result of this interpretation is that vendors could structure arrangements with covered entities to deliberately avoid coverage under HIPAA.  Again, our aim is not to exempt PHRs from regulation in some circumstances but instead to have them regulated under rules that will maximize their functionality but also provide strong protections for consumers. 

Some have suggested that covered entities may insist that vendors enter into business associate agreements, for two reasons.   First, in the face of uncertainty regarding how HHS will interpret the language, covered entities may decide to interpret the provision as requiring them to enter into business associate agreements with the PHR vendors with which they contract.  Second, some covered entities may actively seek to enter into such agreements because they want to be able to access data in a patient’s PHR on the same terms as they can access their own records (and those entities will then seek to interpret the language we’ve discussed here in a way that reinforces that business goal).  

However, the interpretation set forth in this post may better serve the needs of both covered entities and consumers.  I have already made a case for why the HIPAA rules are not the right regulatory fit for PHRs.   Under current HIPAA regulations, covered entities can, in some circumstances, be held responsible for the actions of their business associates.  Further, current rules require covered entities to provide an accounting of disclosures made by business associates in response to a patient’s request (this is sort of like an audit trail of some disclosures out of a patient’s medical record). The new provisions in ARRA making business associates more independently accountable for complying with HIPAA do not go into effect until early next year (and the new rules expanding what must be provided to patients who request such an accounting of disclosures from their record do not go into effect for several years), which means that any business associate agreement entered into now is governed by the existing rules.  Even under the new rules, a business associate who breaches health information is only required to inform the covered entity of the breach; the covered entity then has the obligation to notify the individual.  PHR vendors who are not business associates have independent obligations to directly notify individuals of any breaches. 

The growing pressure for regulating these products would be significantly diminished if we just covered them automatically under current HIPAA rules.  We then will have lost any momentum to create a regulatory infrastructure to govern PHRs that gives consumers control and targets the real risks to individuals who use these tools.  The joint study and report to Congress by HHS and the FTC lays the foundation for further regulation of PHRs.  Our focus now should be on ensuring the development and implementation of appropriate rules and policies that will build patient trust in these products and help facilitate their adoption.

In post #3 of this series, Vince Kuraitis and David C. Kibbe will discuss business implications.

Deven McGraw is the Director of the Health Privacy Project at the Center for Democracy & Technology, where she focuses on developing and promoting policies that ensure individual privacy as personal health information is shared electronically.   Before joining CDT, she worked on health IT issues as Chief Operating Officer for the National Partnership for Women & Families, and was an associate in the law firms of Patton Boggs in Washington, D.C. and Ropes and Gray in Boston, MA. 

She is lead author of “Privacy As An Enabler, Not An Impediment: Building Trust Into Health Information Exchange”, published in the latest issue of Health Affairs.

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. Feel free to republish this post with attribution.

2 Comments

  1. Andrew Howard on April 21, 2009 at 11:01 pm

    Deven McGraw (of @CenDemTech) offers lucid analysis of what new health privacy provisions in ARRA/HITECH might mean: http://bit.ly/dApoX



  2. medlaw on April 23, 2010 at 11:10 am

    I am kind of at a loss to see the evil to be alleviated by the proposal to create a second level of medical privacy laws applicable only to “PHRs Primarily for Patient Benefit”. Besides the evident difficulty in defining that term, it’s no small task involved in crafting a new regulatory scheme only to be used by this new class. Also, any PHR set up to benefit the patient can only fulfill that promise by being accessible to said patient’s health care providers. The main benefit to the patient is rapid access to the patient’s complete history by any provider no matter where located. Meaning health care providers (covered entities) must interactive with all PHRs for them to have any utility. Perhaps a better approach would be to lobby for a few limited exceptions to specific HIPAA provisions that the industry feels are the most burdensome.