OCR Cloud Computing HIPAA Guidance

The latest OCR HIPAA guidance — on cloud computing — will probably not satisfy those who keep calling for an overhaul of HIPAA because it dates from an era whe

The latest OCR HIPAA guidance — on cloud computing — will probably not satisfy those who keep calling for an overhaul of HIPAA because it dates from an era when health records were kept on cuneiform tablets. However, they, like the rest of us, will have to learn to live with the latest guidance.

Like other OCR publications (e.g., guidance on ransomware, on precision medicine, on de-identification), the cloud computing guidance will be variously seen as either simply applying existing regulations to new circumstances, or extending previously promulgated regulations in a manner not contemplated when the regs were written. Given the agency’s authority to interpret and apply the regs, and the reality that a new health data privacy and security framework is not about to be promulgated, we need to play the hand we’ve been dealt, we need to understand and implement these guidelines in order to operate in a compliant manner.

Most of what is found in the guidance should come as no surprise to anyone who has thought about the intersection of cloud computing and healthcare, though there a few items that warrant further contemplation.

First, the unremarkable:

• A cloud storage provider (CSP) is a business associate (BA). No “conduit” exception.
• A covered entity (CE) that contracts with a CSP BA needs to understand the cloud environment and services offered so that the CE can conduct its own risk analysis — and the BA needs to conduct its own risk analysis as well. (For purposes of this post, “CE” will include business associates and subcontractors — anyone “upstream” from the CSP)
• Just because one party (CE or BA) is nominally responsible for a security control (e.g., user authentication to limit access to authorized users) doesn’t mean the other party has no responsibility for the same control (e.g., a CSP BA is responsible for execution of security controls to address a potential malicious actor even where the CE is responsible for authenticating access to its authorized users).
• A CE must have a BAA in place before using a CSP to process or store PHI.
• A CSP that meets the definition of a BA is subject to HIPAA whether or not it signs a BAA (though OCR recognizes that a BA may not have knowledge of a CE’s using its resources for PHI and compliance requirements are only triggered by the BA’s knowledge of the violation (actual or constructive), unless ignorance was due to the BA’s willful neglect).
• PHI in the cloud may be accessed by CEs using mobile devices.
• A CSP that receives only de-identified data from a CE is not a BA. (Important to remember: encrypted PHI is still PHI; de-identified PHI is not PHI.)

Then, the things that might make you stop and think:

• “No-view” CSPs (i.e., CSPs that handle encrypted data only and do not have access to decryption keys) are still BAs and must still comply with certain HIPAA requirements. Many, if not most, of the big players in this space require customers to encrypt their data (thus reducing — but not eliminating — the CSP’s regulatory exposure). The guidance does not break new ground here but highlights the general principle that the HIPAA regs are not one-size-fits-all, and are flexible and scalable to address the circumstances of the no-view BA. Take note of these observations on encryption, though:

Encryption does not maintain the integrity and availability of the ePHI, such as ensuring that the information is not corrupted by malware, or ensuring through contingency planning that the data remains available to authorized persons even during emergency or disaster situations. Further, encryption does not address other safeguards that are also important to maintaining confidentiality, such as administrative safeguards to analyze risks to the ePHI or physical safeguards for systems and servers that may house the ePHI.

• CEs should be sure to review CSPs’ service level agreements (SLAs), to ensure that the CSP does not limit the ability of the CE to comply with HIPAA and that the SLA is consistent with the BAA. OCR notes that SLAs may address HIPAA-relevant issues such as:
  • System availability and reliability;
  • Back-up and data recovery (e.g., as necessary to be able to respond to a ransomware attack or other emergency situation);
  • Manner in which data will be returned to the customer after service use termination;
  • Security responsibility; and
  • Use, retention and disclosure limitations.

Even a no-view CSP BA has to ensure that it does not impermissibly block or terminate access for its CE customer because it may only use or disclose PHI as permitted by the Privacy Rule.

• CSP BAs must notify CEs of security incidents even where the PHI in their possession is encrypted.
• The rules do not require that PHI is stored on CSP servers within the US, but location should be considered as part of risk analysis and risk management. As a practical matter, key issues to consider are the likelihood of successful malware attacks or other exploits at the overseas data center and ease of enforcement of legal rights in the overseas court system. Given these issues, it makes sense in most cases to keep US health data on US servers. (As an aside, for US-based CEs with international customers, it is important to review the applicable law in the data subject’s home country; some may require, rather than simply encourage, data storage within their borders.)