Meaningful Use Stage 2 has made mostly minor adjustments to the security and privacy capabilities, but critical and welcome ones. They have added detail to the Security/Privacy Audit Logging, references to FIPS for cryptographic algorithms, synchronization of time clocks, clarified some old criteria, and defined a patient accessible accounting report. These are all things that have been recommended in many other environments including IHE, HL7, DICOM, HITSP, and previous EHR certifications. These are also aligned with guidance and requirements from other regional and national programs. Overall a system that has been designed well to handle security should be in good shape.
Detailed DiscussionI provide more details below. Here is the text from the NPRM of interest to Privacy and Security:
§ 170.210(g) Synchronized clocks:The most referenced inside of the NPRM, and the most important of these changes is the synchronization of time clocks. This has been called for by IHE since 2002. The only addition that ONC did was to specify that NTP v4 is also acceptable. I think this is more because they feel the need to point at the latest version. The only useful new thing in NTPv4 is support for IPv6. IPv6 is going to be critical, but is likely a decade off. The US federal government has been mandating it since 2003. IPv6 will likely show up first for mobile devices on cellular networks. Having support for NTPv4 and IPv6 is a good thing, eventually, but not too urgent.
The expectation is that the practicing organization will choose a single time source and configure all their systems to synchronize with that. This is often times transparently done in cases where Active Directory is used as the Microsoft technology automates this.
§ 170.210(e) Record actions related to electronic health information, audit log status, and encryption of end-user devicesThis section is simply adding some more detail to a few specific auditable events and what minimally should be recorded when these events happen. A well designed security audit log system would have captured these events anyway, as there is not new events or new detail. These events have been included since 2004 in IHE-Audit Trail and Node Authentication (ATNA) and the standards that it is based on.
Item (3) is the least useful and should be removed. The most likely scenario for encryption of data-at-rest is to use a totally transparent off-the-shelf solution. The EHR would not be involved in this and couldn't possibly know that encryption of data-at-rest is being used. I have written an extensive blog article on this: Encryption is like Penicillin.
More confusing is the way they are describing how security audit logging will be handled for EHR Modules vs EHR Complete. I simply can't quite figure it out. Seems to me that if a piece of code, modular or complete, is responsible for allowing a 'security auditable event' to happen, that it should be responsible for recording that it happened. This is the model defined in the IHE-ATNA profile, and through the SYSLOG standard that it uses for transport all of the events end up in one location, the Audit Record Repository. In this way many modules record events that are all able to be sorted, filtered, alerted on, and reported on. The result is a distributed system with a complete Accountability supporting Accounting of Disclosures.
The comments to ONC on this would be to remove (3). I get why they want it, but it is an event that will never be detected by an EHR. The underlying problem of mobile devices getting stolen is an operational problem that CMS has covered well through pointing at HIPAA Security rule.
§ 170.210(f) Encryption and hashing of electronic health informationThis item is here to clear up confusion caused by Meaningful Use Stage 1 which included specific algorithms. The goal of this new item is to indicate that Meaningful Use and Healthcare as an industry should simply look to NIST/FIPS for the algorithm endorsements. This is a good thing as it puts the decision in the hands of experts in cryptography, and opens up the number of algorithms to a more reasonable choice.
This should make it more easy to simply leverage off-the-shelf security. Typical network, object, and system encryption tools follow the recommendations of NIST/FIPS.
It is good to see that in the prolog (Page 32 in my copy) of the NPRM they explain that because the Transports defined include Security (Encryption, Integrity, and Mutual-Authentication), that it is unnecessary to further elaborate on transport security. This is good, but does put in question all the other non-specified transports. The IHE-ATNA profile handled this differently saying that once you include "Secure Node" or "Secure Application" that the system is obligated to include security for ALL network communications that carry PHI, regardless of if they are IHE compliant network communications or not. This is just the 'capability' to secure the communications, but it is a clear indication that any non-secured communication is a vector for attack.
They reinforce this with more comments on page 49 "…designing EHR technology to meet the following standards: IETF RFC 2246 (TLS 1.0) and SMTP/SMIME as well as implementation specifications such as NIST Special Publication 800-52 ("Guidelines for the Selection and Use of TLS Implementations") and specifications developed as part of nationwide health information network initiatives. ". This is also a reference to the Transport standards that I covered here.
What is still missing is guidance around Key Management. This is a major issue with Encryption and Digital Signatures, the keys must be managed very carefully. With bad key management comes bad security.
The comments to ONC are that this is a good job, please add comments that Key Management must also follow the recommendations found in FIPS 140-2.
§ 170.314(d) Privacy and security. I am not going speak to everything in here as most of it is clear.
I have a minor concerned with their § 170.314(d)(2) "Auditable events and tamper-resistance". At some point audit logs need to be purged. This is only done after they have been fully analyzed and all value (security and privacy surveillance) has been gotten out of them. But ultimately the audit log must be purged or it will become far larger than the EHR database it-self. My comment would be to recognize that there are times when authorized purging of the audit log is appropriate.
I have another minor concern with § 170.314(d)(6) "Emergency access". They define a term using the term it-self. What is an 'Emergency'? We have been developing an understanding of "Break-Glass", that is not the "Emergency Room", as the emergency room is a place where specific individuals are assigned to work and these people hold the functional role of emergency room doctor. So are they talking about a wide scale disaster like Katrina or Tōhoku. See some lessons learned from them. My comment for ONC is to remove this item. The concept of 'Emergency access' has not been clear since HIPAA, it needs some clarity before we can start requiring support for it.
I have lots to say about § 170.314(d)(7) "Encryption of data at rest", and have said it in my article Encryption is like Penicillin. What I have to say is very supportive of this item, then again I was very much engaged in the writing of this specific item.
§ 170.202(a)(1&2)(ii) Patient accessible log. This is the start of a real Privacy Access Report. It is clearly leveraging the audit logging, and is a well written description of the expectation for an Access Report. How this Report gets created is left to the creativity of the EHR designer. I could imaging it being only created upon demand, but that would require that the audit log be kept for a very long time. I could also imaging it being created on an annual basis, thus allowing the audit log to be purged.
They have included Privacy! They should be given kudos for this. Nothing earth shocking for any well done EHR or operational environment, but welcome guidance and encouragement for those that had not yet addressed Privacy. Their changes are directly to support HIPAA Privacy and HITECH. They have identified that security audit logging is an input to an Accounting of Disclosures, and a Access Log. They have defined what these reports would include. They have given stronger guidance on Amendments.