Stage 2 Meaningful Use: The Next Step in Security Risk Analysis


Published on

A brief overview of changes in stage 2 meaningful use.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Stage 2 Meaningful Use: The Next Step in Security Risk Analysis

  1. 1. Stage 2 Meaningful Use: The Next Step in Security Risk AnalysisAt first read, the security risk analysis (SRA) provisions of the proposed Stage 2 “meaningful use” regulations appear tohave changed only slightly from those in Stage 1. The language in the draft rule is nearly identical to Stage 1, with onenotable addition highlighted below:“Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1),includingaddressing the encryption/security of data at rest in accordance with requirements under 45 CFR 164.312(a)(2)(iv) and 45CFR 164.306(d)(3), and implement security updates as necessary and correct identified security deficiencies as part ofthe provider’s risk management process.Covered entities and eligible providers must now address the issue of encryption of “data at rest” as part of their securityrisk analysis process. This shines a spotlight on the existing encryption references within the HIPAA Security Rule.Encryption of ePHI is specifically covered under 45 CFR 164.312(a)(2)(iv) which reads; “Implement a mechanism toencrypt and decrypt electronic protected health information.” However, since it is categorized as an “addressable control,”it is not specifically mandated.As part of Stage 2 Meaningful Use, encryption of “data at rest” must be considered as an addressable control. Assuch, providers need a process by which they evaluate whether the control is “reasonable and appropriate” and wouldlikely contribute to protecting its health information. If the control is deemed “reasonable and appropriate,” thenit must be implemented. However, if the provider decides “encryption of data at rest” is not reasonable and appropriate,then it must 1) document why it is not reasonable and appropriate, and 2) Implement an equivalent alternative measure ifreasonable and appropriate. Despite a little remaining wiggle room, it has become increasingly difficult to justify notencrypting ePHI under the “reasonable and appropriate” caveat.Turning to the new rules for EHR software certification, Stage 2 also requires the main software application ‘to be able todemonstrate the capacity to encrypt [data on] mobile devices in circumstances where the EHR technology manages thedata flow on the mobile device,” In our view, these provisions stop just short of a mandate. Determining reasonableness isnot just about the cost of hardware and software or the complexity of implementation. It is more about whether or not theorganization can execute the requirement consistently and effectively.Given that the majority of significant breaches to date have been the result of lost or stolen devices containingunencrypted data, and the increasing mobility of data itself, it will be difficult to find “equivalent alternative measures.” Thatsaid, Redspin can provide a framework for considering the issue within our overall SRA roadmap and expert guidance onhow to reasonably and effectively protect patient information. WEB PHONE EMAIL WWW.REDSPIN.COM 800-721-9177 INFO@REDSPIN.COM