HEALTHCON Regional 2022 | Stay Current. Stay Engaged. | Join today!

Unlocking the HIPAA Security Rule’s Stance on Encryption

  • By
  • In Compliance
  • January 28, 2020
  • Comments Off on Unlocking the HIPAA Security Rule’s Stance on Encryption
Unlocking the HIPAA Security Rule’s Stance on Encryption

In an age where digital information is constantly under threat, taking every step possible to protect that information would seem to be paramount for any institution. Which is why you may be surprised to learn that one tool used to protect digital information — encryption — is not a mandatory component of the Health Insurance Portability and Accountability Act (HIPAA) Security Rule.
In fact, a closer look at the recent resolution agreement between the Office for Civil Rights (OCR) and the University of Rochester Medical Center (URMC) suggests that encryption may not always be a reasonable or an appropriate safeguard for every covered entity.

What is Encryption?

The Health and Human Services (HHS) document “Security Standards: Technical Safeguards” defines encryption as “a method of converting an original message of regular text into encoded text … by means of an algorithm (i.e., type of procedure or formula).”
The document goes on to explain that the purpose of encryption is to ensure “a low probability that anyone other than the receiving party who has the key to the code or access to another confidential process would be able to decrypt (i.e., translate) the text and convert it into plain, comprehensible text.”
From this, you’d think that HHS would regard encryption as ideal for protecting patients’ electronic protected health information (ePHI), right?
Not necessarily.
HHS does regard encryption as one of the four implementation specifications associated with access control standards, which “provide users with rights and/or privileges to access and perform functions using information systems, applications, programs, or files.” But of the four specifications, only two — unique user identification and an emergency access procedure — are required. The two others — encryption and decryption, along with an automatic logoff — are regarded as “an addressable implementation specification.”
By addressable, HHS means that it only needs to be implemented if “after a risk assessment, the entity has determined that the specification is a reasonable and appropriate safeguard in its risk management of the confidentiality, integrity and availability of e-PHI.” This means a covered entity must first analyze whether the specification will be effective in helping them protect ePHI “from reasonably anticipated threats and hazards.”
If the entity decides the specification will not do so in a reasonable and appropriate way, the entity must then “document the reason and, if reasonable and appropriate, implement an equivalent alternative measure,” according to the HHS document “Security 101 for Covered Entities.”

What Happens When Equipment Goes Unprotected?

Clearly, an institution has to do something to safeguard the computers, phones, or other technology that it uses to store and transmit ePHI. If it doesn’t, not only is it leaving itself open to cyber attacks and information theft, but it could also find itself on the receiving end of a pretty hefty fine and a corrective action plan (CAP).
Just ask URMC — one of New York’s largest health systems — who were assessed a $3 million resolution and made to enter into a CAP with the OCR in November 2019, after an unencrypted laptop containing the ePHI of 43 patients was stolen in 2017, according to the HHS press release that announced details of the settlement.
This led to an OCR investigation, which found URMC failed to:

  • “conduct an enterprise-wide risk analysis;
  • “implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level;
  • “utilize device and media controls;
  • “and employ a mechanism to encrypt and decrypt electronic protected health information (ePHI) when it was reasonable and appropriate to do so.”

HHS clearly believed that implementing encryption was “reasonable and appropriate” in URMC’s case. But the problem lay not in URMC’s failure to adopt the technology but in their failure to (a) conduct an accurate and thorough risk analysis; (b) document the reason why encryption is not a reasonable and appropriate protection for URMC patients’ ePHI; and (c) implement a measure that will provide an equivalent level of effective protection to that offered by encryption.

To Implement, or not to Implement, Encryption

Simply put, HHS believes encryption is not a one-size-fits-all solution to the question of how best to protect patients’ ePHI. According to the Security Standards: Technical Safeguards document, “covered entities use open networks such as the Internet and e-mail systems differently,” and “currently, no single interoperable encryption solution for communicating over open networks exists.”
Additionally, HHS believes that imposing “a single industry-wide encryption standard in the Security Rule would likely have placed too high a financial and technical burden on many covered entities.” For now, HHS believes in allowing “covered entities the flexibility to determine when, with whom, and what method of encryption to use,” if indeed the entity decides to use encryption at all.
Whether adopting encryption will prove to be a reasonable and appropriate solution for URMC’s HIPAA woes, or whether they will even implement “an equivalent alternative measure” remains to be seen. In the meantime, many of us will be watching URMC’s next move with great interest.

Bruce Pegg
Latest posts by Bruce Pegg (see all)

Comments are closed.