When is Encryption Not Encryption? When it’s Not.

Don Miller

MFT Nation has written previously about whether the Health Insurance Portability and Accountability Act (“HIPAA”) requires the use of encryption. In that post, we noted that HIPAA requires use of data security measures, including encryption, whenever it’s “reasonable and appropriate” to do so, and suggested that very few situations exist where it would not be reasonable and appropriate to use encryption as a data security measure. The subject of this post is an FTC case in which regulators flesh out further details about reasonable and appropriate data security measures, including what level of encryption will suffice to pass muster with the FTC and under HIPAA.

FTC vs. Henry Schein Practice Solutions, Inc.

The FTC initiated a proceeding against a company that develops and sells dental practice management software alleging that the company made knowingly false statements that its software provides industry-standard encryption that meets the security requirements of HIPAA. The FTC offered the following compelling evidence showing that the company knew it was making false statements about the level of encryption in its software:

  • In 2010, the vendor who helped develop the software advised that it used a proprietary algorithm that had not been tested publicly and was less secure and more vulnerable than widely-used, industry-standard encryption algorithms, such as Advanced Encryption Standard (“AES”) encryption.
  • In addition, the company knew that regulators have recommended that healthcare providers follow guidance from the National Institute of Standards and Technology (“NIST”) to help them meet their regulatory obligations, and NIST guidance recommends AES encryption.
  • On June 10, 2013, the United States Computer Emergency Readiness Team (“US-CERT”) issued a Vulnerability Note describing the form of data protection used in the company’s software as a “weak obfuscation algorithm.”
  • On June 16, 2013, NIST published a corresponding vulnerability alert stating that the vendor had agreed to re-brand the data protection as “Data Camouflage” so it would not be confused with standard encryption algorithms, such as AES encryption.
  • Despite receiving notice of the US-CERT Vulnerability Note and the vendor’s decision to re-brand in June 2013, the company continued to disseminate marketing materials stating that its software “encrypts” patient data and offers “encryption.”

Lessons Learned

To secure data, whether you are storing it or transmitting it internally/externally, follow NIST’s guidance and ensure that you have the capability to encrypt the data using the Advanced Encryption Standard.

Although the FTC has targeted only a handful of data security cases involving an entity that is subject to HIPAA, the FTC appears to be applying tougher standards than HIPAA’s requirements (e.g., requiring a specific type of encryption than what HHS historically has interpreted HIPAA as requiring).

For the first time ever in a data security case, the consent order includes a financial payment of $250,000, and the FTC settlement does not preclude a HIPAA action by HHS or by one or more of the states. So perform periodic risk assessments of your data security infrastructure to ensure that there are no security/compliance holes.

If you want to learn more about HIPAA compliance, or need a solution that has NIST-recommended AES encryption, please contact us at info@btrade.com. If you want to keep updated on developments in the world of secure file transfer and data security, follow us on Twitter, Facebook, LinkedIn, Google+, and our blog MFT Nation.

bTrade Case Study