On January 25, 2013, the U.S. Department of Health and Human Services (HHS) released the Omnibus Rule, which finalized all the former interim rules for Health Insurance Portability and Accountability Act (HIPAA) and Health Information Technology for Economic and Clinical Health (HITECH) compliance.
As I see it, most of the effect of the Omnibus Rule on public cloud services boils down to governance issues. That opinion, and this article, is my layman's interpretation of the Omnibus Rule in the context of having dealt with all sorts of compliance for more than 15 years. HHS and individual auditors will have their own interpretations, but all of the following things matter for organizations and individuals who plan to use public cloud services when dealing with protected health information (PHI).
Important Definitions
The official definitions of entities and concepts related to the Omnibus Rule are peppered throughout the HHS HIPAA site, but here’s how I interpret them in layman’s terms:
Protected health information (PHI): Individually identifiable health information. Effectively any demographic information related to the condition, provision, or payment of health care to an individual that can be used to identify (or be tied back to) a specific individual.
Covered entity (CE): A health plan, a health care clearinghouse, or a health care provider that transmits any health information in electronic form in connection with a transaction.
Business associate (BA): An organization or individual who operates on behalf of a covered entity. Focus is on any function or activity involving the use or disclosure of PHI, such as claims processing or administration; data analysis, processing, or administration; utilization review; quality assurance; billing; or benefit management.
Business associate agreement (BAA): A contract between a covered entity and business associate that stipulates the requirements for the business associate to protect PHI in accordance with HIPAA guidelines.
U.S. Department of Health and Human Services (HHS): The agency responsible for creating and maintaining rules, standards, and implementation guides. “Secretary” refers the the HHS agency head.
U.S. National Institute of Standards and Technology (NIST): The U.S. federal technology agency that, for our purposes, works with industry to develop technology standards and guidance. Most, if not all, U.S. federal government defers to NIST tech publications and standards for just about everything.
HITECH: The HITECH Act was enacted as part of the American Recovery and Reinvestment Act of 2009. As per the HHS site, HITECH was designed to:
... promote the adoption and meaningful use of health information technology... Subtitle D of the HITECH Act addresses the privacy and security concerns associated with the electronic transmission of health information, in part, through several provisions that strengthen the civil and criminal enforcement of the HIPAA rules.
HITECH is the enforcement rule that gave HIPAA teeth.
HIPAA Title II
Title II of HIPAA contains the Administrative Simplification Rule (along with other items), which has three main components:
Privacy Rule
The Privacy Rule imposes controls around preventing unauthorized disclosure of PHI in any form. It requires appropriate safeguards to protect the privacy of PHI and sets limits and conditions on the uses and disclosures that may be made of such information without patient authorization. The rule is all about authorized disclosure.
Security Rule
The Security Rule exists to prevent unauthorized electronic access to PHI (ePHI). Its focus is on maintaining reasonable and appropriate administrative, technical, and physical safeguards for protecting ePHI. Specifically, the Security Rule attempts to ensure that CEs and BAs have controls that ensure the confidentiality, integrity, and availability of all ePHI they create, receive, maintain, or transmit. It requires a CE/BA to identify and protect against reasonably anticipated threats to the security or integrity of the ePHI as well as protect against reasonably anticipated impermissible uses or disclosures. Finally, the Security Rule provides controls to ensure compliance by the CE/BA workforce.
The rule has two categories of control implementation: Required and Addressable.
Required: The implementation specifications must be implemented
Addressable: Permits entities to adopt an alternative measure that achieves the purpose of the standard
Breach Notification Rule
The Breach Notification Rule exists to ensure timely notification of affected parties in the event of a failure in the above two rules. It requires notification if a breach involved unsecured PHI. Unsecured PHI is defined as PHI that has not been rendered unusable, unreadable, or indecipherable to unauthorized individuals. If there is a breach, the CE is on the hook to notify the affected individuals and HHS. A BA is required to notify the CE within 60 days of breach discovery. The entity that is subject to the breach investigation must prove to the investigators that:
All required notifications have been provided –OR–
The disclosure did not constitute a breach.
Key Issues
When I attended the NIST HIPAA conference in May 2013, I found that organizations were grappling with some key issues when dealing with public cloud:
Location: Do you know where to find the PHI that is under your purview? What assurances and warrants does the cloud service provider (CSP) give that your data is where you think it is? Note that there was no discussion on limits for “geography” for where PHI could be stored, but rather the fact that you “know and control” where it is stored.
Breach: What does your CSP do to prevent breaches of PHI that you have entrusted to it, and for which it is therefore responsible? If there is a breach, what is the response capability of the CSP to give adequate information on the access of PHI?
Access and Monitoring: Has the CSP implemented proper controls? Does it monitor access? In particular, can the CSP identify any access — including read and print, not just modifications — to PHI?
Changes Affecting HIPAA and Public Cloud
The two biggest changes from the Omnibus Rule that will affect those using public cloud services are definition and requirements around business associates, and breach notification requirements. None of the other changes in the Omnibus Rule, in my opinion, distinguish between public cloud or any other technology. So, for example, finalized rules around use of PHI for marketing purposes would be the same if the PHI were in a public cloud or your own data center.
Business Associate
The requirements around business associates are the biggest issue, as they will require significantly more effort by both CEs and BAs to maintain compliance. By law, the HIPAA Privacy Rule applied only to covered entities. From the statute:
The Privacy Rule allows covered providers and health plans to disclose protected health information to these “business associates” if the providers or plans obtain satisfactory assurances that the business associate will use the information only for the purposes for which it was engaged by the covered entity, will safeguard the information from misuse, and will help the covered entity comply with some of the covered entity’s duties under the Privacy Rule.
So that begs the question: Who is a business associate?
Per the statute, a business associate is one “who will create, receive, maintain, or transmit PHI for a covered entity.” This is generally a person who performs functions or activities on behalf of, or certain services for, a covered entity that involve the use or disclosure of PHI.
The Omnibus Rule has a special call-out or addition of the following as BAs:
Patient safety organizations
Health information organizations (HIO), e-prescribing gateways, and other persons that facilitate data transmission, as well as vendors of personal health records
Subcontractors (which becomes a recursive definition)
Exceptions
There are exceptions called out in the statutes:
Incidental access: With persons or organizations (such as an electrician or a janitorial service) whose functions or services do not involve the use or disclosure of protected health information, and where any access to protected health information by such persons would be incidental, if at all.
Conduit: With a person or organization that acts merely as a conduit for protected health information — for example, the U.S. Postal Service, certain private couriers, and their electronic equivalents.
Interestingly enough, many CSP used the conduit exception to remove themselves from a BA designation. HHS did not agree, and issued the following clarification in the Omnibus Rule:
... We note that the conduit exception is limited to transmission services (whether digital or hard copy)… In contrast, an entity that maintains protected health information on behalf of a covered entity is a business associate and not a conduit, even if the entity does not actually view the protected health information…the difference between the two situations is the transient versus persistent nature of that opportunity. For example, a data storage company that has access to protected health information (whether digital or hard copy) qualifies as a business associate, even if the entity does not view the information or only does so on a random or infrequent basis. (emphasis added)
At this point in time, HHS has indicated that the persistency of data, not degree of access, is the key driver in defining a business associate.
This clarification means that any CSP that an organization uses for persistent storage of PHI (encrypted or not) falls under the definition of business associate, and thus would require a business associate agreement
Why the BA Focus?
HHS indicated that the focus on BAs was due to the overall impact a disclosure at a BA has on individuals. Per the number released at the NIST conference:
One-third of all breaches are related to third parties
55 percent of people affected are related to third parties
Thus a third-party disclosure has a larger impact than a non-third-party.
Many people have asked, “Does encryption remove you from BA status?” At this time, as I understand it, no. HHS has indicated that appropriate encryption can be used to render PHI “unusable, unreadable, or indecipherable to unauthorized individuals,” which in turn affects whether a disclosure is considered a breach. If you meet the encryption requirements and the “encrypted data” is leaked (without the key obviously), then the leaked data would be considered “unusable, unreadable, or indecipherable to unauthorized individuals” and thus no breach would have occurred.
The encryption requirements by HIPAA specify the following NIST standards and special publications:
NIST Special Publication 800-111 (storage)
NIST Special Publications 800-52 (has been withdrawn as of 3/13/2013), 800-77 (transit)
NIST Special Publication 800-88 (destruction)
Federal Information Processing Standards (FIPS) 140-2 (validated crypto)
So in a nutshell, encryption does not remove you from being a BA, but does affect the definition of a breach. However, the conversation by the powers that be during the NIST conference seemed to indicate HHS is looking at this.
What HHS Is Pushing
My read on the environment is that HHS desires organizations to take a risk-based approach to the CE/BA relationship. It expects:
CEs and BAs to beef up contracts with respect to security requirements
It wants to see that the BAs (and their BAs, and down the chain) represent and warrant that they meet the controls that are specified in the contract/agreement (likely in an appendix).
Use of pre-contract assessment to perform a short-form risk assessment
What PHI are we sharing?
Where is it located?
How does the BA protect it?
Use that information to assess risk and identify specific controls for a given BA
You would conduct a post-contract audit to ensure that the BA you contracted with is doing what it says it is. The expectation is that you would audit your most risky relationships first.
Direct Liability and Subcontractors
The Omnibus Rule made modifications to the HITECH Act’s provisions extending direct liability for compliance to business associates. A BA is now directly liable for civil money penalties. For the BA, if it uses a subcontractor who creates, receives, maintains, or transmits PHI on its behalf, including with respect to personal health record functions, it is a HIPAA business associate, and the BA must have a BAA with subcontractors (just another BA). This is recursive.
BAA: Is It Optional?
You may wonder, do I really have to put my BAs under BAA? Per Page 5591 of the Omnibus Rule:
Comment: One commenter suggested that business associate agreements should be an ‘‘addressable’’ requirement under the Security Rule.
Response: The HITECH Act does not remove the requirements for business associate agreements under the HIPAA Rules. Therefore, we decline to make the execution of business associate agreements an ‘‘addressable’’ requirement under the Security Rule.
Seems pretty straightforward to me that you need a BAA to be in compliance. If you decide to forgo the BAA, make an informed decision.
Changes to Breach Notification Rule
The Omnibus Rule made a number of changes to the Breach Notification Rule. Most importantly:
It clarified the term “breach” to basically mean guilty until proven innocent, and changed “risk of harm” to “low probability PHI compromised”:First, we have added language to the definition of breach to clarify that an impermissible use or disclosure of protected health information is presumed to be a breach unless the covered entity or business associate, as applicable, demonstrates that there is a low probability that the protected health information has been compromised.
You must complete a risk assessment to prove the “low probability”:
Thus, breach notification is not required under the final rule if a covered entity or business associate, as applicable, demonstrates through a risk assessment that there is a low probability that the protected health information has been compromised, rather than demonstrate that there is no significant risk of harm to the individual ...
How Do the Changes Affect You and the CSP?
You (the one sharing the PHI and the one having the PHI shared with them) need to be watching the PHI for unauthorized disclosure, which means you have to know who is accessing (not just modifying) it. Further, you must be reviewing the access logs and have a mechanism in place to perform notification if a disclosure is determined to be a breach. If there is a suspected disclosure, you should notify the affected parties in the contract and follow the breach notification guidelines.
If you are not doing these things, and a breach does occur, you could fall into the “willful neglect” category for penalties, which can be stiff. Take a look at the Enforcement Activities and Results section on the HIPAA site for details on penalties.
What Is Involved in the Risk Assessment?
If you suspect a disclosure, you should determine the probability of an actual breach by identifying:
The nature and extent of PHI involved. What types of identifiers are there and what is the likelihood of re-identification to a specific individual?
Who accessed or used the information?
Was the PHI was actually acquired or viewed? (Remember when I said you need good logging?)
The extent to which the risk to PHI has been mitigated.
Alternatively, you can forgo risk assessment and just declare a breach and go through the notification process. It is your choice.
Timeframes
While the Omnibus Rule was passed on January 25, 2013, and went into effect on March 26, businesses were given 180 days, until September 23, 2013, to become compliant. Read the Omnibus Rule before that deadline, and if you don’t understand its provisions, you may be able to get answers through the HHS Health Insurance Privacy website.
Cloud Providers and BAA
Several of the cloud providers whose services we (RightScale) monitor and manage will sign a BAA:
AWS: Will sign
Windows Azure (IaaS): Will sign
Rackspace Public Cloud: May sign one as an addendum to the general terms and conditions. Customers need to validate if Public Cloud or just managed services.
Datapipe: On a case-by-case basis
Google Compute Engine (GCE): Not at this time
SoftLayer: Not at this time
There are others as well, I am just not knowledgeable about them.
Summary
In summary, proper oversight of your BAs is critical — and if you are a BA, be aware that you now have direct liability. You are responsible for your subcontractors, and they for their subcontractors, ad infinitum. Watch what actions are taken on the PHI you have in your custody and encrypt where you can. Things are still changing, but there is at least a line in the sand now.
With all that said, don’t let that responsibility frighten you. Good security that encompasses governance, patching, hardened configurations, proper authentication, and other best practices, will, as always, cover much of what you need.
Cross Posted from the RightScale Cloud Management Blog
Related Reading: The Game-Changing Legislation That No One is Talking About
Copyright 2010 Respective Author at Infosec Island