Covered entities and business associates will remember 2015 as "the year of the health care hack." The Department of Health and Human Services reports that 56 major hacks affected nearly 112 million individuals last year, including the record-breaking Anthem hack, which alone affected almost 80 million individuals. Strong incentives to digitize mean that electronic health data – including electronic protected health information (ePHI) – is more available than ever for criminal exploitation and accidental exposure. Although more electronic data is available, the health care sector is later to data security than commerce and finance, and therefore can be considerably less resilient when confronting privacy and security threats. Unfortunately, cybercrime is easier, with flourishing marketplaces for hacker skills and tools, forums to share successful social engineering tactics, and even distribution chains for faster monetization of health data. If digital data is a target for thieves, electronic health information is in the bullseye.

Of course, criminals are not the only threat to the confidentiality, integrity, and availability of electronic health data. IT systems and processes may fail. Employees or third parties may not know how to protect ePHI, or may make mistakes when accessing, using, storing, or transmitting the data. A 2015 study by the Ponemon Institute reveals that employee negligence is the number-one data security concern of both covered entities and business associates surveyed.1

Given this threat environment, it is fair to say security incidents and data breaches are not a matter of "if," but "when." According to the Ponemon Institute: 2

  • Ninety-one percent (91%) of covered entities, and 59% of business associates, had at least one data breach in the past two years. Forty percent (40%) of covered entities had more than five breaches, and 29% of business associates had more than two breaches.
  • Criminal attack was the number-one cause of data breaches among covered entities, followed by lost or stolen devices, and employee negligence. However, employee negligence was the number-one cause of data breaches among business associates, followed by third-party negligence, and criminal attack.
  • Sixty-five percent (65%) of covered entities, and 87% of business associates, had multiple security incidents involving the exposure, theft, or misuse of ePHI in the past two years. Fifty-eight percent (58%) of covered entities, and 70% of business associates, had 11-30 electronic-based security incidents.
  • Lost or stolen devices were the number-one cause of security incidents for both covered entities and business associates, followed by spear phishing and web-borne malware attack.

Data breaches are expensive. The Ponemon Institute estimates the average financial cost of a data breach is more than $2.1M for covered entities, and more than $1M for business associates. Patients, too, may lose money to financial identity theft. However, breach costs are not limited to financial loss. Covered entities, business associates, and patients may suffer reputational injury as the result of a data breach. Patients may be subject to medical identity theft, and with it the potentially life-threatening consequences of a mixed medical record. Likewise, patients will likely refuse to disclose sensitive, yet vital, medical information – such as mental health concerns, HIV status, substance abuse, and the like – if they do not believe their doctors can keep this information safe and confidential. This, in turn, impacts public health reporting, making compromised data security in health care a true public health concern. The tentacles of harm reach far and wide.

The threat environment may be daunting, but the health care sector is far from helpless to protect itself and its patients. A variety of tools can assist covered entities and business associates in anticipating, protecting against, and responding to privacy and security threats, and preparing for the anticipated second round of OCR HIPAA compliance audits. One of the sharpest of these tools is the Security Rule risk analysis. A risk analysis is an organization-wide "accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability" of ePHI. (45 CFR 164.308(a)(1)(ii)(A)). Risk analysis is a required implementation specification under the Security Rule, meaning that a CE or BA must perform the analysis in order to be compliant with the Security Rule. OCR Director Jocelyn Samuels has called comprehensive risk analysis, in combination with timely risk management practices, "the cornerstone of any good compliance program."

If you are not convinced that a comprehensive Security Rule risk analysis should be an integral part of your organization's electronic data management program, OCR's recent high-dollar settlements with covered entities should catch – and hold – your board's and C-suite's attention:

  • University of Washington Medicine – December 14, 2015 ($750,000 resolution amount):  Approximately 90,000 patients' ePHI was exposed when an employee downloaded an email attachment containing malware. UWM failed to follow its own policies in that it did not ensure affiliated entities conducted system-level risk assessments and properly identified risks and vulnerabilities. OCR Director Samuels said of the settlement: "All too often we see covered entities with a limited risk analysis that focuses on a specific system such as the electronic medical record or that fails to provide appropriate oversight and accountability for all parts of the enterprise .... An effective risk analysis is one that is comprehensive in scope and is conducted across the organization to sufficiently address the risks and vulnerabilities to patient data."
  • Triple-S Management Corporation – November 30, 2015 ($3.5M RA): A former employee whose access rights were not terminated improperly accessed a database while working for a competitor, exposing more than 500 individuals' ePHI. Triple-S had not conducted a Security Rule risk analysis. Director Samuels emphasized the settlement was meant to convey an "important message" to covered entities about Security Rule compliance, including risk analysis.
  • Lahey Hospital and Medical Center – November 25, 2015 ($850,000 RA): A laptop containing 599 individuals' unencrypted ePHI was stolen from an unlocked treatment room overnight. OCR found widespread non-compliance and determined, among other things, that Lahey had failed to conduct a Security Rule risk analysis. Director Samuels noted that workstations associated with medical devices often contain ePHI and are highly portable; therefore, "such ePHI must be considered during an entity's risk analysis, and entities must ensure that necessary safeguards that conform to HIPAA's standards are in place."  
  • Cancer Care Group, P.C. – September 2, 2015 ($750,000 RA): A laptop containing 55,000 patients' unencrypted ePHI was stolen from an employee's car. The entity had not conducted an enterprise-wide risk assessment addressing the "common practice" of removing hardware and media containing ePHI from the facility. Director Samuels emphasized: "Organizations must complete a comprehensive risk analysis and establish strong policies and procedures to protect patients' health information .... Further, proper encryption of mobile devices and electronic media reduces the likelihood of a breach of protected health information."
  • St. Elizabeth's Medical Center – July 10, 2015 ($218,200 RA): Employees' use of an internet file-sharing application to store documents resulted in the exposure of 595 individuals' ePHI. The entity had not analyzed the risks associated with using the application. Commenting on the enforcement, Director Samuels emphasized the importance of extending the risk analysis to internet-based applications.
  • Anchorage Community Mental Health Services – December 2, 2014 ($150,000 RA): The hospital notified OCR of a breach involving 2,743 individuals after malware compromised the security of its IT resources. OCR determined that the incident was a direct result of the entity failing to identify and address basic risks, not regularly updating IT resources with available patches, and running outdated, unsupported software. Director Samuels stated: "Successful HIPAA compliance requires a common sense approach to assessing and addressing the risks to ePHI on a regular basis...."
  • New York Presbyterian Hospital/Columbia University Medical Center – May 7, 2014 (NYP = $3.3M RA; Columbia = $1.5M RA): The entities operated a shared data network, administered by both, that linked to NYP patient information systems. A physician employed by Columbia, who had developed applications for both entities, tried to deactivate a personal computer server on the network, resulting in ePHI being accessible on internet search engines. OCR found, among other things, that neither entity had conducted a risk analysis identifying all systems that accessed ePHI, and neither entity had an adequate risk management plan in place. OCR Acting Deputy Director Christina Heide emphasized that health care providers "need to make data security central to how they manage their information systems."

What exactly is a Security Rule risk analysis?

The Security Rule requires covered entities – and, now, business associates – to implement administrative, technical, and physical safeguards to protect the confidentiality, integrity, and availability of ePHI. To be compliant with the administrative safeguards requirement, CEs and BAs must have in place a security management process, meaning the entity must implement "policies and procedures to prevent, detect, contain, and correct security violations." (45 CFR 164.308(a)(1)(i)). The risk analysis is a required element of a CE's or BA's security management process, and requires the entity to perform an "accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability" of ePHI. (45 CFR 164.308(a)(1)(ii)(A)).

Some definitions are helpful to understanding the scope of a risk analysis, although not all of them come from the Security Rule:

  • A "risk" is a measure of the extent to which an entity is threatened by a potential circumstance or event, and is typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. Risks can arise from:

    • Unauthorized (malicious or accidental) disclosure, modification, or destruction of information;
    • Unintentional errors or omissions;
    • IT disruptions due to natural or man-made disasters; or
    • Failure to exercise due care and diligence in implementing and operating the IT system.
      (NIST SP 800-30 r.1)
  • "Vulnerability" means a weakness in an information system, or a system's security procedures, internal controls, or implementation, that could be exploited by a threat. (NIST SP 800-30 r.1)
  • "Confidentiality" means data or information is not made available or disclosed to unauthorized persons or processes. (45 CFR 164.304)
  • "Integrity" means data or information has not been altered or destroyed in an unauthorized manner.  (45 CFR 164.304)
  • "Availability" means data or information is accessible and useable upon demand by an authorized person. (45 CFR 164.304)

While the Security Rule requires a risk analysis, it does not mandate any particular form, format, or content and in fact is silent on these matters. This is because one size does not fit all covered entities and business associates. The Security Rule generally encourages a flexible approach to information security management (including the risk analysis), and a CE or BA may use "any security measures" that allow it to "reasonably and appropriately" implement Security Rule requirements. (45 CFR 164.306(b)). Factors to consider when evaluating what is reasonable and appropriate for your organization include:

  • The entity's size, complexity, and capabilities.
  • The entity's technical infrastructure, hardware, and software security capabilities.
  • The cost of the contemplated security measures, and whether the entity will have to divert resources from other mission-critical functions to implement the measures.
  • The probability and criticality of potential risks to ePHI – how likely is it that the identified threats will occur, and how serious will the consequences be if they do?

While there is no "one right way" to conduct a risk analysis, critical steps include:3

  1. Prepare for the Risk Assessment: Establish context for the task by defining the purpose and identifying the scope, assumptions, information sources, and analytic approaches to be used.
  2. Characterize the Organization's IT System: Define the boundaries of the IT system, including the resources and information that comprise it. This includes, but is not limited to: Hardware; software; internal and external system interfaces; data and information; users and support personnel; system mission (what processes it performs); system and data criticality (value to the organization); and system and data sensitivity (level of protection required to maintain confidentiality, integrity, and availability).
  3. Gather Information: Questionnaires; on-site interviews; review of relevant documents such as the organization's policies and procedures, system documentation, and security-related documentation.
  4. Identify Threat Sources: What natural, human, and environmental sources threaten the confidentiality, integrity, and availability of ePHI? For adversarial human threat sources, assess capabilities, intentions, and targets. For non-adversarial human threat sources, look at the potential range of effects.
  5. Identify Threat Events: What might happen, who or what might initiate it, and how relevant is it to the organization?
  6. Identify the Organization's Vulnerabilities and Predisposing Conditions: Understand the nature and degree to which the organization, its mission, its business processes, and its IT systems are vulnerable to identified threat sources and threat events. What predisposing conditions within the organization increase or decrease the likelihood a threat event, once initiated by a threat source, will adversely impact operations, assets, or individuals?
  7. Determine Likelihood: Will identified threat events actually result in adverse impacts to operations, assets, or individuals? Consider the characteristics of threat sources, identified vulnerabilities and predisposing conditions, and organizational susceptibility. What countermeasures or safeguards have been implemented, or are planned?
  8. Determine Impact: What effect will a threat event have on operations, assets, or individuals? Again, consider the characteristics of threat sources, identified vulnerabilities and predisposing conditions, and organizational susceptibility. What countermeasures or safeguards have been implemented, or are planned?
  9. Determine Risk: What is the overall risk to the organization if a threat event occurs? Consider the resulting impact, as well as the likelihood that the event will actually occur.

Once the organization completes the risk analysis, it should communicate the results to decision-makers to support appropriate risk responses. The organization must also be dedicated to maintaining the risk analysis and keeping it current – monitoring policy and law; considering changes to the organization's structure, function, and mission; keeping abreast of the internal and external threat environment; assessing the effectiveness of risk responses; and verifying workforce training and compliance.

Risk analysis is not only a regulatory requirement for CEs and BAs, it is also good business. A robust risk analysis informs decision-making at all levels of the organization, and protects both the organization and its patients by maximizing the confidentiality, integrity, and availability of ePHI. Risk analysis is not a "once and done" checkmark, but rather an ongoing process throughout the organization's life cycle.

HIPAA gives CEs and BAs broad discretion to design and implement a risk analysis that best meets the organization's needs within its broader risk management program. The regulations afford flexibility in all aspects of the risk analysis, including formality, rigor, and level of detail; methodologies, tools, and techniques; format and content; and reporting. Cost, timeliness, and ease of use are also important considerations and will vary by organization. The only requirement is that the risk analysis be reasonable and appropriate under the circumstances.

Risk analysis may be mandatory for CEs and BAs, but it is foundational to any organization's risk management program. Any entity endeavoring to perform a risk analysis should consider not only what is reasonable and appropriate, but also (1) limitations inherent in the techniques, tools, and methodologies employed; (2) the quality and trustworthiness of data inputs; and (3) subjectivity in interpreting results.  Armed with this knowledge, a CE or BA has the best chance of successfully framing, assessing, responding to, and monitoring risk to ePHI.

Footnotes

Fifth Annual Benchmark Study on Privacy & Security of Healthcare Data (Ponemon Institute, May 2015). Ponemon surveyed 90 covered entities and 88 business associates.

Id.

See NIST Special Publication 800-30 Rev. 1: Guide for Conducting Risk Assessments (September 2012).

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.