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 of 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 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 be stored on CSP servers within the US, but location should be considered as part of risk analysis and risk managment. As a practical matter, key issues to consider are 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.)

Clear? Good.

David Harlow
The Harlow Group LLC
Health Care Law and Consulting

3 replies on “OCR Cloud Computing HIPAA Guidance”

  1. As always to the initiated there’s not much, if anything, new here. However. in this case there are some key clarifications that may eliminate the endless round of cloud questions that we deal with. The guidance here hints at, but does not, address (nor should it) the complexities surrounding what happens when (not if) things “go south” in cloud relationships. The cloud poses a minefield of availability and integrity questions having to do with getting your ePHI back in some suitably usable form should irreconcilable differences arise. Keep in mind that cloud vendors generally control both the your data, and how it’s accessed. Breaking up is hard to do is a gross understatement when it comes to ePHI in the cloud; even if you have ironclad contractual provisions.

  2. “[…]A cloud storage provider (CSP) is a business associate (BA). No “conduit” exception.”
    Does this mean that even a store-and-forward CSP, which holds PCI for just a limited time (days?), is a BA, and a CE, before using the service, needs to sign a BAA with this provider? Thanks.

    1. Read this Q&A from the guidance. The last sentence provides an extremely limited conduit exception for certain CSPs, based on the services they provide. I cannot advise via a blog post comment whether this exception applies to your situation.

      3. Can a CSP be considered to be a “conduit” like the postal service, and, therefore, not a business associate that must comply with the HIPAA Rules?

      Generally, no. CSPs that provide cloud services to a covered entity or business associate that involve creating, receiving, or maintaining (e.g., to process and/or store) electronic protected health information (ePHI) meet the definition of a business associate, even if the CSP cannot view the ePHI because it is encrypted and the CSP does not have the decryption key.

      As explained in previous guidance,[14] the conduit exception is limited to transmission-only services for PHI (whether in electronic or paper form), including any temporary storage of PHI incident to such transmission. Any access to PHI by a conduit is only transient in nature. In contrast, a CSP that maintains ePHI for the purpose of storing it will qualify as a business associate, and not a conduit, even if the CSP does not actually view the information, because the entity has more persistent access to the ePHI.

      Further, where a CSP provides transmission services for a covered entity or business associate customer, in addition to maintaining ePHI for purposes of processing and/or storing the information, the CSP is still a business associate with respect to such transmission of ePHI. The conduit exception applies where the only services provided to a covered entity or business associate customer are for transmission of ePHI that do not involve any storage of the information other than on a temporary basis incident to the transmission service.

Comments are closed.