What Are the HIPAA Requirements for Email Encryption?
Tuesday, April 9th, 2019If you’re involved in the healthcare field, you may have wondered what HIPAA’s exact requirements are when it comes to email encryption. Understandably, not too many people are willing to read the 115 pages of the simplified regulation text, so the question tends to go unanswered.
The good news is that we’ve gotten someone to do it for you. They’ve trawled through the long and arduous document to pick out the exact HIPAA regulations concerning email encryption.
We’ve gone through and found out what the text actually says, as well as conducted some analysis to help you figure out just how your organization can comply with these requirements.
What Do the Regulations Actually Say?
There are a few different segments of the security rule which are pertinent to email encryption. The first one is section 164.306 Security standards: General rules:
(a) General requirements. Covered entities and business associates must do the following:
(1) Ensure the confidentiality, integrity, and availability of all electronic protected health information the covered entity or business associate creates, receives, maintains, or transmits.
(2) Protect against any reasonably anticipated threats or hazards to the security or integrity of such information.
(3) Protect against any reasonably anticipated uses or disclosures of such information that are not permitted or required under subpart E of this part.
(4) Ensure compliance with this subpart by its workforce.
Let’s unpack some of these terms a bit:
- Covered entity – As a simplification, a covered entity is essentially any healthcare-related organization that deals with data.
- Business associate – A business associate (BA) is a person or organization that a covered entity shares electronic protected health information (ePHI) with. This must be done under a business associates agreement (BAA)
- Electronic protected health information (ePHI) – This is basically any digital information that is both “individually identifying” and contains “protected health information”. “Individually identifying” information includes names, contact details, social security numbers and much more. “Protected health information” is any information related to a patient’s health, treatment or payment. Check out our article on ePHI for the specifics.
So let’s summarize things a little bit. Under the Security Rule, organizations in the healthcare field and those that deal with their sensitive data are obligated to protect it.
Let’s wade a little bit further into the text. It specifically talks about encryption in section 164.312 Technical safeguards:
(iv) Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information.
Notice how it says “addressable”? HIPAA has two different specifications when it comes to implementation, “required” and “addressable”. “Required” means that a certain mechanism must be in place for compliance.
“Addressable” means that there is flexibility in the mechanisms that can be used. This isn’t particularly specific, but it’s important to be aware that HIPAA is intentionally vague and technologically agnostic. This gives organizations the flexibility they need to come up with the best security measures for their own unique situation. It is not an excuse to be lax about security.
Are Encryption & Decryption Required?
At this stage, you may be thinking that you have found a loophole and you don’t technically have to use encryption. This assumption is kind of correct–nowhere in the HIPAA documentation does it specify that encryption and decryption must be used.
But unfortunately, things aren’t that simple. Let’s return to section 164.306, where it states that covered entities and business associates must:
(1) Ensure the confidentiality, integrity, and availability of all electronic protected health information the covered entity or business associate creates, receives, maintains, or transmits.
This time, we’ve put different terms in bold. So, while HIPAA does not state that covered entities have to use encryption, it does say that they need to ensure the confidentiality of any ePHI that is created, received, maintained or transmitted.
The big question is, “If you aren’t going to use encryption, what techniques are you going to use to guarantee confidentiality instead?” Will you put all of the data on flash drives, then lock them in metal boxes for storage and transit?
Sure, the text says that you don’t have to use encryption, but given the other requirements stated in the HIPAA documentation, encryption is the only reasonable solution.
When it comes to encryption, the HIPAA legislators are kind of like a parent who takes their child to a store, promising them that they can eat anything that they want. The child’s eyes light up with excitement, imagining all of the candy that they will be gobbling down in just a few moments
When they arrive, the child’s heart sinks – they are at the fruit store. Sure, they can have anything they want, but the only thing around them is fruit.
You don’t technically have to use encryption under HIPAA, but it’s pretty much the only thing on offer.
How Should You Use Encryption to Protect Email?
Since the HIPAA text doesn’t include any encryption requirements, the documentation isn’t particularly helpful for those organizations that want to be both compliant and secure. Thankfully, the National Institute of Standards and Technology (NIST), another government agency, has released its own documentation about email and how to keep it secure.
The guide is extensive, but some of the key takeaways are:
- Appropriate authentication and access control measures need to be in place.
- TLS should be used to connect to the email server.
- Mechanisms such as PGP or S/MIME should be used to encrypt sensitive data (such as ePHI).
If you don’t feel like reading such an exhausting document, you can turn to a HIPAA compliance specialist like LuxSci instead. Our HIPAA-Compliant Email includes all of these features and much more, helping your organization stay both secure and compliant.
