Can the HIPAA Security Rule learn something from the HIPAA Privacy Rule?  When it comes to encryption at the application security level: yes.

First, one of my particular soapboxes: in a world where medical records are increasingly found in digital form, the HIPAA Security Rule and the HIPAA Privacy rule cannot be minded by two different parts of the organization.  There must at least be tremendous and constant cooperation between the Security Officer and Privacy Officer at a Covered Entity or a Business Associate.

So how can the Privacy Rule inform application and database design?  Consider that a large concentration of electronic protected health information at this point is in application databases.  These databases are either housed in the Data Centers of the largest health care programs or at the hosting facilities used for running electronic medical record systems remotely.  In the latter case, the data represent an aggregate of many health care providers’ patient records.

To give credit where credit is due, this would not come as a surprise to the folks that put together the HIPAA Security Rule.  If you look at the discussion in the Federal Register for the Rule, you find the following comment from late 2000:

“The same technological advances that make possible enormous administrative cost savings for the industry as a whole have also made it possible to breach the security and privacy of health information on a scale that was previously inconceivable.”

Federal Register/ Vol. 65, No. 250 / Thursday, December 28, 2000 / Rules and Regulations p. 82474

And yet, yes, encryption of these records is still “addressable” as a standard in HIPAA as opposed to being “required”.  But the pushback on that is growing, and rightly so.  Consider what Deven McGraw, the co-chair of the Security and Privacy Tiger Team that’s advising the Office of the National Coordinator for Health Information Technology (a mouthful of a name, but a group that has put out some very meaningful  work) told Howard Anderson in an interview.  When asked why her team did *not* recommend requiring encryption for all sensitive data at rest and in motion she replied:

“The reason why we took the approach of just underscoring what HIPAA already requires, rather than suggesting or recommending that it go further and absolutely require encryption, is that we were advised by some of the members of the tiger team who actually do work on security within covered entities … that while encryption is an important tool, there are circumstances under which if you use it, it creates some downsides with respect to data access and data flows that … would be unacceptable. … So I don’t think we would have gotten to consensus on a requirement that encryption of data at rest is required in all circumstances.

Now having said that, I do personally think that the healthcare industry is a little bit behind where other sectors are with respect to robust use of encryption to protect data, and we really do need to be pushing a little bit further here in circumstances where there is a clear case for encryption and not really any good viable reason why it wouldn’t be used. Mobile devices, for example, is one area where at least we at Center for Democracy & Technology have called for an encryption mandate. I think when the law is clear on those issues, you get some more consistent implementation across the board.”

(http://www.inforisktoday.com/deven-mcgraw-on-tiger-team-priorities-a-3588/op-1)

Ok.  Let’s accept that there “are some downsides”.  But if your infrastructure is truly large and you’re in the business of creating or hosting the applications that house hundreds of thousands if not millions of patient records, encryption of data at rest is coming to be expected.  I believe it is a matter of when not if.   How can this encryption be done while mitigating some of the real and imagined obstacles, the “downsides”, to encryption?  Here’s where the Privacy Rule might help out.

There are two ways to meaningfully protect patient records and avoid classifying a loss of data as a breach under HIPAA:

1.    The data are encrypted to a high enough standard
2.    The data are de-identified

The specifications for de-identifying data are from the Privacy Rule.  If we combine them with encryption, we can mitigate most of the obstacles to encryption.

Note: on the one hand, what follows is not theoretical.  With the help of some very talented DBA’s and Data Analysts, I have implemented this in a large production database, albeit one used for analytics.  On the other hand, I cannot warrant that this approach would constitute “safe harbor” from breach notification requirements under HIPAA.   Only the regulators can provide that clarification.

Here’s the ten thousand feet view:  encrypt all the elements that would de-identify  the data and leave all the others in plain text within the operational database used by the application.  Give the application the ability to decrypt the data on the fly.  In addition, store a plain text surrogate index number (in database terms, a “foreign key”).  This number can link the operational database to another database that stores the identifying elements in plain text but is NOT stored in the same place.

Before I outline how this can eliminate obstacles to encryption, let me provide the picture that is worth the 1,000 words:

Here’s a discussion of the obstacles and what I would argue are the opportunities to the design:

BIGGEST OBSTACLE: Encryption creates performance issues. By limiting the number of data elements encrypted to only those that would identify the record, this solution limits the amount of work the application has to do to encrypt and decrypt the data. In addition, since the identifying data elements tend to be short (date of birth, last name, city, state, zip code, etc.), the actual number of characters that need to be encrypted is limited.  Finally, since the application does not need to display all these elements on every screen nor does it tend to write them very often (one’s date of birth does not change except in the rare case that it needs correcting), the application should not work too hard.  Finally, whenever “performance issues” are claimed as an obstacle to encryption, any kind of encryption, ask to see the analysis that’s based on.  If the analysis is based on stress testing the application at 10 times the volume that’s normal for a large implementation, perhaps it’s not that big an obstacle.

SECOND BIGGEST OBSTACLE: What if the keys become corrupt? Because the database is designed with a plain text copy of all the data, you could easily restore the data in the event that a key becomes corrupt. And if you are backing up the plain text database (again, not in physical proximity to the encrypted database or the backup of that database), then you can even recover from a situation where the plain text fields become corrupted by a corrupt key.  The beauty of the scheme is that while you can restore from the plain text, if the plain text table that store the patient identifiers is breached, you may have breached confidential patient information (social security numbers, birth dates) but since the medical record is in a different database, you have not breached electronic protected health information.

THIRD BIGGEST OBSTACLE: Key management is tricky and this scheme makes it trickier.  I cannot argue with that.  But the question is: how much higher do HIPAA fines have to go before it’s worth it to invest in and develop appropriate tools and staff for this task?

BIGGEST “BUT”: Isn’t full disk encryption easier? Yes. And there is nothing wrong with full disk encryption. But that usually is not something packaged with an application.  I would argue that full disk encryption is very useful for personal devices.  The data are deciphered off the disk on your network through what is usually single factor authentication (that should be strengthened to two factor no matter what else you do to secure the data).  Some mobile media/laptop encryption products at this point will even tie to Active Directory so anyone with a “Windows” account on your domain can access the drive.   When we’re talking thousands of records in an application’s primary data store, I think we should look for something more layered.

SECOND BIGGEST “BUT”: Why not encrypt the entire database? This is like full disk encryption. Is it really offering you the benefit of encryption when one ID and password unlocks everything and that password is used for various kinds of administration? In this scheme, it is easier to keep the key away from more system administrators without impacting their ability to do their jobs.  And anyone who thinks system administrators never breach data has not been reading the papers lately.

To sum up: full disk or full database encryption is not bad.  If the database is turned off and the physical media are stolen, it is exceptionally good and that is why it is appropriate for laptops and mobile media.   But if we are talking about data stored in a Data Center in large application databases, the risks are as great if not greater that someone on your network will try to access the database without stealing the physical drives.   And designing a scheme by which the plain text identifiers are removed from the sensitive medical information might reduce the risks significantly.