Transitive Liability: Balancing HIPAA and Meaningful Use

Just recently, the U.S. Health Information Portability and Accountability Act (HIPAA) grew sharper teeth and a longer arm. On January 2013, the Health and Human Services (HHS) department published what is referred to as the Omnibus Rule, reinterpreting the Act. More severe penalties were approved for violation of personal health information (PHI) privacy.
The grace period for complying with the Omnibus Rule is up. As of September 23, 2013 health care providers can face fines from $1,000 to $1.5 million depending on their tier and the nature of the violation. Breach disclosure requirements have been strengthened too. But according to the article “HIPAA Omnibus Rule Violation Nets Hefty Fines” many providers are not fully aware of the changes and may find themselves at risk.
I recommend you check out the aforementioned article and perhaps even the textof the Rule itself for more general information on the new face of HIPAA. Because from here on this post focuses specifically on the transitive liability requirement imposed on “business associates” and “subcontractors” of health care providers, or “Covered Entities.”
The Omnibus Rule contains a significant amount of discussion related to the changed definition of Business Associate. HHS goes into great length (see pp. 18-36 in the PDF) in discussing who is, and who is not, considered a Business Associate.
The Rule adopts as Business Associates many organizations that perform services for health care providers. It greatly narrows the former “conduit exception” to services that merely transmit PHI as opposed to those that “maintain and store it” (e.g. a record storage company). The former is NOT a Business Associate but the latter is. Also, a subcontractor(s) who “creates, receives, maintains, or transmits PHI on behalf of one Business Associate, is [itself also a de facto] Business Associate” and therefore required to comply with HIPAA security, privacy and breach notification rules.
What boggles my mind is that Covered Entities are required to obtain “satisfactory assurances” from all their their Business Associates, and Business Associates are required to get the same from their subcontractors. This chain of transitive liability is intended to follow PHI wherever it goes. That should be really interesting when a cloud services provider (CSP) like Google gets hit with a fine due to a breach of some small or medium business (SMB’s) Google Apps account that handled PHI for a Covered Entity upstream. In that scenario one could imagine Google and the hypothetical SMB pointing fingers at each other. But Google, of course, can afford better lawyers.
On my way to a meeting with a client in the health care space last month, I spent a lot of time with the 567-page HHS Omnibus Final Rule’s business associates sections trying to figure out whether, if a CSP ended up running a personal cloud for that Covered Entity, what would it be liable for? I also had lunch with Adrian Gropper, who writes an excellent blog at, on this question.
Per Adrian, it turns out that the conduit, or chain of liability, that is important is not the chain of custody or conveyance of PHI but the chain of contracts from the health care provider to a CSP. As long as a personal cloud service acting as a personal health record store is clearly serving the patient and clearly not acting “on behalf of” the health care provider, it is NOT a de facto business associate. Delving into the law, in the U.S. there is no inherent right to privacy for PHI (or anything else), only a duty for organizations explicitly by a sector-specific law such as HIPAA or Gramm Leach Bliley. A CSP not acting on behalf of a Covered Entity could even blatantly share PHI with data brokers of the worst kind as long as it could show that the patient had agreed to this in its privacy policy. If on the other hand the CSP’s privacy policy said it would not share PHI but then it turned around and did so the CSP would still not be liable under HIPAA – but it might become liable to the Federal Trade Commission (FTC) for violating its own privacy policy.
This gets really interesting when one starts thinking about personal clouds, and a government mandate that health care providers must provide patients with access to their own PHI such that they can make “meaningful use” of the information. If the patient of a health care provider pulls information out of a medical record system at a covered entity and into his or her personal cloud, the CSP could possibly be construed to be acting on behalf of the patient rather than the covered entity. In Adrian’s words, the patient is acting as a “circuit breaker” in the chain of transitive liability.
So, could this circuit breaker effect prove to be a huge business driver for personal clouds? In proposing this, I’m not trying to get CSPs off the hook. I’ll certainly do everything in my power to ensure that Respect Network, its partners and any other CSPs I influence through security guidance or consulting maintain robust security practices. Still, breaches happen sometimes even with robust security and good people get in trouble.
That being said, we all know that compliance fears drive security activity and spending. In fear of HIPAA, some CSPs might tend to provide more robust security than otherwise. Could a personal cloud, or any other form of HIPAA circuit breaker, have negative effects on privacy by weakening the compliance driver? Perhaps. But getting back to Meaningful Use, the point of government policy isn’t to lock up all PHI and throw away the key. If you read the posts at HealthURL, you’ll learn (probably not to your surprise) that perhaps $1 TRILLION of aggregate U.S. health spending is wasted. The goal of Meaningful Use is to increase transparency and accountability in the industry on treatment outcomes and (perhaps even pricing) to improve efficiency in the system through patient engagement.
Information privacy must always exist in balance with information utility. Personal clouds that try to maximize both, therefore, are a good thing – for health care and for other industries.
Subscribe to Blog Notifications...  HERE