HIPAA Rules cover encryption, although the HIPAA encryption requirements have caused confusion for some healthcare organizations. One of the reasons is the use of encryption is not a required element of HIPAA. Encryption of protected health information is only an ‘addressable’ issue in the technical safeguards.
To add to the confusion about HIPAA encryption requirements, in the section covering transmission security, HIPAA-covered entities are required to “implement a mechanism to encrypt PHI whenever deemed appropriate.” With terminology that vague it is no surprise that many covered entities have been left confused.
It is important for covered entities to understand the difference between a required implementation specification and an addressable implementation specification.
A required implementation specification means covered entities must adopt appropriate controls to meet that specific aspect of HIPAA.
An addressable implementation specification means covered entities must implement appropriate controls if they have performed a risk assessment and determined that the specification is reasonable given the level of risk to the confidentiality, integrity and availability of PHI.
An addressable element of HIPAA cannot be ignored or put off. Ignoring an addressable implementation specification would be a violation of HIPAA Rules and would likely attract a significant financial penalty.
The phraseology “whenever deemed appropriate” could mean that a covered entity decides that encryption is not necessary as PHI is only communicated internally via a network protected by a firewall with appropriate access controls.
In such cases, the decision not to encrypt must be documented to show that a risk assessment has been conducted and a decision was taken by the covered entity not to use encryption. The reasons for that decision must be documented and the covered entity must stipulate what alternative controls have been implemented in place of encryption to provide a similar level of protection. Documenting the decision shows the lack of encryption was not an oversight.
Why are HIPAA Encryption Requirements Only Addressable?
Given the volume of healthcare data breaches, in particular the number of unencrypted devices containing PHI that are lost or stolen each year, why are HIPAA encryption requirements only an addressable implementation specification? Surely such an important security control should be required?
When HIPAA Rules were first penned, it was clear that technology would advance and specific measures such as encryption may not be the only or best safeguard to prevent accidental disclosure of ePHI. In the future there could be any number of alternative controls that would offer the same level of protection, or even better protection than encryption.
Specific technological controls were therefore left to the discretion of the covered entity. That way, covered entities could select the most appropriate safeguards and legislators would not have to keep releasing updates when technology advanced.
Covered entities should not that not all forms of encryption are equal. If after performing a risk assessment encryption is determined to be appropriate, covered entities should choose a form of encryption that meets the standards of security detailed in NIST Special Publication 800-111.
Ignore HIPAA Encryption Requirements at Your Peril!
The failure to encrypt PHI at rest and in transit or employ an alternative security measure that offers a similar level of encryption could result in a HIPAA violation penalty from the HHS’ Office for Civil Rights. Many covered entities have already received fines for the failure to encrypt data on portable devices.
In February 2017, Children’s Medical Center of Dallas settled potential HIPAA violations with OCR which were discovered during an investigation of a breach of 3,800 patient records. Those records were stored on an unencrypted Blackberry device that was lost. The failure to encrypt the PHI on the device, or use an equivalent alternative measure, resulted in a settlement of $3.2 million.