How does GDPR compare to HIPAA?
Co-founder & Chief Technology Officer
At the AWS re:Invent conference earlier this month, GDPR was a major area of interest from attendees though AWS has little content coverage for GDPR. GDPR, which stands for General Data Protection Regulation, is the acronym for the much anticipated new EU security and privacy framework that goes into effect in May of 2018. GDPR leaves some discretion to EU member states but, as a general rule, and the reason it is getting so much attention, is that it applies across all EU Member States. The purpose of this post is to introduce those familiar with healthcare privacy and security in the United States, namely those concerned with HIPAA, to GDPR. This post doesn’t get into technical requirements, or even security requirements more generally, but instead focuses on the broader principles and privacy guidelines for health data under GDPR.
The process of expanding and proving compliance across multiple frameworks, both for us and our customers, is not new to us at Datica. You can follow our changes through the updates to our open source policies and procedures; our policies define the operational and technical controls we use. We started with HIPAA and quickly expanded to leverage HITRUST as the core risk framework for our internal compliance program. We then added SOC2, Privacy Shield, and, most recently, GxP. We will complete our full GDPR audit in 2018 ahead of GDPR going into effect. Our goal has always been to build and maintain one compliance program to prove compliance with multiple frameworks. In the paraphrased words of HITRUST: one control, many frameworks.
GDPR applies to all personal data storage
GDPR is getting outsized attention because it applies to all personal data storage and processing, limiting or putting at risk all companies that leverage individually identifiable data (think of Google and Facebook, not just healthcare providers, payors, life sciences, and digital health companies). GDPR also applies to organizations that control or process data for citizens of EU Member States regardless of where the organization is based.
Healthcare and health data, “data concerning health”, is one subset of GDPR and specifically applies to data concerning physical and mental health, genetic data, and biometric data. The good news is that GDPR has considerable overlap with HIPAA, and to an even larger extent, HITRUST.
GDPR entities: controllers and processors
In the world of HIPAA, you’re either a covered entity (CE) or a business associate (BA); for the purposes of this guide, subcontractors are just business associates of business associates. In the world of GDPR, you’re either a controller or a processor. The structures don’t mirror each other 100% but controllers, like covered entities, are the organizations that ultimately own personal data and processors, like business associates, provide services, or data processing, for controllers.
The major difference is that HIPAA strictly defines covered entities based on functions in healthcare as providers, payors, and clearinghouses whereas GDPR defines controllers as “natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of processing of personal data.” HIPAA defines entities based on the function of the organization and GDPR defines it based on the ownership of data; this is a consistent theme throughout GDPR.
My interpretation of GDPR, and a significant area of difference that healthcare organizations need to consider, is that direct to consumer health offerings like Fitbit, MapMyRun, or an application for medical adherence created by a pharmaceutical company, would be considered controllers whereas in the US, under HIPAA, they wouldn’t need to adhere to HIPAA until they worked with customers or patients of a provider or payor. When those same direct to consumer companies in the US did work with providers and payors, they would be considered business associates and not covered entities. This flips the model for these companies as they are now the focal point of data control and risk under GDPR.
Controllers, like covered entities, are ultimately responsible and liable for the protection of data. As such, controllers need to put data processing agreements (DPA) in place with processor partners; similarly, covered entities under HIPAA must put business associate agreements (BAAs) in place with business associates. GDPR is more prescriptive in terms of what needs to be included in a DPA, something that is much needed in the US but is lacking in the HIPAA rules. The prescriptive nature of DPAs ensures additional protection and transparency over the wild west of BAAs in the US. One of the things GDPR requires, with some rare exceptions, in DPAs is that data is destroyed once the relationship between controller and processor ends; this severely limits the ability of processors to aggregate and retain personal data for future use. And, similarly to the US and HIPAA after the Omnibus rule was passed, processors under GDPR must have similar DPAs in place with their own processor partners.
GDPR breach reporting
Under GDPR, there are strict breach reporting requirements. The timeline to report breaches is 72 hours from becoming aware of a breach. Any organization adhering to HIPAA would have breach reporting timelines in policies, contracts, and/or BAAs; but, most breach reporting times we see from major cloud providers and vendors are on the order of days (10 days being the shortest we’ve seen), weeks, and even months. The lowest time we’ve seen for breach reporting is our own Datica breach reporting time, which is 4 hours. For entities looking to comply with GDPR, there are changes that need to be made both technically and operationally to commit to 72 hour breach reporting.
Health data access under GDPR
GDPR puts forth clear guidelines for when health data can be processed, or essentially when it can be accessed. Under GDPR, health data can only be accessed 1) with explicit consent from the individual, 2) for health and social care, and 3) for public health (cross border containment being the example given). There are some nuances to this, specifically with data for scientific or clinical research, but those are mainly only with explicit consent. HIPAA similarly defines permitted uses and disclosures of health data for 1) treatment, 2) payment, and 3) healthcare operations.
Some of the harder areas of GDPR, at least in comparing it to HIPAA, are the rights of individuals to get access to all of their data and to be forgotten (have all their data deleted). Healthcare data is much more extensive than other types of data like payment data; it’s the reason complying with HIPAA isn’t the same as complying with PCI where you can essentially outsource payment processing to Stripe. Granting access to all personal health data or being able to delete all health data is a very high bar to meet, especially for large, bloated EHRs and legacy healthcare software.
Data Protection Impact Assessments
One of the things I like a lot about the GDPR is the overarching principle of data protection by design and default. Sadly, security, and compliance, is often an afterthought at best or perceived unnecessary box to check at worst. GDPR explicitly attempts to resolve this pattern. GDPR goes further than HIPAA, and in this way is very similar to HITRUST, in that it anchors risk assessment, analysis, and management to the entire lifecycle of products and services. GDPR requires controllers and processors to conduct Data Protection Impact Assessments (DPIAs), which are just a longer name for a risk assessment. These DPIAs should be performed before the start of development work and done periodically throughout the lifecycle of a product to ensure data is protected and secure. This risk-based model is similar to the way organizations are supposed to use HITRUST to develop a baseline risk model and then consistently update that baseline model. It’s the model we use at Datica and has made it easy for us to maintain continuous compliance for us and our customers.
Why should you care about the GDPR? If you do anything with healthcare data in the EU, then you are at risk of significant penalties for violations. The penalties for violating GDPR can be up to $20m or 4% global revenue, whichever is highest. If you want to work in the EU or are already in the EU, you need to expand your compliance program and posture to minimize your risk.
Going forward, we’ll get into technical details and mappings between HIPAA and GDPR. We’ll also provide specific guidance to inform expansionary changes to security and compliance programs to bring them in line with GDPR. Fundamentally, addressing HIPAA and GDPR is about having security as a core tenet of operations; the major difference is ensuring that evidence and documentation is created to prove compliance with each framework.
