Topics In Demand
Notification
New

No notification found.

Blog
Unpacking new HHS guidelines on healthcare data in the cloud

November 2, 2016

362

0

The new guidelines recognize the growing importance of cloud computing in healthcare and are the right step in the bringing cloud service providers into the broader discussion on healthcare data security. But covered entities and BAs have to unpack the guidelines and address certain gaps

The cloud services market is growing exponentially, and research firm Gartner estimates the market for cloud services to be over $200 billion. The healthcare sector has been getting on board as well, for enterprise IT workloads as well as cloud-based technology solutions. It’s no surprise that the U.S. Department of Health and Human Services (HHS) has released a set of guidelines for cloud service providers (CSP), clarifying their role as business associates (BA) in the context of HIPAA and healthcare data.

I’m going to try to unpack these guidelines and highlight the key aspects.

First off, the guidelines acknowledge the growing role of public cloud providers, such as Amazon Web Services (AWS) and Microsoft Azure, that have been storing electronic protected health information (ePHI) for some years as part of their agreements with technology providers and enterprises. These CSPs are now apparently classified as BAs and are required to sign HIPAA business associate agreements (BAA), regardless of the nature of the arrangement and the level of access to ePHI stored in the cloud infrastructure.

Secondly, the focus of the guidelines seems to be more on information security. Given the rash of data breaches recently (over 112 million medical records breached in 2015, and 2016 likely to be a banner year), and ransomware incidents at hospitals, HIPAA BAs aremore on notice than ever before.

Here are the key aspects of the new guidelines:

Any covered entity or BA who works with a CSP to handle ePHI will need to have a BAA with the CSP. The onus is now on both the CSP as well as their BA to ensure there is a BAA in place.

CSPs who store ePHI will come within the purview of HIPAA.HHS has made no allowances for CSPs who claim to be outside the purview of HIPAA because they do not have the encryption key to the data. Explaining this, HHS has specifically called out the threat of “malicious actors,” and in the new guidelines has made CSPs take responsibility for breaches, even if they do not have direct access to the data or are protected by “no view” clauses in their contracts.

CSPs are allowed to store ePHI on servers outside the U.S.: This one was a bit of a surprise to me, since the general practice in the market between covered entities and their BAs is to house all data in cloud servers that reside in the U.S. Storing ePHI in overseas servers raises a whole new set of issues, including additional compliance with the data privacy laws of the host country. This can be a nightmare in places like the EU, where every country has its own legislation governing the privacy of healthcare data. For healthcare tech companies in the U.S that are focused entirely on the U.S market, the safe option would be to insist on data storage within the U.S.

Conduit exception denied to CSPs. An earlier guideline clarifies that conduit exception exempts entities such as the U.S Postal Service and delivery trucks. Considering that the vast majority of patient medical information is now electronically stored and transmitted (for which taxpayers spent over $30 billion in meaningful use incentives for an electronic health record backbone across the country), this might seem like an anachronism. It’s not clear if network providers such as AT&T are exempt, since there is an argument that they are no different from a postal service in their function. The bottom line is that CSPs are considered to have “persistent access” to data and are hence denied conduit exception.

HHS allows mobile access to ePHI in the cloud: What took them so long? ‘nuff said. However, this raises the ante for mobile app providers.

An important exception granted to CSPs is that they are outside the purview of the HIPAA rules to the extent of ePHI that is de-identified according to the Office for Civil Rights (OCR) rules. The complex and extensive guidance on the de-identification required to qualify for this exemption might make it cumbersome and risky for both parties in the BAA.

There are a few gaps in the guidelines that covered entities and BAs will need to work through:

Reporting of HIPAA breaches left to contracting parties: This could cause inconsistencies in reporting that provide an incomplete picture of the nature and extent of breach at any entity

Reconciling U.S privacy laws with international laws, especially in the EU, where every country has a different set of guidelines. HHS acknowledges these differences and urges covered entities and BAs to do risk assessment if choosing to store ePHI outside the U.S. An additional complexity is data access from locations such as India and the Philippines in outsourcing arrangements.

Certain providers (network carriers, middleware companies) may be exempt from HIPAA as conduit access providers, despite their role in transmitting ePHI. Data in motion is as vulnerable to cyberattacks as data at rest, and accountability needs to be specified for such entities.

The HHS guidelines targeting CSPs is very timely, and can potentially eliminate much of the contentious contract discussions regarding ePHI in the cloud. Most importantly, it recognizes the growing importance of cloud computing in healthcare and is the right step in the bringing these entities into the broader discussion on healthcare data security and privacy.

Originally published on. CIO


That the contents of third-party articles/blogs published here on the website, and the interpretation of all information in the article/blogs such as data, maps, numbers, opinions etc. displayed in the article/blogs and views or the opinions expressed within the content are solely of the author's; and do not reflect the opinions and beliefs of NASSCOM or its affiliates in any manner. NASSCOM does not take any liability w.r.t. content in any manner and will not be liable in any manner whatsoever for any kind of liability arising out of any act, error or omission. The contents of third-party article/blogs published, are provided solely as convenience; and the presence of these articles/blogs should not, under any circumstances, be considered as an endorsement of the contents by NASSCOM in any manner; and if you chose to access these articles/blogs , you do so at your own risk.


© Copyright nasscom. All Rights Reserved.