Even for the numbers averse, these statistics are as easy and simple to read as the top line of an eye chart: Roughly 56 percent of all breaches reported on the Health and Human Services (HHS) Web listing of data breaches are exactly 100-percent avoidable.

In more than half of the current listing of 682 breaches the reported cause was lost, stolen or improperly disposed of unencrypted computing devices. In case after case, personal health information (PHI) simply walked out the door, to be used and viewed by anyone, resulting in immense cost, harm of reputation and loss of trust.

What may be more staggering than the number, however, is that each breach, as a result of a lost or stolen device, is preventable. Here, an easy-to-identify problem has an easy-to-identify answer.

While preventing theft, loss or misuse of computing devices may be no more solvable in the long term than any other type of workplace theft, healthcare providers can be compliant with HIPAA standards and avoid an appearance on the HHS site, with a relatively easy, cost-effective, preventative measure.


With encryption, even when a device is stolen, PHI remains secure and no breach is required to be reported.

Explaining Encryption

Encryption is a method of converting an original message (data) of clear text into an encoded message of ciphertext—text altered according to an algorithm and incomprehensible to a reader without the correct inverse function to decipher it. In a very basic example, think of an algorithm that increases the value of each letter in a word by one character. So, the word c-a-t-, when encrypted, would render as DBT. Now imagine an algorithm that operates with the full range of numbers, letters and symbols and uses an exponentially more complex mathematical formula to obfuscate data. Think of the cryptograms you completed in the newspapers as a child, now imagine they were created by Deep Blue and not beholden to any dictionary or rules of language.

The resulting ciphertext is not comprehensible to a reader, and, as such, prevents understanding of what the data represents. As a result, a lost or stolen device containing PHI that has been encrypted is not considered a data breach since the holder of that information cannot see the original data. 

Converting back from ciphertext to cleartext is called decryption. Typically an inverse mathematical function is used to perform that process. Without knowing the algorithm involved, this process can be considered computationally infeasible—meaning it would take very specialized tools and specialized knowledge to return the encrypted data back to its original form, an extreme edge case in a landscape dominated by garden variety theft. While secure electronic transmissions are needed when passing electronic records between healthcare organizations, the breaches reported to HHS are on lost or stolen records stored on devices, and represent data at rest. Having PHI locally encrypted would suffice to meet the definition of ‘protected’ data. 

More specifically, according to HHS guidance, encrypted data meets the standard of "unusable, unreadable or indecipherable to unauthorized individuals," and, therefore, does not require a company to report a breach if the device containing PHI is lost or stolen. Encrypted data also does not represent a substantial threat to patient privacy due to the infeasibility of cracking the algorithm.

There are, of course, some common sense points that accompany this rule (Don't store the encryption key on the same device as encrypted data, HHS warns—the digital version of not attaching a sticky note with your password to your computer monitor), but encryption is a simple solution to a widespread problem.

So what gets in the way of deployment?


Generally, licensed software performs the encryption/decryption process. Typically, each end device that stores electronic records requires a license. If deployed to the entire enterprise, cost could become a significant factor.  

Yet, ways exist to mitigate cost, as well, particularly using open-source encryption, and, more importantly, smartly deploying encryption only to devices on which electronic records are stored.

Open-source software offers leading-edge capabilities at a low cost, often free. Examples of open-source encryption software include True Crypt and AES Crypt. Using open source can avoid the acquisition cost of encryption, but be aware that open source doesn't mean entirely without cost. These products still need to be configured and managed, so total operational costs are not zero. 

Another cost-saving consideration is to use encryption only where PHI is actually stored.

If supporting electronic record applications are configured only to store PHI on enterprise servers, then only those servers need to be configured with the encryption/decryption software. Any mobile devices that would process electronic medical records would also need to be configured. This approach limits the use of encryption only to those devices with an explicit need, providing an optimum mix of risk management and financial soundness.


Will the encryption software noticeably slow down response times for software applications using encrypted electronic records?

Algorithms must be executed each time data is being encrypted or decrypted, so the short answer is yes, but likely very minimally, particularly weighed against the inconvenience of a breach.

Numerous steps can be taken to minimize impact. For starters, run encryption on startup and shutdown, where PHI is unencrypted upon device start up and decrypted when it is shut down. This puts the encryption/decryption process outside normal operations, and reduces any potential performance impact to end users. 

Further, given the performance of current hardware platforms, sufficient CPU horsepower is typically available to allow multi-threading, parallelization or other performance-enhancing techniques. Many products offer "on-the-fly" capabilities explicitly designed for a user environment where files are being read and written on an ongoing basis over the course of a day. The data is decrypted prior to reading and encrypted once used. The user is not even aware of this process occurring. With sufficient hardware computing platforms, this class of software can ensure all transactions involving PHI are encrypted yet still speedy. 

Enterprise Deployment

Managing encryption over a large enterprise can seem like a daunting task, from configuration management to ongoing updates.

It doesn't have to be taxing on the organization, however. Large security vendors, such as Symantec and McAfee, offer integrated packages that manage both the secure storage of PHI, as well as the secure transfer. For small- and mid-size organizations using electronic records, this can be a strategic growth path. Initial efforts to lock down all endpoint devices can be extended across the entire enterprise as the organizations mature and grow in size. Ongoing conversions of paper records to digital records can be encrypted at the point of conversion.  Encryption is a scalable technology that can be used to maintain security controls of all PHI over time.

Meanwhile, employing encryption immediately can avoid the most common cause of breaches reported to HHS and the concomitant mix of cost, bad publicity and loss of trust each breach brings.

Given the importance of securing each and every instance of PHI to avoid a reportable data breach, it is critical that a policy, such as mandatory encryption of all computing and mobile devices which host PHI, be enacted.

Once installed and enabled, an end user should not notice any performance impacts and can be assured patient data is properly protected when locally stored.  

For organizations of any size, as the HHS "Wall of Shame" makes abundantly clear, the problem is high-definition clear. Fortunately, so too is the solution.