HIPAA encryption is an addressable implementation specification of the Security Rule’s Technical Safeguards for Protected Health Information at rest (§164.312(a)) and in transit (§164.312(e)). Viable alternatives to HIPAA encryption are limited, may require a high level of technical skill to deploy, and could be incompatible with other systems and databases.
What is HIPAA Encryption?
HIPAA encryption is the process of transforming data to “into a form in which there is a low probability of assigning meaning [to the data] without use of a confidential process or key” (§164.304). Once “transformed”, encrypted data should be rendered unusable, unreadable, or indecipherable to unauthorized individuals when the data is at rest (in compliance with §164.312(a)) and in transit (in compliance with §164.312(e)).
To comply with the standards for HIPAA encryption, not only is it necessary to implement software for transforming data, but it is also necessary to maintain the encryption and decryption “process or key” separate from the data they are used to encrypt or decrypt. Because the most secure types of encryption rely on multiple encryption keys, it may also be necessary to implement a key management system.
Due to the skills required to manage all the necessary encryption processes to the standard required by HIPAA, many covered entities and business associates subscribe to services that support encryption by default (i.e., Microsoft 365). Alternatively, they may subscribe to a service that enables encryption on an otherwise non-compliant service (i.e. Paubox) provided the service is supported by a Business Associate Agreement.
What is an Addressable Implementation Specification?
An addressable implementation specification is a requirement of HIPAA that has to be implemented unless there is a justifiable reason why the implementation specification is not “a reasonable and appropriate safeguard in its environment, when analyzed with reference to the likely contribution to protecting electronic Protected Health Information” (§164.306(d)).
There are circumstances in which HIPAA encryption may not be a reasonable and appropriate safeguard for protecting electronic Protected Health Information. For example, if a healthcare provider maintains Protected Health Information in paper format and uses a third party’s secure portal to conduct Part 162 transactions, encryption would not be necessary.
However, such circumstances are increasingly rare; and, although HHS’ Office for Civil Rights has acknowledged that HIPAA encryption is not mandatory, most covered entities and business associates create, receive, store, and transmit Protected Health Information electronically using channels of communication for which encryption is a reasonable and appropriate safeguard.
HHS Guidance on HIPAA Encryption Standards
When the HIPAA Security Rule was published in 2003, HHS stated it was “committed to the principle of technology neutrality and […] consistent with this principle, specifying an algorithm strength or specific product would be inappropriate. Moreover, rapid advances in the success of ‘‘brute force’’ cryptanalysis techniques suggest that any minimum specification would soon be outmoded.”
At the time, the Advanced Encryption Standard (AES) was still in its infancy, and many applications were using versions of the Data Encryption Algorithm (DEA/TDEA/3DES etc.) that only had a key length of 56 bits. DEA encryption has since been proven to be ineffective at safeguarding Protected Health Information; and, in 2013, HHS published guidance on HIPAA encryption standards.
According to the guidance, Protected Health Information at rest should be encrypted to the standards recommended in NIST SP 800-111 (AES-128 or higher), and Protected Health Information in transit should be encrypted to standards which comply with NIST SP 800-52” (TLS 1.2 or higher) or “others which are FIPS 140-2 validated” (for example, OpenPGP and S/MIME).
Alternatives to HIPAA Encryption
Alternatives to HIPAA encryption are similar to encryption inasmuch as they consist of measures such as tokenization, hashing, and pseudonymization. Deploying these measures requires a high level of technical skill, and it may be necessary to reconfigure existing systems and networks to accommodate them – assuming it is possible to reconfigure existing systems and networks to be compatible with the alternatives to HIPAA encryption.
Whether or not an alternative to the HIPAA encryption requirements is suitable – or, indeed, whether or not it is necessary to comply with the HIPAA encryption requirements – is a question that should be resolved by a HIPAA risk assessment. If the results of a risk assessment indicate the need for encryption or an encryption alternative, then the standards relating to the encryption of Protected Health Information must be complied with.
Photo Credit: stock.adobe.com
