Updated August 2014 -- This article seems to be popular for some reason, well beyond the usefulness it brought back in 2010. Please refer to the MU topic, or Secure Communications topic for fresh information.
The topic of encryption continues to be a hot one with the Meaningful Use certification.The criteria are mostly clear, but how they will be tested continues to be confusing. I have blogged on this before: Meaningful Use Security Capabilities for Engineers and Meaningful Use Certification issue with Encryption of data-at-rest. But these blog posts leave some more current details out. The good news is that from what I can tell they (ONC, NIST, and the certifying bodies) have gotten more reasonable.
The second item (c) is simply calling for SHA1 to be used to protect data from unauthorized modification.
Item (a) and (b) are referenced in the encryption items that are being tested. Where (c) is referenced less
§170.302 (u) General encryption...
From what I can tell (u) is being interpreted much as I have been posting before, use of portable encryption such as Secure ZIP or portable S/MIME file.
The NIST test procedure here is short. It does make clear that the EHR vendor identifies the "test data". We did receive clarification that this as NOT asking for the EHR database or backend servers to be encrypted. This might not be a bad solution, but it is one that needs to be carefully deployed as this could introduce new risks.
The test data is expected to be exported and encrypted all by the EHR being tested. From what I understand CCHIT is being more strict about this needing to be integrated, where the other certifying bodies might be allowing external capability.
§170.302 (v) Encryption when exchanging...
This item should be very simple. It should be a case where the EHR vendor simply says that they have TLS or VPN capability available for their customer to use on network interfaces. For example the interface for submitting prescriptions, lab requests, lab results, etc. This is what my read of the comments in the regulation. Unfortunately comments in the regulation don't mean anything.
I have heard that some certifying bodies might be simply asking for the network protocols used and doing simple verification. So the tester would ask the EHR vendor to explain the algorithms used. The vendor says that they have TLS with AES and SHA1. They demonstrate this with some network sniffer, like wireshark, showing the network traffic as looking like random noise.
The problem with this is that the NIST test Encryption when exchanging electronic health information don't completely agree with this reading of (v). The NIST test seems to be asking for the same functionality tested in (u). So I would be prepared to re-use the test you have for (u), and show that when this portable-encrypted-package is transmitted over TLS that the TLS also encrypts. Thus resulting in double encryption.
Conclusion
I don't know everything. I am struggling with everyone else. I would be glad if anyone who has had an experience was to comment on this blog. I think it is better if we all share experiences. This is not a good place to get secretive. The idea that the certifying bodies need to be so secretive is rather counter to an open process. I don't mind comments from anonymous, or you could have me summarize as anonymous information.
The topic of encryption continues to be a hot one with the Meaningful Use certification.The criteria are mostly clear, but how they will be tested continues to be confusing. I have blogged on this before: Meaningful Use Security Capabilities for Engineers and Meaningful Use Certification issue with Encryption of data-at-rest. But these blog posts leave some more current details out. The good news is that from what I can tell they (ONC, NIST, and the certifying bodies) have gotten more reasonable.
- §170.210 (a) - Encryption and decryption of electronic health information
- §170.210 (c) Verification that electronic health information has not been altered in transit
- §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.
- §170.302 (v) Encryption when exchanging electronic health information. Encrypt and decrypt electronic health information when exchanged in accordance with the standard specified in §170.210(a)(2).
The second item (c) is simply calling for SHA1 to be used to protect data from unauthorized modification.
Item (a) and (b) are referenced in the encryption items that are being tested. Where (c) is referenced less
§170.302 (u) General encryption...
From what I can tell (u) is being interpreted much as I have been posting before, use of portable encryption such as Secure ZIP or portable S/MIME file.
The NIST test procedure here is short. It does make clear that the EHR vendor identifies the "test data". We did receive clarification that this as NOT asking for the EHR database or backend servers to be encrypted. This might not be a bad solution, but it is one that needs to be carefully deployed as this could introduce new risks.
The test data is expected to be exported and encrypted all by the EHR being tested. From what I understand CCHIT is being more strict about this needing to be integrated, where the other certifying bodies might be allowing external capability.
§170.302 (v) Encryption when exchanging...
This item should be very simple. It should be a case where the EHR vendor simply says that they have TLS or VPN capability available for their customer to use on network interfaces. For example the interface for submitting prescriptions, lab requests, lab results, etc. This is what my read of the comments in the regulation. Unfortunately comments in the regulation don't mean anything.
I have heard that some certifying bodies might be simply asking for the network protocols used and doing simple verification. So the tester would ask the EHR vendor to explain the algorithms used. The vendor says that they have TLS with AES and SHA1. They demonstrate this with some network sniffer, like wireshark, showing the network traffic as looking like random noise.
The problem with this is that the NIST test Encryption when exchanging electronic health information don't completely agree with this reading of (v). The NIST test seems to be asking for the same functionality tested in (u). So I would be prepared to re-use the test you have for (u), and show that when this portable-encrypted-package is transmitted over TLS that the TLS also encrypts. Thus resulting in double encryption.
Conclusion
I don't know everything. I am struggling with everyone else. I would be glad if anyone who has had an experience was to comment on this blog. I think it is better if we all share experiences. This is not a good place to get secretive. The idea that the certifying bodies need to be so secretive is rather counter to an open process. I don't mind comments from anonymous, or you could have me summarize as anonymous information.
I concur with "anyone who has had an experience" (sharing is caring). There needs to be a lot more "feedback" from other entities that have already gone through the trenches.
ReplyDeleteASP Model(Web Based)
data in motion secured via SSL?
data at rest,"the capability", is where the double encryption comes into play. SecureZip is great but come with a cost, licensing. FYI, can anyone chime in on http://www.7-zip.org/7z.html [supports encryption with AES-256 algorithm], its FREE. Less the digital signature, it's comparable to securezip? Validating a Digital signature is a beastly undertaking when trying to educate Staff. I do like the use of HASH Keys, AKA Checksum(conceptually easier on my brain), as a substitute. Allow user to see corresponding HASH on site and then they can use something like http://www.febooti.com/products/filetweak/members/hash-and-crc/, also FREE, to validate.
...I appreciate your efforts with this BLOG, great stuff ~BOB
Hello John,
ReplyDeleteI work for a company that is preparing for "meaningful use" certification and we too are searching for solid answer on what the expectation is for 170.302 (u) and 170.302 (v).
We have a client/server web enabled application in which all health information is stored on the dataserver which is expected to reside on a secure network. What we are trying to determine is what data actually needs to be encrypted. To this point it appears that the data in the server does not need to be encrypted which leaves the transmission of the data from the server to the client which in most cases is html and is encypted by using HTTP and SSL, however, there is no mention of SSL encryption being one of the acceptable means of encryption.
Is this really just a matter of providing the end-user with a way of encrypting and decrypting eported data such as a report or speardsheet?
Has your organization passed certification as of yet? If so, in what scenarios were you expected to encrypt data?
Thanks,
Todd
Hi Todd, My understanding of the current testing is that they are just looking for encryption of exported 'data sets'. That they are not looking for server or database encryption.
ReplyDeleteThey are also testing for encryption of network communications. SSL is a transport standard that can use encryption and integrity controls that are specified. The Meaningful Use specifications did not define this higher level standard. I think they wanted to allow for SSL as well as VPN. I think this should eventually be specified or there will be a miss-match in interoperability capabilities. Hence why IHE did specify this in IHE ATNA profile.
John, thank you for blogging on this topic.
ReplyDeleteThe bottom line as I understand it from your blog is that:
1) The General Encryption test is NOT checking for the EHR database or backend servers to be encrypted... and,
2) The General Encryption IS checking for the test data to be exported and encrypted all by the EHR being tested
In case an ACTB (authorized testing and certification body) may be reading this blog, it would be great if they could provide the same guidance.
One of the most confusing aspect has been the Integrity requirement which seems to have been written only from the perspective of an EHR system. We're an online portal. Is it acceptable to show that Integrity requirements are satisfied by the use of SSL/TLS (which use message digests)? I can't think of any other way to demonstrate Integrity for an online application which allows uses to access their health data online.
ReplyDeleteDear Anonymous,
ReplyDeleteYou should be able to ask your test/certification vendor. They usually have some form of one-on-one feedback. I know this because I know answers to some questions that I can't share because the answer comes from the certifying vendor under this kind of one-on-one method. I think this is not very 'transparent', and you can likely see some of these answers hidden in my blog.
From what I know the integrity tests have only been around transport, and YES SSL/TLS is sufficient as long as you can explain that your TLS configuration does negotiate a hashing algorithm such as SHA1 (or higher).
John,
ReplyDeleteThanks for all the info above. It has been helpful to ensure we have the right structure in our services. We are currently implementing a field level encryption on some fields (passwords, and single field sensitive information). We are also using the same encrpytion (AES) to wrap our service messages (to a client app). The requests are also over SSL (2048bit SHA1). Does this give us our double encryption to meet the requirement?
We have much confusion around the requirements for what our client application requires, and what the export/sending of data to a 3rd party. Does the test actually require us to share the keys/certificates so the data can be decrypted and remain unmodified, or is it more for the check that the data is encrypted when intransit as well as external to the native application?
Anonymous, The requirement is for data-at-rest. It sounds like you have built a system for data-in-transit. TLS should be enough for transport.
ReplyDeleteWhat really confuses me is the integrity 170.302(s) case.
ReplyDeleteIf you read this document, it only confuses things worse.
ONC-ATCB 2011_2012 Guidance v4 Jan 2011
You would assume that since SSL uses SHA, this would be enough to handle it at the network layer, but from page 25:
"You will take test patient data that is electronic health information (for example: CCD or CCR file, or lab result data) and you will generate 2 hashes on that same original data. A hash value is a 40 character string of mixed numbers and letters. Since you are hashing the exact same data twice, the first two hash values you produce should exactly match. You will copy both of these values and paste them into a .txt document for the Tester to verify that they match. Next, you must modify the original test data in some way and then generate 1 more hash value. This hash value should be different than the first two because the data was changed. Copy this value and paste it into the same .txt document. The Tester will need to visually confirm that the first 2 hash values are identical and the 3rd hash value is different."
This is just retarded...
@ David W:It is indeed without purpose. In practical terms; The ability to produce a hash is pervasive - in all OS platforms-, and proving that you can hash a document holds no value, unless it is done for practical purposes.
ReplyDelete