Lets review different viewpoints driving why healthcare organizations implement a HIPAA Security Risk Analysis. The purpose of exploring these different perspectives is to show that the primary objectives for doing a HIPAA Security Risk Analysis can be categorically defined as either security or compliance – and that both of these objectives can be achieved if a practical approach to the analysis is utilized. Here I use the term security as the goal of safeguarding electronic protected health information (ePHI) and compliance to mean the requirement that healthcare organizations operate consistently with guiding regulatory mandates – HIPAA & HITECH Act.
While many think of security and compliance as the same thing, they are in fact unique, and not identical objectives. For example, it’s very common for organizations to consider themselves compliant with the HIPAA Security Rule, yet to be in a state of high risk of an ePHI data breach. Conversely its also possible for a health IT environment to be quite secure without being compliant. Ultimately healthcare organizations have both security and compliance risk and need to achieve both.
The following examples summarize different viewpoints. In reality most organizations undertaking a HIPAA Security Risk Analysis want to achieve both security and compliance, but there is usually an over-riding primary factor driving the effort. These viewpoints are meant to highlight those dominant factors as they tend to influence the assessment and the eventual value that is derived from the effort.
The compliance view of HIPAA Security Risk Analysis: When the objective is to become “compliant” the assessment tends to come in one of two flavors:
- Check the box that says “we did a HIPAA Security Risk Analysis” or
- To ensure that all of your IT controls around safeguarding ePHI are “compliant”
In either case, the risk of focusing on compliance is that it becomes a rote effort focused on just getting it done rather than getting to the essence or the intent of the regulation, which is safeguarding protected health information.
The meaningful use view HIPAA Security Risk Analysis: This view, of course, is driven primarily by meeting the HITECH Act’s meaningful use core objectives, so this is somewhat of a corollary to the previous example. In this case the objective defined by the HITECH Act to meet meaningful use is to protect ePHI created or maintained by the EMR system. CMS defines this core objective as follows:
Objective: Protect electronic health information created or maintained by the certified EHR technology through the implementation of appropriate technical capabilities.
Measure: 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 business Associate view of HIPAA Security Risk Analysis: This too is similar to the compliance view. In the case of a business associate (BA), the driver is either:
- Be compliant with the HIPAA Security Rule as is now required of BAs by the HITECH Act
- The BAs client – the covered entity – is pressuring them to show that they have an effective information security program in place
The security and risk management view of HIPAA Security Risk Analysis: Organizations in this camp are undertaking a security assessment purely for the purpose of identifying risk within the health IT environment to ensure that the ePHI is effectively safeguarded and that IT resources are focused on areas of most importance. This is the pure security perspective.
How to achieve all of these? Focus on the intent of the HIPAA Security Rule. In the case of the meaningful use view, for example, that means to focus on the “objective” they define (protect ePHI) rather than completely focusing on how they “measure” the achievement of that objective (Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1) ). By focusing on the intent of the guidelines defined by the HIPAA Security Rule you won’t be another victim of rote security controls, like the ever common intrusion detection system, which in concept is great, but in practice is often implemented in a way that provides little security. The HIPAA Security Rule is flexible and the guidelines are defined in such a way to allow interpretation depending on the size, complexity and site-specific characteristics of the healthcare IT environment in question. This allows enough flexibility for most health IT organizations to implement cost effective and practical solutions, whether technical controls or operational procedures that achieve both security and compliance.
Here are a couple of tips to consider when embarking on a HIPAA Security Risk Analysis.
- Avoid a checkbox approach to audits in which the existence of a controls (true / false) are the defining characteristics of whether a guideline is met or not. This approach fails to identify risk in which controls, such as a firewall, IDS or security policy, exist but are not effective. This approach also yields many recommendations for controls that are often expensive, not practical and can be mitigated by simple and cost-effective work arounds.
- Leverage a risk-based approach in which the analysis focuses on areas of risk for your particular environment. This focuses the analysis on practical areas that can minimize your security risk.
- Ensure you use an independent and objective party for your analysis. For example, avoid a product company that has something else to sell such as a firewall, IDS or managed security service, as their findings are likely to be clouded by the opportunity to upsell expensive “solutions” to their findings. A non-objective approach to the analysis is in many ways the opposite of a risk-based approach.
By focusing on the intent and spirit of the regulations and leveraging a thoughtful, risk-based, and non-checkbox approach to a HIPAA Security Risk Analysis, it is possible for your healthcare organization to achieve both security and compliance.