Healthcare providers missing the mark on risk assessments

As the comment period continues for the recently published proposed rules and draft certification criteria and standards associated with “meaningful use” of electronic health records, it appears that a large proportion of healthcare providers are not prepared to comply with the one meaningful use measure related to security and privacy that has been proposed as a requirement for 2011. In comments reported last week, members of the Health IT Policy Committee working with the Office of the National Coordinator at HHS cited a survey that found 48 percent of responding health providers do not perform risk assessments. The stage 1 (2011) measure associated with the health outcomes policy priority for privacy and security (“Ensure adequate privacy and security protections for personal health information”) found in the Notice of Proposed Rulemaking says simply that EHR users must conduct or review a security risk analysis and implement security updates as necessary. This and other measures demonstrating meaningful use must be met by providers to receive incentive payments for adopting electronic health records.

At first glance the security and privacy bar appears to have been set quite low (there is a separate list of security functionality that a certified EHR system must be able to perform), especially since risk analysis is something covered entities like providers are already required to do under HIPAA rules. Among the requirements of the HIPAA Security Rule — which went into effect in 2003 and with which compliance has been required by covered entities of all sizes for almost four years — is an Administrative Safeguard for risk analysis: “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” (45 CFR 164.308(a)(1)(ii)(A)). Without getting to the heart of why so many providers have yet to implement the practices to meet this HIPAA requirement, practically speaking this means they now have another 18 months or so to get their security houses in order. There’s been some discussion among ONC’s advisory committees as to what specifically a compliant risk analysis must entail, and there is not as yet a corresponding standard to provide that specificity. From a government perspective agencies likely have to look no further than NIST and its Special Publication 800-66, “An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule,” which addresses conducting risk assessments using a process adapted from NIST’s own risk assessment process documented in Special Publication 800-30, “Risk Management Guide for Information Technology Systems.” This guidance might be less comprehensive than risk assessment practices found in other security management or IT governance frameworks, particularly as 800-66 constrains the risk assessment to consider only the risks of non-compliance with the security standards general rules for electronic protected health information (PHI). Because the financial penalties for HIPAA security rule non-compliance are relatively minor, and the criminal penalties are rarely sought, the most relevant risks for a private-sector covered entity might be business consequences like negative publicity or the loss of customers.

The point is, healthcare providers and other covered entities have access to many available approaches, methodologies, and process standards for risk analysis, yet to date do not appear to be using any of them. In order to avoid falling short on meaningful use, these organizations need to set in motion the process of changing their security program operations to make routine risk analysis an integral component. Using the HIPAA Security Rule requirements as a precedent, the specifics of what a risk analysis must include may not be enumerated in exhaustive detail, so following just about any accepted risk analysis standard has a good chance of being compliant, whether choosing to go with NIST, or ISO 27005, or COBIT, or ITIL, or a comparable approach.