As more and more organizations turn to cloud solutions to meet modern technology challenges, there has been rising concern about HIPAA/HITECH compliance for healthcare organizations. (From here on, we’ll just say “HIPAA compliance” to cover both, though you can read about the differences here.)
Many believe that, if they simply adopt a well-known public cloud that is HIPAA compliant, they can “check the box” and rest easy knowing that their medical data and health records are safe.
That attitude would be a little premature, however. While it’s true that using a well-known public cloud (or even a private cloud from a reputable vendor) is a good first step toward HIPAA compliance, most of the work is still left to the covered entity and/or its managed service provider(s).
Time, then, to dispel some of the misconceptions around what it means to be a “HIPAA-compliant” cloud services provider, and review what needs to be done in organizations that are already-covered entities seeking to use public clouds.
A Quick Overview of HIPAA Compliance and “Business Associates”
HIPAA encourages the use of electronic medical records for efficiency and easy sharing. Along with this, the law includes standards for protecting the security and privacy of this information, referred to as protected health information (PHI). PHI includes most personally identifiable health information, including insurance and billing information, diagnosis data, clinical care data, lab results, and imaging data (including images themselves).
The HIPAA rules governing the security of this data affect organizations tagged as HIPAA-covered entities (or simply “covered entities”). Typical covered entities include hospitals, insurance companies, medical services providers, research facilities, and any other entities that handle patient data. The rules also extend to business associates who handle medical data on behalf of other covered entities—including companies offering cloud services and hosting.
More explicitly: Under HIPAA, any entity that is involved in the creation, maintenance, receipt, or transmission of PHI is regarded as a business associate. This includes cloud providers, whether they offer a public, private, or hybrid cloud. Covered entities that plan on using the services of a business associate need to ensure that they are entering into a HIPAA-compliant business associate agreement (BAA). This will help them ensure that their cloud infrastructure has the same HIPAA protections that their on-premise systems would.
But the task of ensuring HIPAA compliance for the cloud doesn’t stop there. Indeed, it is only the start. It is largely up to the cloud customer to ensure HIPAA compliance by correctly configuring their cloud infrastructure, monitoring for compliance, and following through with remediation if there are any problems.
What Does it Mean for a Public Cloud to be HIPAA Compliant?
It can’t be said enough: No cloud platform, public or otherwise, is inherently 100% HIPAA compliant. Or, perhaps more accurately: Large public clouds (like AWS and Azure) support HIPAA compliance, but they cannot offer or guarantee this compliance. This is because compliance comes not from having a certain kind of technology or platform, but rather from configuring the platform (and, ultimately, handling the data) in appropriate ways.
Take Amazon’s AWS, for example, which is currently considered the market leader when it comes to public cloud offerings. AWS has all the protections that satisfy HIPAA security rules, and Amazon has a standard BAA that they will sign with healthcare organizations. All of that is how it should be.
But…for a covered entity to be HIPAA compliant while using AWS, several things need to happen. Access permissions need to be set correctly for all Amazon services used. Appropriate encryption will need to be put into place. The covered entity will need an Amazon artifact account to access compliance-related information. Appropriate reports demonstrating compliance will have to be generated routinely. And so on.
So why doesn’t Amazon handle most of these things? It has to do with the distinction between providing a platform versus actually accessing and handling the data. AWS uses a “shared responsibility” model that makes a distinction between security “of” the cloud and security “in” the cloud. Amazon can guarantee that its infrastructure is secure, and that it has the appropriate tools for its customers to be HIPAA compliant (security of its cloud). But it cannot, for obvious reasons, assign or restrict access rights to your employees. Likewise, it can help you generate compliance reports showing that the infrastructure is secure, but it cannot report on HIPAA compliance “across the board,” as it were. Your organization will need to guarantee the security of the data being stored in the cloud.
Here’s a metaphor that might help. Suppose you bring your laptop to a cafe to get some work done remotely. The cafe owner can ensure the security of the cafe: She can guarantee that the cafe is locked before and after business hours, that the back door is secure so thieves can’t sneak in, that the premises are well lit, and so on. But if you get up to use the bathroom and leave your laptop behind, or if you loan it to someone you don’t know well, it is you who have failed to secure your belongings.
In summary, when a public cloud provider says they are “HIPAA compliant,” what they are saying is that the underlying infrastructure is secure, and that they provide tools for ensuring compliance. Covered entities must then use these tools appropriately and follow up with appropriate monitoring and reporting.
What You, as a Covered Entity, Still Need to Do to Maintain HIPAA Compliance
So let’s get specific: What is left over for the covered entity to do after they have engaged a public cloud service?
Sign the BAA. The BAA is literally a contract between the covered entity and the service provider that is the business associate. The BAA should spell out allowable uses and disclosures of PHI, as well as the safeguards in place to prevent unauthorized access or use of that data. If you use multiple cloud providers (i.e., you have a multi-cloud environment), you might need to sign multiple BAAs.
Set up appropriate access controls. Covered entities must ensure that access controls are carefully configured so that any given piece of PHI can be accessed only by authorized individuals. Procedures should be set in place for consistently granting, revoking, and reviewing such access over time, as needed.
Set up firewalls that provide logging. On-premise data centers and workstations should already be behind a firewall that is compliant. (In fact, this is needed in order to pass a typical HIPAA audit.) HIPAA rules also require logging, auditing, and monitoring access to PHI data, which means that any firewalls or UTMs, whether on-premise or in the cloud, will need such logging enabled.
Set up controls for file integrity monitoring. Integrity controls are meant to ensure that PHI has not been altered or destroyed in any way that is unauthorized. When the right controls are in place, your organization should be able to identify when unauthorized access happens, and when changes to data are made. They should also be able to verify the “authenticity” of any given piece of healthcare data.
Make sure encryption is in place. Any data shared via the cloud should be protected by end-to-end encryption, and any data stored in the cloud should be encrypted at rest. Note, however, that encryption alone is not enough to meet all HIPAA Security Rule requirements.
Set up appropriate processes for notification of breach. Data breaches do happen. In the event of such a breach, both covered entities and business associates are required to document and investigate the incident. Breaches must be reported to HHS OCR, and all affected parties must be notified.
Get assistance. Unless you are a healthcare IT company or compliance company, the above steps are probably not part of your core competencies. As your cloud footprint expands, the terrain will become more and more complicated. When this happens, it helps to have a third-party provider with in-house HIPAA expertise who can guide you through the process and ensure compliance in the public cloud.
For example, we here at Connectria help many healthcare organizations maintain compliance with HIPAA/HITECH security standards for the storage of PHI. We can do this whether workloads are housed in one of our private clouds or in a public cloud like AWS. We can help with audit trails and reporting, so your in-house IT teams can worry about more strategic aspects of your business.
Though simple in theory, HIPAA/HITECH compliance can be exceedingly technical (and tedious) when it comes to actual implementation. Leveraging the expertise of others is not a bad idea…especially when the penalties involved with non-compliance can be so steep.
For more about HIPAA compliance and the pitfalls of doing it wrong, we recommend our article “6 Mistakes Jeopardizing Your HIPAA Compliance.”
You can also read more about specific aspects of HIPAA compliance for major public cloud providers in these articles:
- You Can be Compliant in an AWS Cloud
- Migrating HIPAA compliant workloads to the public cloud: Azure & AWS
- HIPAA Compliant Hosting
The exact details about the difference between HIPAA and HITECH can be found here.
Still have questions? Contact us.