Security and Proposed Meaningful Use Stage 2
Those in the healthcare industry may have heard that Office of the National Coordinator for Health IT and CMS have released the Meaningful Use Stage 2 Notice of Proposed Rulemaking at the HIMSS12 conference. In traditional government committee fashion, the proposal is 455 pages. I recommend leaving the in-depth reading and detailed analysis to the lawyers and your Meaningful Use project leader!
The full proposal can be found here: Meaningful Use Stage 2 Notice of Proposed Rulemaking
For the purpose of our audience, this blog post will focus only on the security aspects and how they have changed from Stage 1 to Stage 2. In Meaningful Use Stage 1, healthcare information security is really only addressed in one requirement. Pondurance has worked with clients to establish compliance with this requirement in their Meaningful Use Stage 1 submission.
The primary goal of security in the Meaningful Use requirement of HITECH/ARRA funding process is to “protect electronic health information created or maintained by the certified EHR technology through the implementation of appropriate technical capabilities”.
Meaningful Use Stage 1
Conduct or review a security risk analysis per 45 CFR 164.308 (a)(1) and implement security updates as necessary and correct identified security deficiencies as part of its risk management process
One path for achieving compliance with this measure is to perform a HIPAA security assessment, execute a risk analysis, and develop a plan for remediation of high risk issues.
Meaningful Use Stage 2 (page 82 of the proposal)
Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1), including addressing the encryption/security of data at rest in accordance with requirements under 45 CFR 164.312 (a)(2)(iv) and 45 CFR 164.306(d)(3), and implement security updates as necessary and correct identified security deficiencies as part of the provider’s risk management process.
This proposed measure in Stage 2 is nearly the same as in Stage 1 except that encryption/security of data that is stored in the Certified EHR Technology (data at rest) is called out. The fundamental reason for this is the increasing number of breaches reported to HHS involving lost or stolen devices.
Perhaps the most interesting aspect of this proposed measure is that it really isn’t a new requirement. It is a focused emphasis of the already existing HIPAA addressable requirement for encryption. Because ONC and CMS have not recommended changing the existing HIPAA Security requirements to make encryption of ePHI necessary, I think this is their way to move the needle on new technology implementations in healthcare IT. I expect that this change indicates it will be one of the Stage 2 submission review focus points. If your Certified EHR doesn’t support encryption, work with your vendor to see when this is available in their future product roadmap. If it isn’t there soon or if they don’t even want to talk about it, it’s time to start looking at new vendors. If they offer encryption, but you haven’t implemented it, either ensure your risk assessment formally documents why and what your compensating controls are or get your multi-disciplinary project team engaged now.
In terms of encryption, your ePHI data flow mapping should be able to document the location of ePHI as it is stored, accessed and transmitted. Ensure you encrypt:
- ePHI in the application database and associated log files (storage)
- any temporary or local storage at the client and don’t forget mobile platforms such as laptops and tablets (access)
- between the client and the application using techniques such as SSL, VPN, or IPsec (transmission)
As a healthcare IT consumer, I am happy to see the renewed focus on encrypting health information and medical data in the proposed changes for Meaningful Use Stage 2.
Steve Lodin is a consultant with Pondurance and has been a CISSP since 1998.