Technology, HIPAA and You Part 2: NIST Tool

This is the second part of my series on HIPAA compliance tools, apps and hardware. This week I focus on the NIST HIPAA Toolkit.


Creators: The National Institute of Standards and Technology is a part of the US Department of Commerce. NIST’s stated mission is to “promote U.S. innovation and industrial competitiveness by advancing measurement science, standards, and technology in ways that enhance economic security and improve our quality of life.”  In other words, this is government funded research aimed towards producing useable products, papers, and technology for anyone to use. NIST also co-hosted a conference in 2014 with OCR to discuss HIPAA Security rule issues.

Look and Feel: This tool is as utilitarian as you would expect from something that was funded by the US Government. It does not have splashy graphics, complex reporting or some of the features you might see in traditional for profit applications. That said, what this program lacks in pretty, it makes up for in pure unadulterated HIPAA horsepower. Once you have created a survey, the dashboard serves as a step by step walkthrough survey of the HIPAA statute beginning with 45 CFR 164.308 through 45 CFR 316.  The program works on Mac, Linux and Microsoft platforms.

Under the Hood: All told, there are 809 survey questions in the enterprise version and 492 in the standard version. The primary difference being how in depth you want to get. I used the enterprise version for an umbrella company and the standard edition for the subsidiaries/sister companies.  Each question is geared towards asking, at least in theory, exactly what a HIPAA OCR auditor would ask your company in the unfortunate event you are being audited. For example:

“Has your organization defined the frequency of your Risk Assessment policy and procedures reviews and updates? “

NIST ScreenCap

As you can see, this question is paired with a very basic response of Yes, No, or Not Applicable. In addition, you can flag the question for importance on a color/number scale and make comments. Another very impressive feature of this tool is the ability to upload the documents/policies that support your answer to the question. The feel of survey is that an auditor would use something very similar to run a company through the ringer.

Use: As you work your way through the survey, you will, almost inevitably, find glaring holes in your documentation. That is ok, if you note the misses and keep going, you can run a report that allows you to draw out questions based upon level of completeness or flag level. Ultimately, you can run a report that would, in theory, demonstrate full documentary HIPAA compliance at the click of a button for Administrative, Technical and Physical Safeguards.

A couple other neat features worth pointing out, the survey itself is saved in a .xml format that can be accessed across networks. This means different offices, such as privacy office and security office, could work on the same survey in different locations by importing the .xml file back and forth.  The .xml format also means that the technically minded could manipulate and work with that file.

The primary drawback to this tool revolves around the document attachment feature. Once a document is attached, it must be deleted and re-attached anytime changes are made. This makes using this program as a living document very problematic. The company I am with chose to keep the documents outside of the tool, but reference which policy answered the question(s).

Another negative is that this tool does not address the privacy rule aspects of HIPAA. It is solely concerned with the Administrative, Technical and Physical Safeguards. This tool can appear very daunting and complex.  That said, a methodical approach to this tool will yield good work product.

Final Thoughts: In November of 2011, NIST quietly released this tool to aid organizations in working towards HIPAA Compliance. Surprisingly, I routinely meet practioners who have never heard of this tool. Even taking into account its age (four years old) and missing pieces, it is a surprisingly robust tool that will get almost any entity organized and on the path to compliance. Add to that the versatility of being able to generate a “HIPAA Compliance Report” is amazing and being able to hand this to the auditor as a first step would certainly frame the discussion in a positive way.

Now the website clearly states the tool is for informational purposes only and does not provide the user with HIPAA compliance. However, if I had a choice between a paid third party app and an app from the agency that co-hosted the HIPAA Security Conference with the auditing entity, I would probably pick the NIST tool.  As part of a broad based HIPAA compliance strategy, the NIST tool can be very helpful in tackling the Administrative, Technical and Physical Safeguards requirements.

/s/ HH @legalevity

HIPAA, Technology, and You Part 1: Encryption

Over the past eight months I worked to evaluate, demo and test out a wide array of apps, hardware, services and programs all designed to assist companies with HIPAA Compliance.  This post will be the first in a series evaluating these different tools and my experiences with them.

In light of the HIPAA breaches by Anthem (~80m) and Aspire Indiana(~45k), there has been a lot of discussion, information, and debate over what encryption is and who has to encrypt data. While nothing official has been published, layman reviews of the OCR data indicate that more than half of all HIPAA breaches are attributable to unencrypted data. To begin, this post will attempt to explain the basics of what encryption is in plain language, how it works and how it fails.  It is not meant to cover every corner of encryption practices, but rather provide essential understanding of what is a very complex topic.  It will then turn to the question at hand, what duty, if any, does a covered entity have to encrypt its data?

Basics of Encryption:

At its most basic level, think of a server as a house. The house contains all the data within its walls; the front door is the only proper entry to the house and the house key grants access to everything within.

Taken a step further, visualize the alternate entrances to a home: back door, windows and chimney.  Each of these other entrances serve as good examples of how a potential thief might target different ways into a home, thereby circumventing the front door and bypassing the need for a key. Sometimes these alternate entrances are wide open, subject to attack, or even available with keys unknown or uncontrolled by the homeowner. These alternate entrances are good metaphors for the security vulnerabilities of a server.  Every potential route into a server acts as a path to the data contained within.

With that understanding, there are two key terms to grasp: “in motion” and “at rest.” Data in motion is just that, data being sent from one point to another (e.g., e-mails, file downloads, and opening a client record remotely). Data at rest is, as its name implies, data that is sitting on a server.

Data in Motion:  Unencrypted data in motion is akin to a letter written in plain English, sealed in a paper envelope, and put in the mail.  If someone is able to intercept and open the envelope, they can read the contents without any further effort. The Jeb Bush email dump is a good example of unencrypted data containing names, address and social security numbers being available for anyone to find.  Encrypted data in motion uses the same mail carrier theory, but this time, the piece of paper within the envelope is written in code and completely illegible unless you have the right key to unscramble the letter.

Data at Rest:  Unencrypted data at rest means that once the mail enters the home, regardless of how it was sent, it is stored in clear and plain text. In this scenario, a thief only needs to gain access to the home to read anything contained within. A piece of mail sitting on the counter after being delivered is an good analogy. Data encrypted at rest means that each individual piece of mail is encrypted when it enters the house. Once you are in the house, all the contents of the house are present, but are scrambled and randomized. You might see a fragment of a couch or a picture, but nothing is recognizable or makes any sense unless you have a key to unscramble and assemble the couch and pictures.

Putting these pieces together, we end up with four different transmission/storage scenarios:

  1. Unencrypted in motion/unencrypted at rest
    • This is the most un-secure possible scenario. Here, the covered entity neither encrypts its own data in motion, nor requires the entities it works with to encrypt the data in motion.  The situation faced by Aspire Indiana indicates that the breach involved unencrypted data at rest. The stolen laptops all had unencrypted data with clear text of patient data.
  2. Unencrypted in motion/encrypted at rest
    • In this scenario, data is moved around and received unencrypted, but once it is in the house, it is encrypted.  This scenario presents what is perhaps a very common occurrence. Companies encrypt the data on their servers, but pay little or no attention to how data is transmitted or sent (i.e. e-mail, listserv, etc.)
  3. Encrypted in motion/unencrypted at rest
    • This is similar to the Anthem situation where a company encrypts its data in motion, but once it enters the house, the data is unencrypted and requires no further key to unscramble and read.
  4. Encrypted in motion/encrypted at rest
    • This presents the most secure scenario. Every piece of data is not only encrypted when in motion, but also when at rest within the house. This means that a thief would need to not only break through the house’s defenses, but through the individual defenses of the data to yield usable information.

There are a variety of pros and cons to each approach, but at a bare minimum, encryption of PHI data in motion is something that every company should do. Scenario’s 1 and 2, should never occur.  Otherwise, every time PHI is in motion it is completely unprotected and out in the wilds where anyone could capture and read it. The horror stories of hackers sitting by the door to your house reading everything that comes in and goes out is real, it’s called packet sniffing.

Scenario 3 – Encrypted in motion/unencrypted at rest

The real issue here, as evidenced by Anthem’s choice to not encrypt its data, is whether to encrypt data at rest. This scenario is the process implemented by Anthem.  All of its data in motion was encrypted, but as soon as it passed through front door, it was decrypted and put into its appropriate place. The touted benefit of this approach is that the data within the home is very easy to work with, manipulate and leverage into applications.  The downside of this approach is evidenced by the breach on February 5, 2015.  Once hackers were able to gain access to Anthem’s house, they had free reign and access to everything inside.

Scenario 4 – Encrypted in motion/encrypted at rest

When a company chooses to implement this security plan, it means that a piece of data is never unencrypted. In the house and out of the house, the data is encrypted and requires a key to unscramble.  For example, when Dr. Jones needs to view Bob Smith’s record, the doctor types in Bob’s name and searches for him in his office’s EHR. The server receives the request, and with its key, finds the appropriate data. The data then passes out of the house, retaining its encryption, and remains encrypted until it displays on the doctor’s computer. After any changes are made, the process reverses with the encrypted data going back to the house for safekeeping. While an argument can be made that unencrypted data is easier to work with, these companies are not keeping records for a lemonade stand. This is PHI, perhaps some of the most private and important information about a person.  The difference between working with encrypted and unencrypted PHI is fractions of a nanosecond for today’s computers.

How Encryption Fails

Sadly, no encryption program is perfect, although many come close. The complexity of those systems, coupled with the nature of humans often leads to inadvertent gaps, holes or forgotten maintenance access doors. Those tasked with system design and maintenance can also simply forget, refuse, or for various business and technical reasons, be unable to update the server’s defenses to protect against new threats.  Many times, hackers will utilize known security vulnerabilities to invade a server. While the numbers are not completely clear, several industry analysts believe that more than half of all server breaches are due to un-patched server software. While the excuses and reasons not to update are common, if you have an unpatched server, it needs to be fixed, isolated or transitioned out. Simply leaving it as is, is a recipe for disaster.

Duty of a Covered Entity to Encrypt

Encryption and decryption are addressed primarily under HIPAA in 45 CFR 164.312; Access Controls and Transmission Security. As a quick HIPAA primer, there are two types of safeguard specifications within the statute; those that are required and those that are addressable.  A covered entity must implement policies and procedures that meet what a specification requires. When a specification is addressable, it does not mean optional, but rather requires the entity to analyze the specification. Here is what OCR says about addressable safeguards:

“If an implementation specification is addressable, then the covered entity must assess whether it is a reasonable and appropriate safeguard in the entity’s environment. This involves analyzing the specification in reference to the likelihood of protecting the entity’s EPHI from reasonably anticipated threats and hazards. If the covered entity chooses not to implement an addressable specification based on its assessment, it must document the reason and, if reasonable and appropriate, implement an equivalent alternative measure.”

With this in mind, Anthem may have determined that it did not need to encrypt its data at rest, but solely while it was in motion.  Assuming it has the proper documentation in place and can justify the decision, it is possible they are not in violation of this HIPAA safeguard. However, in 2009 Anthem had over 1 million individual records stolen by hackers from hard drives that were unencrypted. You read that right, Anthem had a breach 6 years ago where unencrypted data was hacked and stolen.  It’s going to take an amazing amount of legal gymnastics to demonstrate why encrypting its data was not reasonable and appropriate in light of the 2009 breach.


Anthem did not have a specific requirement under the law to  encrypt its data at rest. That said, it did have a duty to implement an encryption and decryption plan that would address reasonably anticipated threats and hazards. So the question becomes whether Anthem could have reasonably anticipated its unencrypted data being hacked.  After the 2009 breach, Anthem issued the following statement:

“This was an isolated occurrence,” said Cindy Wakefield, spokesperson on behalf of Anthem, in a written statement to Healthcare IT News. “Appropriate corrective actions have been implemented, and process improvements for posting provider data online have been reviewed with the team.”

That statement was apparently premature and incorrect. A short six years later, Anthem’s unencrypted data was yet again hacked and stolen.  The decision to encrypt or not encrypt in this day and age is rapidly becoming moot. The difficulty in working with encrypted data does not exist on a level that justifies maintaining client records in clear text (i.e. unencrypted) once they are in the house.  In the next round of HIPAA statute amendments, it would not be a surprise to see a requirement that all PHI data must be encrypted in motion and at rest.

If you find yourself in a position where you do not know what scenario your company fits into, or you know you have unencrypted data moving or resting, reach out to your CIO and hammer out a game plan. HIPAA compliance crosses departmental boundaries and may involve at a minimum: legal, HR, and IT.  Get the right people to the table now and avoid pushing this topic under the rug.

/s/ HH @legallevity