HIPAA and Encryption: A Guide

Modified on Thu, 7 Aug at 1:53 PM

DISCLAIMER: The information provided in this article, other knowledge base articles, and the Compliancy Group website do not, and are not intended to, constitute legal advice. All information, content, and materials in the Knowledge Base and on the Compliancy Group website are for general informational purposes only.

Introduction

This article discusses the concept of encryption in the context of HIPAA.

What is Encryption?

The HIPAA Security Rule defines encryption as “the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key.” 

An encryption key is a string of bits (data) that is used to encode and decode data using cryptographic algorithms. A cryptographic algorithm, also known as a cipher or encryption algorithm, is a mathematical procedure that transforms data into an unreadable format to protect it and ensure its secrecy. This process is called encryption.


Where is Encryption Mentioned in the HIPAA Security Rule?


Encryption is mentioned twice in the HIPAA Security Rule. Each mention is in the “Technical Safeguards” requirement of that rule (45 CFR 164.312), and appears as a measure, or implementation specification, to be implemented. 


The first mention is in the Technical Safeguard “access controls” standard. To implement access controls, covered associates and business associates must, among other measures, implement:


(iv) Encryption and decryption:  Implement a mechanism to encrypt and decrypt electronic protected health information.   (45 CFR 164.312(a)(2)(iv)). 


The second mention is in the Technical Safeguard “transmission security” standard. To implement transmission security, covered entities and business associates must, among other measures, implement:


(ii) Encryption (Addressable).  Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate. (45 CFR 164.312(e)(2)(ii)).


What is End-to-End Encryption?


End-to-End Encryption (E2EE) safeguards the privacy of messages exchanged by individuals. With end-to-end encryption, the recipient must "unlock" or "unencrypt" a message before they can view it, using their unique key.  Only the recipient's unique, private key is capable of decrypting and reading the message.  An advantage of E2EE is that there is no third-party access; even if a server or service provider intercepts or transmits the message, the server or service provider cannot decrypt the message, since they do not have the unique, private key. 


Through this process, all encryption and decryption take place on the users’ devices. Therefore, there is no opportunity for an intermediary to read user data. 

HIPAA does not strictly mandate end-to-end encryption (E2EE) for all communications. HIPAA does not mandate any one type of encryption. What the HIPAA Security Rule does require is that electronic communications such as email and text that contain PHI must have appropriate safeguards in place to protect the communications from unauthorized access. End-to-end encryption is an example of such a safeguard.

What is TLS?

TLS stands for "Transport Layer Security."  TLS 1.2+ encryption is a key transport layer protocol. TLS 1.2 encryption secures the communication channel between a client and a server, preventing eavesdropping and tampering during transmission. Use of TLS 1.2+ (as opposed to older versions of TLS) is a must for anyone doing business on the modern Internet. TLS 1.2+ encrypts data in transit - data being transmitted from one point to another. TLS 1.2+ is considered a minimum "encryption best practice" to use when transmitting PHI via email or text. However, TLS 1.2+ does not encrypt data at rest - data being stored. 


How Can Data at Rest be Encrypted?


A well-known algorithm can be used to encrypt data that is not being transmitted - data that is "at rest." This algorithm is known as AES (Advanced Encryption Standard). This algorithm can be implemented on hard drives and cloud storage (among other ways), to encrypt data before that data is "written" to storage. Server-side encryption (SSE) encrypts messages as soon as they are received. Server-side encryption protects data at rest.

How Can Both Data at Rest and Data in Transit be Encrypted?

One method of encryption, that secures both data in transit as well as data at rest, is referred to as "layered TLS SSE encryption." Layered TLS SSE encryption applies Transport Layer Security (TLS) to secure data in transit, often using server-side encryption (SSE) for data at rest. However, this method of encryption requires an additional component to be considered end-to-end encryption. To achieve true end-to-end encryption, the data must be encrypted on the sender's device before being transmitted via TLS to the server, and only decrypted on the recipient's device. To ensure that the service provider cannot access or decrypt data, client-side encryption (CSE) can be added to layered TLS SSE encryption.  


When May PHI be Encrypted?


Under the HIPAA Privacy Rule right of access requirement, covered entities may send patients their PHI through unencrypted communications, if and only if the covered entity has first warned the patient of the risk that an unsecured communication may be intercepted, and the patient has then consented to the communication with awareness of the risk.


HIPAA does not have a “consent to unsecured communication” provision other than the one discussed above. As such, communications of PHI, between providers, between providers and business associates, between business associates, and between HIPAA-covered entities and entities not covered by HIPAA, if permitted by HIPAA to be exchanged, should be encrypted using a method of encryption that appropriately safeguards the PHI.  


Covered entities and busness associates that utilize an encryption service for PHI should enter into a business associate agreement with the service provider.

 




Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article