Meaningful Use Security Risk Analysis

July 2011

By Feisal Nanji, Techumen, and Jeffrey White, Aspen Advisors

During the first quarter of 2011 alone, there have been media reports of inappropriate access to electronic Personal Health Information (e-PHI) of four sizeable healthcare organizations. This is damaging in terms of public relations, patient confidence, possible revenue loss, and increased costs to protect patients with exposed identifying details.

It seems that many organizations are overlooking or delaying the need to perform a security risk assessment.

Yet, under the Health Information Technology for Economic and Clinical Health Act (HITECH) enacted as part of the American Recovery and Reinvestment Act of 2009 (ARRA), one of the core Meaningful Use (MU) measures for both Eligible Professionals and Eligible Hospitals alike is the requirement for healthcare providers to “Conduct or review a security risk analysis … and implement security updates as necessary, and correct identified security deficiencies prior to or during the EHR reporting period to meet this measure.”

This measure is, therefore, a key task healthcare providers must conduct before attesting to their ability to meet all Stage 1 requirements. Additionally, the risk analysis requirement in the HIPAA Security Rule is not only an integral part of meeting “meaningful use” for HITECH but also for being in compliance with the law.

All e-PHI created, received, maintained, or transmitted by an organization is subject to the Security Rule. The Security Rule requires entities to evaluate risks and vulnerabilities in their environments and to implement reasonable and appropriate security measures to protect against reasonably anticipated threats or hazards to the security or integrity of e-PHI. Risk analysis is the first step in that process.

This paper outlines the key steps required to achieve this important core Meaningful Use measure. Conducting a risk analysis is the first step in identifying and implementing safeguards that comply with and carry out the standards and implementation specifications in the Security Rule. Therefore, a risk analysis is foundational for healthcare providers to obtain the HITECH subsidies offered by the federal government.

Why Perform a Risk Analysis?

Under the HIPAA Security Rule all e-PHI created, received, maintained, or transmitted by a “Covered Entity” (CE) is subject to the Security Rule. If we assume that information technology powers modern healthcare, then it stores or disseminates most everything an entity might know about a patient. Thus e-PHI security and privacy is fundamental and paramount.

The Security Rule requires entities to evaluate risks and vulnerabilities in their technology environments and to implement reasonable and appropriate security measures to protect e-PHI. The Office for Civil Rights (OCR), the security watchdog for the Department of Health and Human Services (HHS), in particular, is responsible for issuing annual guidance on the provisions in the HIPAA Security Rule. The OCR is also the body responsible for ensuring CEs are complying with the intent of the security rule. From a compliance perspective then, it may seem especially wise to take heed to what the OCR is saying.

In its first guidance released on July 14, 2010, the OCR states: “A risk analysis is foundational, and must be understood in detail before OCR can issue meaningful guidance that specifically addresses safeguards and technologies that will best protect electronic health information.”

In short, an information technology risk analysis is the fundamental security cornerstone the Department of Health and Human Services expects covered entities to meet.

How to Conduct a Risk Analysis?

A risk analysis using a risk-based approach is the very foundation from which to build your information security compliance program. A security risk analysis should be conducted with active participation of internal auditors, IT leadership, and IT subject matter experts. Many organizations look toward well experienced consultants that can lead the effort and efficiently drive to the desired outcome.

The OCR “suggests” in its first guidance that a covered entity might use the NIST risk-based approach for doing a risk analysis:

“We note that some of the content contained in this guidance is based on recommendations of the National Institute of Standards and Technology (NIST). NIST, a federal agency, publishes freely available material in the public domain, including guidelines. Although only federal agencies are required to follow guidelines set by NIST, the guidelines represent the industry standard for good business practices with respect to standards for securing e-PHI. Therefore, non-federal organizations may find their content valuable when developing and performing compliance activities.”

Of course other good risk frameworks exist, such as Control Objectives for Information Technology (COBIT) developed by the Information Systems for Auditing and Control Association (ISACA), or Octave developed by the CERT Software Engineering Institute at the Carnegie-Mellon University. These frameworks may be used, but with OCR’s recommendation and the fact that the NIST guidance, as provided in its Special Publication 800-30 is excellent, thorough, and easily tailored for small, medium, and large covered entities, we recommend using the NIST framework.

Primary Steps for Security Risk Assessment

NIST’s risk assessment methodology encompasses nine primary steps outlined below.

1. System Characterization. To fully understand your technology risk, you must understand key technology components in your infrastructure. These could be applications, hardware, operating systems, laptops, and mobile devices (i.e., pretty much anything that receives, stores, or transmit information).

2. Threat Identification. Threats can be highly specific and discrete and will usually be based on threat motivation and capability. In general, however, threats can be divided into three types:

Human threats created or instigated by human beings;
Environmental threats caused by what insurance companies term “Acts of God”; and
Natural threats that arise from the inherent nature of information systems.

3. Vulnerability Identification. Your systems will be vulnerable to a wide range of these threats. Vulnerabilities can range from poor software construction and poor design of back-up power to poor training on information security. However, much vulnerability is found within information systems. These could be described as vulnerabilities within applications, databases, networks, and combinations of these.

4. Controls Analysis. Controls analysis allows an organization to assess the capabilities of your existing set of controls to meet your environment’s needs. It does this by helping you identify any existing policies and procedures or standards that may be in violation. Controls are typically described as one of three types:

Preventative: lower the likelihood of the threat exercising the vulnerability;
Mitigating: lower the impact should the threat exercise the vulnerability; or
Detective: alert management that the threat has exercised the vulnerability.

Thus controls will be either technology or process based and usually involve interactions among people. Since many controls safeguard against multiple vulnerabilities, it is usually easier to keep track of multiple instances of a control than to attempt to define and consolidate an “underlying control”.

5. Likelihood Determination. The risk assessment team should use their best judgment to assign likelihoods, considering the threat motivation and ability, the nature of the vulnerability, and current and planned controls. We suggest that a risk assessment methodology use three tiers to determine likelihood:

High: The threat will successfully exercise the vulnerability more than once a year;
Medium: The threat will successfully exercise the vulnerability less than once a year but more than once every three years; or
Low: The threat will successfully exercise the vulnerability less than once every three years.

The output of this step of the risk assessment process is a likelihood determination for each threat and vulnerability pair facing the system or systems undergoing the risk assessment.

6. Impact Analysis. In the absence of any historical data, the risk assessment team should use their best judgment to analyze that impact, considering for each system the effects of lost confidentiality, integrity, or availability, and the effect of any current or planned mitigating controls. For a recent client, we suggested a risk assessment methodology that uses three tiers to determine impact:

High: The impact will cost more than 0.1% of covered entity revenue in financial outlays, require more than 400 man-hours to repair, endanger patient safety, or damage a covered entity’s reputation for security;
Medium: The threat will cost more than 0.01% of revenue in financial outlays or require more than 40 man-hours to repair; and
Low: The threat will cost less than 0.01% of revenue or require less than 40 man hours to repair.

7. Risk Determination. Risk determination is a combination of the impact rating and the likelihood determination. We suggest a three tiered matrix to quickly make decisions. Response speed is critical when an incident occurs, and having a ready way to gauge risk is, therefore, instrumental.

As part of the risk management process, the healthcare organization’s compliance group, IT security committee, or the audit committee should review all risks assigned to this quadrant to determine if the risks have been appropriately ranked and if additional controls are needed.

8. Control Recommendations. Based on the determination of risk, your organization will need a roadmap for planning controls for future implementation. Through this process your management team can make fundamental decisions to either accept each risk as it stands or alleviate some of the risk by imposing additional controls. This is an especially useful exercise since it covers approvals, scheduling, and budgeting for additional control implementation.

9. Results Documentation. Finally, all of this effort must be documented. Compliance officers who have gone through frequent audits know the value of excellent documentation. This, therefore, is a must and should be considered the capstone of your work. A readily available, well written, and thoughtful document that describes your entire risk analysis process will go a long way to assuage any auditor.

When to do a Risk Analysis?

To prepare for Meaningful Use attestation, it is recommended to conduct the security risk analysis at both the technical design and system build phase when implementing a new EHR system. Additionally, it will be important to update the risk analysis further on in the MU Roadmap approximately four months prior to go-live.

As ongoing changes happen, new risk occurs. We recommend that large organizations conduct an annual review. Smaller organizations may only do this every two years, but in our judgment, the pace of information technology changes and requirements is so rapid that an annual assessment is necessary for most institutions.

As an added value, the annual risk assessment becomes part of the compliance process; that is, the risk assessment can be merely updated as an addendum and not as an overbearing intrusion that competes with other organizational needs.. A regular review of your risk posture is what is required to protect e-PHI. Too many new threat vectors and vulnerabilities are introduced into information environments each day. A reasoned, systematic, and consistent approach will help to achieve your organizational goals.

Conclusion

Spurred by the HITECH Act, the healthcare industry is embracing Electronic Health Records at an accelerating rate. This move from paper records to fully electronic patient records is significant and carries with it a need for heightened responsibility since digital information can be copied, transmitted, or used so easily. As such, the risk accruing from this transition to electronic records must be well understood by healthcare organizations. In its passage of HITECH, the U.S. Congress took special consideration to note that security and privacy of patient records should be a paramount concern.

The Department of Health and Human Services has continued the theme of protecting patient health information and has deemed adequate security and privacy consideration should be in scope as one of its initial (“Stage 1”) core measures for demonstrating Meaningful Use. By doing so, HHS has clearly stressed that security and privacy will not be taken lightly. In essence, HHS recognizes that the very success of the HITECH program rests in part on patients’ ability to trust provider information systems with sensitive information.