Covered entities and eligible providers must now address the issue of encryption of “data at rest” as part of their security risk 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 to encrypt and decrypt electronic protected health information.” However, since it is categorized as an “addressable control,” it is not specifically mandated.
Last week, Health and Human Services Secretary Kathleen Sebelius reported that the number of hospitals using electronic health records (EHR) has more than doubled in the last two years from 16 to 35 percent. She also said that 85 percent of all hospitals now report that by 2015 they intend to participate in The Centers for Medicare and Medicaid Services’ (CMS) EHR incentive program.
Also last week, CMS released the proposed Stage 2 Meaningful Use requirements for public comment. The draft rule gives eligible hospitals and providers a good indication of where to focus their efforts as they continue their implementation and adoption of electronic health records throughout their organizations. Stage 1 was mostly about transferring data to EHRs and being able to share information, including electronic copies and visit summaries for patients. Stage 2 moves the goalposts further down field, requiring that patients have online access to their health information and facilitation of electronic health information exchange between providers.
The Stage 2 core requirement for IT security uses nearly identical language from Stage 1 regarding updating or conducting a HIPAA security risk analysis. Both Stage 1 and Stage 2 rely on the HIPAA security rule provisions under federal code 45 CFR. HIPAA deems encryption an “addressable” specification, meaning a covered entity decides if it is a “reasonable and appropriate” technical security step to implement. The security rule enables an entity to adopt an alternative protective measure that achieves the same purpose.
But the difference between Stage 1 and Stage 2 on this issue is subtle but significant. Stage 1 only mentioned the security risk analysis provision. However, by specifically calling out out the issue of encryption at rest in Stage 2 , CMS has heightened the importance of analyzing the pros and cons of using the technology. The complete language of the core objective for both hospitals and eligible providers requires that they:
“Conduct or review a security risk analysis in according 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.”
As Redspin reported in our February 1st Breach Report 2011 – Protected Health Information:
“Of the 385 incidents affecting 500 or more individuals, 55% involved unencrypted devices or media. The Federal government is unlikely to mandate that all portable devices that store ePHI be encrypted, but it’s an obvious and sensible policy for a healthcare organization to adopt. Taking it further, why not require that all mobile devices in the healthcare workplace be encrypted, even if ePHI is not allowed on them.”
As we predicted, the government stopped short of a mandate. There is no movement afoot to change or add to the HIPAA security rule requirements. But in Stage 2 they emphasized that an EP or hospital should consider encrypting electronic protected health information as part of their security risk analysis, and where it is not “reasonable and appropriate,” adopt an equivalent alternative measure of securing data.
Sometimes, you have to read between the lines… or in this case, read between the forward slash. We’ll be talking about the phrase “addressing the encryption/security of data at rest” for the next few years.