One thing interesting about our work as an information assurance provider is how external contexts (most notably highly visible security incidents and new laws/regulations) impact what we end up working on. Oddly, the American Recovery & Reinvestment Act of 2009 (ARRA)HIPAA/HITECH has had that impact on us in two distinct time frames. The first was several years ago when we saw an inrush of projects relating to Smart Grid technology. That inrush stopped nearly as quickly with the infamous ComEd Chicago Smart Meter fires (e.g., a high visibility security incident), significantly slowing Smart Grid initiatives. Now, years later, we are feeling the impact once again, as organizations look to comply with Core Measure 15 (CM15) to qualify for the benefits of the EHR Incentive Program that was baked into the ARRA.
In order to qualify for the incentives, medical practices need to prove “meaningful use” of their electronic health record (EHR) systems. CM15 states that the provider needs to “Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1) and implement security updates as necessary and correct identified security deficiencies as part of its risk management process.” The objective of CM15 is to ensure that key EHR risks are being reduced to an acceptable level.
I have noted some confusion on the definition of “security risk analysis”. Fortunately, OCR issued some pretty definitive guidance on this issue:
I think the guidance is very well done, in that it is perfectly aligned with prevailing good practice and the HIPAA standard that these organizations are subject to. In short it says, in order to understand which of the HIPAA controls you need (remember many are deemed “addressable”) and what an appropriate implementation is in your case (e.g., should passwords be 16 characters and change weekly or 3 characters and never have to change?) you need to understand risk. So the security risk analysis is a “risk assessment” ideally aligned with some form of good risk assessment guidance (e.g., NIST 800-30, ISO-27005).
One interesting delta between HIPAA/OCR guidance and CM15 is that CM15 states; “protect electronic health information created or maintained by the certified EHR technology…” where HIPAA states “Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity” (see section (ii)(A) of 45 CFR 164.308(a)(1)). Restricting it to just the EHR is not rationalizable, given the risk.
If you’re looking to address CM15 – the likely steps are:
- Conduct a Risk Analysis (Assessment) that covers all Electronic Patient Health Information (ePHI) created, received, maintained, or transmitted by the organization.
- Consider an External Penetration Test to ensure that the organization’s external security posture is sufficient to address the risks identified in the RA.
- Consider an Internal Vulnerability Assessment to support vulnerability understanding during the RA and benchmark internal configuration/patch management practices against HIPAA.
- If you’re running a WLAN, review the configuration to ensure that it doesn’t allow unintended access.
- Review your firewall configuration and rule base to ensure all ingress/egress is rationalized.
- Gain attestation from your EHR vendor as to the security of their application.
- Build a Risk Treatment Plan that reduces key risks to an acceptable level.
- Use your RA to determine your responsibility on HIPAA’s “addressable implementation specifications”.
- Develop a prioritized Road Map to bring the organization into HIPAA compliance.
- Execute on the Road Map.
- Repeat (security is a direction not a destination).
Supposedly HHS will be conducting random audits of providers that receive incentive money, so CM15 should be taken seriously. Don’t forget to spend the time to document each step of the process – for unfortunately, during an audit, if it’s not documented it doesn’t exist!