FRSecure works with many hospitals, clinics and medical professionals who are trying to comply with HIPAA (The Health Information Portability and Accountability Act). When we review the security of IT infrastructure and architecture, a discussion of the need for data encryption commonly comes up. As a matter of best practice, we recommend that all organizations encrypt PHI (Protected Health Information) both while stored and during transmission. However, many of our clients have asked “Is data encryption REQUIRED for compliance with HIPAA?” In response, we recently published a whitepaper on data encryption and HIPAA compliance. If your organization is processing, storing or transmitting health information and you’ve wondered exactly how HIPAA compliance impacts this data, our whitepaper can be a great resource.

Overview of the HIPPA Security Rule

The HIPAA Security Rule establishes national standards to protect individuals’ electronic personal health information that is created, received, used, or maintained by a covered entity. The Security Rule requires appropriate administrative, physical, and technical safeguards to ensure the confidentiality, integrity, and security of electronically protected health information.

The Security Rule is located at 45 CFR Part 160 and Subparts A and C of Part 164.

What parts of the Security Rule are concerned with data encryption?

In Subpart C of part 164, there is a specific language to address the required technical controls to protect “electronic protected health information” or ePHI. There are two HIPAA encryption standards in particular. In both cases, the encryption implementation spec is “addressable” and not “required.”

What is the difference between addressable and required implementation specifications in the Security Rule?

If an implementation specification is described as “required,” the specification must be implemented. The concept of “addressable implementation specifications” was developed to provide covered entities additional flexibility with respect to compliance with the security standards.

In meeting standards that contain addressable implementation specifications, a covered entity will do one of the following for each addressable specification:

(a) implement the addressable implementation specifications;

(b) implement one or more alternative security measures to accomplish the same purpose;

The covered entity’s choice must be documented. The covered entity must decide whether a given addressable implementation specification is a reasonable and appropriate security measure to apply within its particular security framework. For example, a covered entity must implement an addressable implementation specification if it is reasonable and appropriate to do so, and must implement an equivalent alternative if the addressable implementation specification is unreasonable and inappropriate, and there is a reasonable and appropriate alternative.

This decision will depend on a variety of factors, such as, among others, the entity’s risk analysis, risk mitigation strategy, what security measures are already in place, and the cost of implementation. The decisions that a covered entity makes regarding addressable specifications must be documented in writing. The written documentation should include the factors considered as well as the results of the risk assessment on which the decision was based.

If encryption is not required under the Security Rule, what must I do to comply?

With addressable encryption implementation specifications, both a covered entity and business associate must consider implementing encryption as a method for safeguarding electronic protected health information (ePHI). If encryption is not used by a covered entity or business associate, clear documentation of the risk analysis, the decision not to encrypt, and the specifics of an equivalent level of protection must be in place to prove due diligence to protect ePHI.

While encryption is “addressable” under HIPAA, it is highly recommended. OCR (Office for Civil Rights) Director Leon Rodriguez was quoted:

“…Encryption is an easy method for making lost information unusable, unreadable and undecipherable.” We will not debate if encryption is “easy” in this white paper, but it is key to recognize that the Department of Health and Human Services, who enforces HIPAA violation investigation and penalties through its Office for Civil Rights considers encryption well within reach with the burden of proof on the organization that chooses not to implement it.”

Is there a requirement for encryption in the HITECH Act?

The Health Information Technology for Economic and Clinical Health Act (HITECH Act) is part of the American Recovery and Reinvestment Act of 2009 (ARRA). ARRA contains incentives related to health care information technology in general (e.g. creation of a national health care infrastructure) and contains specific incentives designed to accelerate the adoption of electronic health record (EHR) systems among providers.

Because this legislation anticipates a massive expansion in the exchange of electronic protected health information (ePHI), the HITECH Act also widens the scope of privacy and security protections available under HIPAA; it increases the potential legal liability for non-compliance; and it provides for more enforcement.

There are no specific requirements for encryption under the HITECH Act. However, the HITECH Act modified the original data breach requirements in the HIPAA Security and Privacy Rules. Under the HITECH changes, a demonstrated implementation of data encryption allows an organization to bypass the breach reporting requirements. This is referred to as “Safe Harbor” and guidance from the Secretary of the HHS was provided around the use of this provision:

”Covered entities and business associates that implement the specified technologies and methodologies with respect to protected health information are not required to provide notifications in the event of a breach of such information–that is, the information is not considered ‘unsecured’ in such cases. ”

“[w]e encourage covered entities and business associates to take advantage of the safe harbor provision of the breach notification rule by encrypting limited data sets and other protected health information pursuant to the Guidance. If protected health information is encrypted pursuant to this guidance, then no breach notification is required following an impermissible use or disclosure of the information.”

HIPAA Encryption Standards of Data at Rest

The HIPAA Breach Notification Rule provides guidance on encryption, stating that the proper standards for encrypting data at rest are aligned with the NIST (National Institute of Standards and Technology) Special Publication 800-111, Guide to Storage Encryption Technologies for End User Devices. The NIST standard approves of the AES algorithm (Advanced Encryption Standard).

Data at rest can include database fileshares, workstations, laptops, tablets, iPads, phones, USB drives, flash drives, data backup tapes, CDs and DVDs, cameras and external hard drives.

The SANS Institute, specializing in Internet security training, recommends employing whole-disk or folder-level encryption for ePHI. For ePHI in databases, they recommend full database or column-level encryption. Additionally, key management procedures and processes that separate duties and least-privilege for users and applications are important for ePHI at rest. Lastly, they recommend hashing or digitally signing all stored ePHI.

HIPAA Encryption Standards of Data in Transit

For data in transit (also referred to as “in flight”), complying with the Federal Information Processing Standards (FIPS) 140-2 also includes standards described in NIST Special Publication 800-52, 800-77 and 800-113. Data in transit crosses the Internet, wireless networks, from tier to tier within an application, or across wired or wireless connections without being stored. Data in transit remains in a non-persistent state – where it’s not being written to disk or other media or being retained.

The SANS Institute recommends implementing a VPN (Virtual Private Network) using either IPSec or TSL for all remote systems that need to transmit ePHI, and to implement encryption for all systems and users that may need to email ePHI. Many organizations add two-factor authentication to their VPN login process such as Duo Security to further protect data and prevent unauthorized use.

Appendix – Full text of 45 CFR 164.312 which considers data encryption

A covered entity or business associate must, in accordance with § 164.306:

Standard: Access control. Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in § 164.308(a)(4).

o Implementation specifications:

Unique user identification (Required). Assign a unique name and/or number for identifying and tracking user identity.

Emergency access procedure (Required). Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.

Automatic log off (Addressable). Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.

Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information.

Standard: Audit controls. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.

Standard: Integrity. Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.

Implementation specification: Mechanism to authenticate electronic protected health information (Addressable). Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner.

Standard: Person or entity authentication. Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.

Standard: Transmission security. Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.

Implementation specifications:

Integrity controls (Addressable). Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of.

Encryption (Addressable). Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.