I’ve long advocated encrypting personally identifiable information (PII), which includes protected health information (PHI), stored (”data at rest”) on all types of mobile computers and mobile storage devices.

If PII can walk away on human legs (or other transport), it is at risk of being lost, stolen, forgotten, misplaced, and any number of other bad things that all unauthorized persons could take the PII and do bad things with it.

As with implementing any type of safeguard, security should be applied based upon risk.

You don’t need to take time and effort to come up with any type of specific number to show that PII traveling on legs/wheels/skates/etc is a high risk activity.

Just look at all the ongoing privacy breaches and you will see that the huge proportion of them occurred because PII on mobile storage was clear text. If the PII was strongly encrypted, the PII would have been safe, even in the hands of crooks who would not have the means to decrypt it.

While the word “encrypt” does not occur even once within the ARRA, the guidance that the Department of Health and Human Services (HHS) provides for complying with the HITECH Act portion of the ARRA is full of encryption direction. (Scroll down to “HHS Encryption Guidance for HITECH Act compliance” below to see the excerpts from that direction.)

The HHS guidance specifies that if encryption solutions are used that meet the minimum specified standards, then if PHI is encrypted using those solutions, and a security incident occurs in which an unauthorized individual (e.g., a crook) gets his or her hands on the PHI file, it would not be considered as a privacy breach, and notification would not need to occur.

The HITECH Act itself does *NOT* require encryption!

The HITECH Act specifies the type of encrypted PHI that is considered as making PHI secure, requiring no notice, in the event of a security incident.

Keep in mind this is part of the larger HIPAA Privacy and Security Rules.

And as the HHS HITECH Act guidance clearly states:

“Covered entities must comply with the requirements of the HIPAA Privacy and Security Rules by conducting risk analyses and implementing physical, administrative, and technical safeguards that each covered entity determines are reasonable and appropriate.”

So, to determine whether or not you should encrypt PHI, *you need to conduct risk analysis and then base your decision to encrypt upon the results.*

So, back to the question, “What’s your interpretation of encryption obligations for PHI data-at-rest under HITECH?”

PHI can be “data-at-rest” in any of a number of locations! The levels of risk in each of those locations will vary. Let’s consider a few…

• PHI in storage on a USB thumb drive that a doctor, insurance broker, whomever, carries around in a pocket, briefcase, etc. Recent history shows that such small and mobile data storage devices are easily lost, stolen, or forgotten. Is this a significant risk? I would say in most to all cases, YES! You don’t need to do a formal risk analysis to know that large numbers of privacy breaches have occurred from clear text PII being obtained from these devices. Storing clear text PHI on mobile storage devices is generally considered as being high risk.
• PHI in storage on a laptop or other mobile computer. You must determine where the mobile computer is used. Is it ALWAYS used within the secured facilities of your business? And with no P2P types of external connections? Then the risks are probably pretty low, and you may decide not to encrypt. However, as soon as you take that mobile computer outside of the facility walls, the risks skyrocket dramatically! Any time your computer changes locations, there are risks that it will be lost, stolen or forgotten. The mobility, and risks, along with HIPAA encryption requirements, should compel you to encrypt PHI stored on mobile computers that leave the building.
• PHI in storage on a fileserver in a secure facility. The risks involved rely completely on each individual circumstance! Who has access to the data? Through what applications, systems and networks? Others from outside the facility, such as business partners, vendors and outsourced entities? Can Internet website communications reach the fileserver? If the results of a risk analysis shows the risk is low, then you wouldn’t need to encrypt under HIPAA. However, even if the risk was low, but then a breach occurred, you would need to provide notification to all involved individuals under the HITECH Act.
• PHI stored in a mainframe where the data can only be accessed through applications, or physically at the mainframe facility. A risk analysis may very well show low risk for this type of PHI. In this case you may choose not to encrypt.

Bottom line is this..

The HITECH Act *DOES NOT REQUIRE ENCRYPTION! HOWEVER, IT REQUIRES NOTIFICATION IF BREACHED PHI IS NOT STRONGLY ENCRYPTED WITH SPECIFIED STANDARDS!

Excerpts from the HHS HITECH Act implementation guidance:

“i) Valid encryption processes for data at rest are consistent with NIST Special Publication 800-111, Guide to Storage Encryption Technologies for End User Devices.17 ii) Valid encryption processes for data in motion are those that comply with the requirements of Federal Information Processing Standards (FIPS) 140-2. These include, as appropriate, standards described in NIST Special Publications 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations; 800-77, Guide to IPsec VPNs; or 800-113, Guide to SSL VPNs, and may include others which are FIPS 140-2 validated.18″

HHS Encryption Guidance for HITECH Act compliance:

“This guidance is intended to describe the technologies and methodologies that can be used to render PHI unusable, unreadable, or indecipherable to unauthorized individuals. While covered entities and business associates are not required to follow the guidance, the specified technologies and methodologies, if used, create the functional equivalent of a safe harbor, and thus, result in covered entities and business associates not being required to provide the notification otherwise required by section 13402 in the event of a breach.”

“In consultation with information security experts at NIST, we have identified two methods for rendering PHI unusable, unreadable, or indecipherable to unauthorized individuals: encryption and destruction.”

“Encryption is one method of rendering electronic PHI unusable, unreadable, or indecipherable to unauthorized persons. The successful use of encryption depends upon two main features: the strength of the encryption algorithm and the security of the decryption key or process. The specification of encryption methods in this guidance includes the condition that the processes or keys that might enable decryption have not been breached.”

“Protected health information (PHI) is rendered unusable, unreadable, or indecipherable to unauthorized individuals only if one or more of the following applies: a) Electronic PHI has been encrypted as specified in the HIPAA Security Rule by “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”15 and such confidential process or key that might enable decryption has not been breached. Encryption processes identified below have been tested by the National Institute of Standards and Technology (NIST) and judged to meet this standard.16″

“i) Valid encryption processes for data at rest are consistent with NIST Special Publication 800-111, Guide to Storage Encryption Technologies for End User Devices.17 ii) Valid encryption processes for data in motion are those that comply with the requirements of Federal Information Processing Standards (FIPS) 140-2. These include, as appropriate, standards described in NIST Special Publications 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations; 800-77, Guide to IPsec VPNs; or 800-113, Guide to SSL VPNs, and may include others which are FIPS 140-2 validated.18″