Wednesday, September 1, 2010

Meaningful Use Certification issue with Encryption of data-at-rest

The final Meaningful Use certification criteria includes one security criteria that has caused much discussion. This discussion is healthy, but it is not resolving to a single understanding and potentially putting Meaningful Use qualification at risk. Most of the security requirements are easy to understand and I have outlined them in Meaningful Use Security Capabilities for Engineers.

The troubling requirement is:
  • §170.302 (u) General encryption. Encrypt and decrypt electronic health information in accordance with the standard specified in §170.210(a)(1), unless the Secretary determines that the use of such algorithm would pose a significant security risk for Certified EHR Technology. 
This seems to be easy enough to understand, although it does include the troubling "unless" clause. I am not going to focus on the "unless" clause here, as I have already ranted enough on that. Although this "unless" clause could be the solution to the problem. That is that the Secretary could resolve this lack of understanding.

The problem is not the selection of encryption algorithms. That is handled nicely in  §170.210(a)(1). The result is a set of encryption algorithms that are well implemented and well understood. Although it should be noted that most encryption schemes start with a Digital Certificate, use asymmetric encryption to cover the key(s) that are used with symmetric encrypt the bulk data. This is included in FIPS 140-2 Annex A, but too often people focus purely on AES (a fine symmetric encryption algorithm).

The problem is trying to figure out what the meaning of "electronic health information" is. Does this mean ALL electronic health information? Does this mean only the extracts identified for Meaningful Use?  The comments in the pretext of the regulation are not all that helpful. They simply keep reminding us that the EHR "must be capable of performing encryption". Does this mean that however the vendor provides for encryption is good enough? I suspect, not.

The one comment that leads me away from the EHR servers and toward the extract is the inclusion of NIST Special Publications (SP) 800-111. The scope of NIST SP 800-111 is "end user devices". This tells me that their worry is the laptops, tablets, smart phones, USB-Memory Sticks, CD, and DVD. This helps to scope the definition of "electronic health information" to those instances where this electronic health information appears on an end user device.

The NIST defined test procedures are not much help. They seem to be applicable to just about anything, thus leaving it up to the vendor to define what 'test data' is. (see Test Procedure for §170.302 (u) General Encryption. I am not sure what real functionality is being delivered when the vendor gets to define what the test will test. It is actually right to not further refine a requirement in the test procedure, but I had hope. This test procedure, could certainly be used to test that an extract of electronic health information intended to be saved onto a inherently portable device is indeed encrypted.

This also aligns nicely with the experience learned from A Look into the HHS Posts Data Breach Notifications. There are simply a huge number of breaches that are associated with inherently portable end user device. Had the data on these devices been encrypted then the data would not have been exposed.  I am not a fan of simplifying the solution to this problem as simply encryption, as there are other ways to protect end user devices. More to the point there are new risks introduced by encryption that need to be considered. But I will leave that discussion inside of NIST SP 800-111 where it already is covered nicely.

Off-the-shelf transparent encryption

Encryption of data-at-rest should not be seen as an EHR problem. There are many levels of abstraction that software developers use to separate functionality. Where a functionality is needed by many different applications, this functionality is pushed down into a lower level where it can be re-used. For example, no EHR includes code to handle interacting with the keyboard hardware. The EHR uses the functionality of the operating system to provide a reasonable set of abstract methods of interacting with the human. The EHR might have special interpretations of some key-sequences, but those same key-sequences could be provided by many different types of input. If this wasn't done then there would be much more work to get an EHR to work on a tablet computer that has no physical keyboard but rather a virtual simile.

This abstraction is done for many subsystems including things like USB-Memory sticks. To the EHR these simply look like another file-systems. The Healthcare Provider or Healthcare Provider Organization could choose a USB-Memory stick that automatically encrypted the contents. Quick survey of Amazon shows 72 different USB-Memory sticks that encrypt (e.g. IronKey).  The EHR would be unable to know, without proprietary means, that the data was indeed encrypted. In fact this solution is already available and in use today.

Another example is an encrypting hard-drive. There are many solutions that will transparently encrypt a hard drive. Some are hardware based, some are built into the operating system, some are built into the database manager, and some are add-on packages. All are available as solutions today and many are used today.

The problem here is that by getting the EHR vendor involved we end up with less choice. This is because the EHR must choose ONE solution that they are going to certify with. It is unlikely that the EHR vendor is going to certify 72 times for 72 different off-the-shelf transparent encrypting USB-Memory sticks, and dozens more times with different off-the-shelf transparent encrypting software. Thus the Healthcare Provider is forced to use that ONE choice because the rules of Meaningful Use require that the Provider must be using the certified EHR functionality.

Far better to recognize that this general encryption capability is abstracted below the EHR, and that the operational environment can already make these choices today. At minimal allow the EHR Vendor to claim a 'class of solution' where it is understood that they certified with a representative instance of an off-the-shelf transparent encryption solution. Forcing less choice is not a good idea.

Portable Standards

I will assert that this leaves only the question of how an EHR produces an encrypted data-set that is not using off-the-shelf transparent means? One way is to use industry-standards, such as encrypted-ZIP. This is a well known ZIP format that supports encryption with password or digital certificates. This is however not an open-standard.

We need open-standards for encrypting blobs of data at-rest in a way that is fully interoperable. The bad news is that there are no good solutions today. If there were than IHE would have included this as an option in the XDM profile. However there is movement.

The DICOM specification now includes support for encrypted portable media. This is mostly documented in Annex D of Part 15. They solved the problem by indicating that the standards used for secure email (S/MIME) can be used to create an encrypted file that is a MIME multi-part. This results in a single object that looks just like a single e-mail containing everything. Thus they take their portable media definition for using e-mail, and say that the e-mail can be seen as a portable-encrypted-file. Their portable media definition uses ZIP to preserve file-system.

The method that DICOM specified for portable media could be integrated into IHE XDM profile. Where the existing XDM file-system, that already has a ZIP format, would be encapsulated in the MIME multi-part, and encrypted using S/MIME methods. The result is a portable-encrypted-file that can be manipulate in many ways. Its not just for e-mail.

This movement is slow because the Off-the-shelf Transparent Encryption fills the need so well.


  1. John, very good post. Where is the reference to NIST Special Publications (SP) 800-111?

  2. NIST Special Publications are all at

    Specifically 800-111 is at

  3. Hi John, great blog. Do you know if PGP encryption would be adequate to satisfy the HITECH requirements?
    Thanks, Jeff

  4. Jeff,

    The HITECH requirements are rather easy to meet. In fact they are easy to meet the requirements and NOT BE SECURE (write the password or key on a post-it attached to the portable device). But that is not your question.

    PGP is very similar to S/MIME. Both were developed at the same time to solve the same problem... how to secure e-mail between two people. They are both good solutions. I tend to prefer S/MIME because it is an official standard. This does not mean that it is better.

    Both can be used in their native way as part of e-mail communications, and both have been re-purposed to create data-at-rest containers.

    One should also note then that ZIP has an encrypted format that is just as good as these for data-at-rest.

    I am not a lawyer, and don't play one on TV... so I can't really answer your question in any official way.

  5. Hey John,
    Good post on encryption and the fact that many COTS products (outside the EHR) can support this requirement, and that choice and innovation should not be discouraged but rather encouraged. Some of us at Siemens feel similarly about another requirement, data integrity.

    Although the test for integrity (TE170.302.s – 1.02, 1.03, 1.04) is thorough and applicable broadly, it appears to impose an unnecessary burden when instead the software developer could simply demonstrate use of widely accepted secure communication methods such as HTTPS (using TLS or SSL), used for virtually all secure Internet transactions. And there are other popular secure communications methods that should be permissible as long as they meet the security requirements. This falls into your COTS categorization as described in your blog post.

    Instead of generating hash values and doing comparisons, wouldn't it be more appropriate for a software developer to demonstrate use of the appropriate integrity algorithm, instead of re-validating the algorithm that is used which has been validated already by a much broader community (including but not limited to healthcare)? For Internet Explorer or Firefox communication to various popular web applications supporting HTTPS, showing that correct encryption and hashing algorithm are used is pretty straightforward and makes a lot of sense. The developer shouldn't have to come up with their own methods of generating hash values when the COTS already performs it. Why the test scenario does not allow for this is unclear. Any thoughts?



  6. I see this

    "Certified EHR Technology must include the capability to encrypt and decrypt information regardless of the transmission method used."

    Which seems to suggest that even if the user were using SSL to communicate client server, the data must be capable of being encrypted before transported.

  7. I don't have a problem with the general idea, the problem is that it is not practical. There are many ways that PHI goes in or out of an EHR, ways that will NEVER use double-encryption. If this criteria is strictly followed it would require engineering and V&V to spend lots of time creating double-encryption that will never be used.

    So I would rather see all required capabilities be specific to a real use-case. This is my first point, to scope the requirement to those that are been seen by the Breach Notifications.

    Yet, even that scope has a different implementation detail that is the greater point. The idea of having at least one implementation of a capability is different than having 'the' capability.

  8. As I understand it, the ability to offer double encryption is so that a user can choose to implement a higher level of security if they so choose. So, some EHRs may choose not to offer this ability. But does that mean then that that EHR can not be fully certified?

  9. Graham, That EHR can't be certified. The rule requires that a EHR must show 'integrated' encryption for all data-sets. Regardless of if anyone uses that functionality. Regardless of if that functionality could be used at all.

  10. I'm just trying to understand the nitty gritty of this. So, if a browser client connects to a https web server based certified EHR, and wants to request a scanned image, it would use something Javascript to request the encrypted document, decrypt it and then display in the browser, and that would be compliant.

    But if a client on a LAN wanted to request the same scan, from eg. Sql server, it would presumably only need to use Sql server's SSL ability to request the un-encrypted document and that would also be compliant?

  11. Graham, It is not clear if your use-case is using double-encryption. HTTPS encludes encryption, so this is the network encryption. You would need to encrypt it one more time that is independent of the network encryption. It is clear you don't have double encryption on your LAN use-case.

    You might also be placing a reasonable constraint on the criteria, one where the user is involved in the transaction. What if they say that ADT is PHI and therefore must be encrypted independent of the network transport? Who would doublely encrypt ADT, who would even support network encryption beyond transparent VPN? What if they say that Lab Results must be encrypted independent of network transport? What lab would ever send you encrypted content?

    I am just looking for the criteria to be constrained to a realistic set of use-cases. I am further saying that these use-cases can be done today without needing the EHR to do anything special. Thus I am asking for the explicit risk that they think double encryption solves.

  12. I just came across this blog and I'm not sure if I understand the interpretation being presented here. We provide an online patient portal to the user. The patient's PHI data is encrypted at rest in our system and while in transit to-from the client (browser), it passes over SSL transport. Does the requirement for encryption mean that we must now encrypt the data again before its shunted onto the SSL pipe? That sounds like triple-encryption to me.

  13. Anonymous, The Meaningful Use criteria is indeed asking you to provide a functionality where you export the PHI into an encrypted form on the client. The workflow they are trying to support is where a data-set is exported out of the system in a way that it can be carried on a USB memory stick, CD-ROM, PDA, etc...

    So, in your case; yes this is triple encryption.

  14. I see, so the "third" encryption you're referring to is really having the PHI be in an encrypted form when the data is exported to say a file on a thumb drive. I'm really wondering how complex the whole scheme could get and would it still be interoperable in terms of ubiquitous accessibility. From the viewpoint of a patient who just wants an export of his CCD to his thumb drive so he could load it up on his tablet (say), it seems like he'll be jumping through a lot of hoops for it to be possible (private keys, CA certificates etc). Your thoughts on it?

  15. Anonymous, Yes you got it. My biggest concern is that the way the requirements are written it will drive many 'healthcare' product developers to invent encryption envelops and key management. Or worse to NOT do any encryption enveloping and NO key management. The way the requirements are written a product could get certified with a FIXED encryption key.

    For this encryption of data-at-rest in portable environments, see my section above on "Portable Encryption". Using S/MIME as a portable encryption container is really a good idea.

  16. John,

    This is the first article I have been able to find that actually makes some sort of suggestion.Thank you for that. Most of these security items have been quite a challenge to meet. Couple of questions for you.

    1.) You mention encrypting the data, but does it matter what format the data is in? (HL7?)

    2.) I initially understood general encryption as encrypting the database of the EHR, but it sounds like that isn't the target. It sounds like giving the user an option to encrypt specified data to a file would satisfy this requirement?

  17. Anonymous,

    1) The format is totally up to the EHR. It could be CCD, PDF, TXT, or any other form. Clearly I would recommend it be one of the document types you are otherwise showing, using the XDM container.

    2) You are correct. There has been clarifications given by ONC on this topic. They are not looking for EHR database or server encryption. They want an exported data-set to be encrypted. The most likely use-case is to put the data onto removeable media.

  18. This is a great article and discussion. Can you provide a reference for your previous comment?
    "There has been clarifications given by ONC on this topic. They are not looking for EHR database or server encryption. They want an exported data-set to be encrypted. The most likely use-case is to put the data onto removeable media."

  19. Anonymous,

    Unfortunately I can't share this... but go ahead and ask your certifying body... Hint, Hint...

  20. John,
    Article was great.
    On the reply to anonymous you mentioned about the clarification by ONC
    Can you provide a reference link for the clarification given by ONC on these topic

  21. Does TrueEncrypt provide adequate protection under hitech act?

    1. I can't make that assessment because I am not a lawyer. That is a product, it is best to check with that vendor. A product like this is indeed an example of how an operational environment(Hospital, clinic, etc) can protect themselves. Transparent and automatic hard-drive encryption is something that can be done without involving the EHR vendor.