For all of its benefits, cloud computing poses very real dangers to covered entities responsible for safeguarding protected health information (PHI).

The cloud model, which the IT industry has been embracing for its up-front cost savings and efficiencies for years now, is more recently being recognized by the healthcare realm for its potential to serve as an ideal infrastructure for Health Information Exchange (HIE) — a main component of the Electronic Health Records (EHR) meaningful use initiatives. What’s more, the cloud can provide easy, affordable access to the latest medical applications, such as e-prescribing or leading-edge diagnostic tools.

[Related: The 5 (PHIve) steps you can take now to protect PHI.]

All of which could contribute to the strong growth of cloud computing in healthcare, according to CompTIA research. But PHI security dangers lurk in the cloud. Here’s a look at how to mitigate some of those.

Legal Liability
In cloud computing, where shared resources — hardware infrastructure, software, and data storage — are constantly changing hands among different users, securing PHI is like shooting at a moving target. With the exception of a private cloud environment, covered entities have little or no control where or how their data is moved, processed, and stored.

This lack of control presents compliance issues for the covered entity. As noted in The Financial Impact of Breached Protected Health Information: A Business Case for Enhanced PHI Security, a seminal report by the American National Standards Institute (ANSI), The Santa Fe Group/Shared Assessments Program Healthcare Working Group, and the Internet Security Alliance (ISA), the covered entity is as responsible for the security of its PHI on the cloud as it is for PHI in its own environment. What’s more, the report says, both the covered entity and the cloud provider could be subject to penalties under HIPAA and/or state regulations for a breach of PHI.

Between a cloud and a hard place
To limit liability in the case of a data breach, covered entities often require their business associates to sign an agreement. The terms of a cloud provider’s service-level agreement (SLA), however, disclaim any such liability on its part. And no legal precedent exists to change that. Perhaps part of that is practicality. Detecting responsibility for a data breach among cloud managers, storage providers, and application developers — none of whom have been tested for liability — is nearly impossible.

Larger covered entities can offset much of these dangers with a private cloud; they simply limit access to their own organization and subsets, such as business associates. Smaller covered entities are at the mercy of cloud providers they can afford.

There’s not an app for that
Cloud-level applications also present problems for covered entities small and large. First is security. Federal law requires that “all access to … PHI must be controlled and must be limited to the ‘minimum necessary’ data fields required for the purpose involved.” This means access is limited to only authorized and authenticated users, and that IT can log and audit all accesses. But this is a function of the application itself; not all applications are designed to meet such security needs.

The second problem is application interoperability. A large medical center recently recounted that a major concern was not the cloud infrastructure, but the inability to move data smoothly and securely between applications, leaving data at risk for exposure. Developing standards and protocols for interoperability between two applications is up to the vendors, but is often not a high priority.

Third-party validation
As mentioned earlier, smaller covered entities have little say in the way a cloud provider secures the PHI in their care. One way to level the playing field would be for clinics and other small covered entities to, as a group, ask a medical association or organization to create a certification for cloud providers that meet HITECH/HIPAA security requirements. A similar program already exists in the federal government, FedRAMP, the Federal Risk and Authorization Management Program.

What you can do now
The security concerns of cloud computing needn’t dissuade covered entities from enjoying the benefits. One of the most important things is to know the risks. Covered entities should carefully review the terms and conditions of the SLA to understand exactly what their liabilities and risks are — then be prepared to absorb those risks.

[Related: 8 security questions to ask your business partners.]

While covered entities have little control over the security of their PHI in a cloud environment, they can control their response to a data breach. An inventory of Personal Identification Information and PHI as well as privacy and security risk assessments can help demonstrate compliance and mitigate the impact of a data breach. Likewise, health entities should enact an incident response plan that includes roles and responsibilities for team members during a privacy event and provides instructions on determining notification requirements, including to regulatory authorities. And, of course, nothing can replace an organization’s commitment to their patients, be it through caring, appropriate notification, consumer education, medical identity monitoring and recovery, and other remediation services.
 

Rick Kam, CIPP, is president and co-founder of ID Experts. Rick is also chairing the “PHI Project,” a seminal research effort to measure financial risk and implications of data breach in healthcare, led by the American National Standards Institute (ANSI), via its Identity Theft Prevention and Identity Management Standards Panel (IDSP), in partnership with the Shared Assessments Program and the Internet Security Alliance (ISA).