HIPAA Risk Analysis Lapses Lead to OCR Enforcement: How Is Your Security Management Process? HIPAA Risk Analysis Lapses Lead to OCR Enforcement: How Is Your Security Management Process?

HIPAA Risk Analysis Lapses Lead to OCR Enforcement: How Is Your Security Management Process?

In April, the U.S. Department of Health and Human Services, Office for Civil Rights (OCR) announced the latest in a series of enforcement actions against Health Insurance Portability and Accountability Act (HIPAA) regulated entities with deficient security management processes. First, Metro Community Provider Network (MCPN), a HIPAA covered entity (CE), agreed to pay a $400,000 resolution amount and enter into a corrective action plan (CAP) after workforce members fell victim to a phishing scam that resulted in unauthorized disclosures of protected health information. Then, CardioNet, another CE, agreed to pay a $2.5 million resolution amount and enter into a CAP to resolve potential HIPAA violations stemming from the theft of an unencrypted mobile device containing electronic protected health information (ePHI). The CardioNet settlement is OCR’s first with a wireless health services provider. These settlements, as have many before them, emphasize the vital importance of a robust and comprehensive security management process, including an entity-wide risk analysis.
 
MCPN is a federally-qualified community health center that provides medical and dental care, pharmacy, social work, and behavioral health care services, primarily to low-income patients in the Denver area. In January 2012, MCPN reported that a hacker had phished workforce members and accessed their email accounts, resulting in an exposure of 3,200 individuals' ePHI. According to MCPN's breach notice:
 
The incident involving protected health information was a result of an email phishing scam. In this incident, a hacker sent an email to several of Metro Community Provider Network’s employees that claimed to be from a trusted source. The email asked for the employee to click on a link and provide login information. This was then used to gain access to the employee’s confidential emails. It is important to note that none of our employees had any intention to cause patients any harm, nor did they have any intention of allowing a hacker to access personal information; they were victims of a scam.[1]

While OCR noted that MCPN took appropriate corrective action, it had not conducted an assessment of risks and vulnerabilities to ePHI before the phishing incident, and therefore, had not instituted a plan to appropriately reduce existing risks and vulnerabilities. Further, MCPN did not conduct a risk analysis until several weeks after the phishing attack, and OCR determined that this analysis was insufficient to meet HIPAA Security Rule requirements.

OCR identified similar shortcomings in CardioNet’s Security Rule compliance. CardioNet is a wireless health services provider of ambulatory cardiac monitoring services that is based in Pennsylvania. Also in January 2012, CardioNet reported that a workforce member’s unencrypted laptop containing the ePHI of 1,391 individuals had been stolen from a parked vehicle.[2] OCR’s investigation revealed, in part, that CardioNet lacked a compliant risk analysis at the time of the breach, and as a result, neglected to develop a plan to reduce the risks and vulnerabilities to its ePHI. 
 
In accordance with the CAPs to which they agreed, both MCPN and CardioNet must:
 
  • Conduct a "current, comprehensive, and thorough" analysis of security risks and vulnerabilities to ePHI, to include all facilities and electronic equipment, data systems, and applications that the CE controls, administers, or owns that contain, store, transmit, or receive ePHI.
    • Submit a documented risk analysis for OCR's review and approval.
    • Review the risk analysis at least annually, and more frequently as needed, to account for environmental or operational changes affecting the security of ePHI.
    • Develop an organization-wide risk management plan (RMP) to address and mitigate security risks and vulnerabilities identified by the risk analysis. The RMP must include a timeline and process to implement, evaluate, and revise risk remediation activities.
  • With the initial analysis and each update, assess whether existing security measures are sufficient to protect ePHI. If not, the CE must revise the existing risk management plan, policies and procedures, and workforce training materials as needed.
  • Review and, as necessary, revise existing Security Rule policies and procedures based on the risk analysis and implementation of the RMP. OCR must pre-approve the policies and procedures.
  • Review and, as necessary, revise existing Security Rule workforce training materials based on the risk analysis and implementation of the RMP. OCR must pre-approve the training materials.
Commenting on the MCPN settlement, OCR Director Roger Severino emphasized: "Patients seeking health care trust that their providers will safeguard and protect their health information. Compliance with the Security Rule helps covered entities meet this important obligation to their patient communities." Addressing the CardioNet settlement, Director Severino noted that "[m]obile devices in the health care sector remain particularly vulnerable to theft and loss."
 
HIPAA Security Rule Requirements
 
The Security Rule's Security Management Process Standard is an Administrative Safeguard that requires CEs and business associates (BA) to “[i]mplement policies and procedures to prevent, detect, contain, and correct security violations.”[3] The standard consists of four elements known as "implementation specifications":

  • Risk analysis. Conduct an accurate and thorough assessment of the potential risks to and vulnerabilities of the confidentiality, integrity, and availability of ePHI held by the CE or BA.[4]
  • Risk management plan. Implement security measures sufficient to reduce the identified risks and vulnerabilities to a reasonable and appropriate level.[5]
  • Sanction policy. Apply appropriate sanctions against workforce members who fail to comply with the CE's or BA's security policies and procedures.[6]
  • Information system activity review. Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.[7]
These are not standardized, one-size-fits-most activities. OCR recognizes that CEs and BAs are different, and a regulated entity can take a flexible approach to Security Rule compliance that takes into account the entity's size, complexity, and capabilities; its technical infrastructure, hardware, and software security capabilities; the cost of contemplated security measures; and the probability and criticality of potential risks to ePHI.[8] Whatever the specifics of the CE's or BA's approach, the security management process must be reasonable and appropriate for the entity and its environment, and it must meet a four-fold goal:

  1. Ensure the confidentiality, integrity, and availability of all ePHI the CE or BA creates, receives, maintains, or transmits;
  2. Protect against reasonably anticipated threats or hazards to the security or integrity of ePHI;
  3. Protect against reasonably anticipated uses or disclosures of ePHI that violate the Privacy Rule; and
  4. Ensure workforce compliance with the Security Rule.[9]
OCR has described risk analysis and risk management as foundational to a regulated entity's Security Rule compliance.[10] In fact, conducting an enterprise-wide risk analysis is the first step an entity should take when creating a Security Rule compliance program. Many of OCR's recent enforcement actions are rooted in absent or deficient risk analysis and/or risk management. Indeed, OCR’s largest monetary settlement to date involved a covered entity’s failure to conduct a risk analysis incorporating all of its information technology equipment, applications, and data systems utilizing ePHI. Clearly, this is an area of great focus and attention for OCR.

While the Security Rule mandates that CEs and BAs perform a risk analysis, it does not require a specific format or methodology, and OCR recognizes that implementation will vary with the organization’s particular circumstances and needs. However, in its guidance materials, OCR describes several baseline expectations for a compliant risk analysis. OCR’s guidance incorporates the U.S. Department of Commerce’s National Institute of Standards and Technology (NIST) recommendations for security management. NIST has identified certain key elements for conducting a risk analysis that—when customized to suit an entity’s unique structure and environment—will help the organization most effectively identify risk: [11]

  • Appropriate scoping. To properly identify risk analysis parameters, the CE or BA must know what ePHI it holds, where ePHI is located, and how ePHI flows into, within, and out of the organization. The result will be a “general characterization of [each] information system, its operating environment, and its boundary,” along with an inventory of all IT assets that house or transmit ePHI. The entity should track all ePHI within the organization’s physical and logical boundaries, as well as ePHI created, received, and transmitted by any remote workforce and on removable and portable media—another target for OCR enforcement and always an area of heightened data security risk.
  • Sound information gathering. Effective risk analysis depends on accurately identifying organizational vulnerabilities (flaws or weaknesses in system security procedures, design, implementation, control) and the internal and external threats (factors that can have a negative impact on ePHI) that may intentionally or unintentionally exploit those vulnerabilities. A high degree of organizational self-awareness is essential to unmasking vulnerabilities and threats. As a part of its risk analysis process, the CE or BA should pinpoint (1) the conditions under which it creates, receives, maintains, processes, and transmits ePHI and (2) the security controls currently in place to protect ePHI.
  • Identifying realistic threats. The sources of threat to ePHI are as varied as the ePHI itself and the organizations that maintain it, and threats may be intentional or unintentional. Threat sources may be natural (floods, earthquakes, tornados), human (thieves, hackers, malicious or negligent insiders), or environmental (power surges, hazmat contamination, pollution). Even the BA vendors that receive access to an entity’s ePHI may be considered as potential threat sources, as BAs often experience security incidents and breaches. The CE or BA must direct resources toward identifying threats and threat sources applicable to the entity and its specific operating environment.  External resources, such as NIST guidance, the U.S. Computer Emergency Readiness Team, vendors, insurers, and information-sharing groups may provide useful threat-identification data.
  • Identifying potential vulnerabilities. A threat cannot negatively impact ePHI without an organizational vulnerability to exploit. Vulnerability identification focuses on the confidentiality, integrity, and availability of ePHI and requires an examination of the “realistic technical and nontechnical areas where [ePHI] can be disclosed without proper authorization, improperly modified, or made unavailable when needed.”[12] CEs and BAs can consult internal and external resources to identify potential vulnerabilities, including prior risk analyses, audit reports, and vulnerability scan and system security test results, as well as Internet, vendor, and insurance information. The federal government’s National Vulnerability Database is another valuable source of information.
As the CardioNet settlement makes clear, unencrypted portable electronic devices (PED), such as smartphones and laptops, present a significant vulnerability. Many of OCR's settlements involve the loss or theft of unencrypted PEDs. CEs and BAs that create, store, or transmit ePHI on or from unencrypted PEDs should focus immediate attention on remediating this substantial vulnerability. This includes not only addressing the lack of encryption but also developing and implementing policies and procedures governing the use and movement of these devices both within and outside of the entity.
 
  • Assessing current security controls. CEs and BAs should evaluate technical and nontechnical security controls wherever they create, receive, maintain, process, or transmit ePHI. This involves not only determining whether the security controls the entity thinks are in place are compliant with the Security Rule and sufficient but also whether they are actually in place and are properly configured and used. As NIST emphasizes, “[a] thorough understanding of the actual security controls in place for a covered entity [or business associate] will reduce the list of vulnerabilities, as well as the realistic probability, of a threat attacking (intentionally or unintentionally) ePHI.”[13] Remember that the appropriateness and adequacy of the entity’s security measures will depend on, among other things, the entity’s structure, size, and geographical dispersion.
  • Determining probability and criticality. Risk is a function of both probability (the likelihood that a threat will exploit an existing vulnerability) and criticality (the degree of organizational impact that will result from loss of the ePHI’s confidentiality, integrity, or availability). Even the nastiest malware variant may not present a significant risk if the organization appropriately manages potential vulnerabilities. Conversely, a more remote threat may be riskier if the organization is riddled with unpatched vulnerabilities or if the threat targets critical organizational assets.
  • Calculating level of organizational risk. Risk is determined by assigning qualitative or quantitative values to probability and criticality and assessing these factors in relation to each other. Depending on the organization's specific circumstances and the particular data impacted, the entity's risk analysis matrix may look like this:
PROBABILITY CRITICALITY
Low Impact Moderate Impact High Impact
Low Likelihood Low Risk Low Risk Moderate Risk
Moderate Likelihood Low Risk Moderate/High Risk High Risk
High Likelihood Moderate Risk High Risk High Risk
 
  • Recommending security controls. After identifying risk levels, a CE or BA should recommend additional controls as needed to reduce the risk reasonable and appropriate levels. Based on these recommended controls, the CE or BA can begin to craft its RMP. The Security Rule describes implementation specifications designed to appropriately reduce risk. While it may not be feasible—monetarily or operationally—for the entity to implement all recommended controls, it can perform a cost/benefit analysis to help it prioritize the risks to mitigate. HIPAA-regulated entities should be aware, however, that many implementation specifications are "required," meaning they "must" be implemented.[14] Others are "addressable," which means a CE or BA must (1) assess whether the specification is reasonable and appropriate within the entity's environment, when "analyzed with reference to its likely contribution to protecting [ePHI]," and (2) as applicable, either (a) implement it; (b) if implementation is not reasonable and appropriate, document why and implement an "equivalent alternative measure" if doing so is reasonable and appropriate.[15]
  • Documenting risk analysis results. In keeping with Security Rule requirements, the CE or BA should document the risk analysis and RMP in writing, and retain the documentation for at least six (6) years from the date it was created or was last in effect.[16] Local laws, or the entity's own policies, may require a longer retention period. The organization should make documentation available to the individuals responsible for implementing the security management process.[17]
  • Regularly reviewing results. The security management process is not static, and regulated entities should not store their documentation—or related efforts—on the shelf. Rather, the individuals responsible for implementation should periodically review both the risk analysis and RMP and, most importantly, update the documentation in response to environmental or operational changes affecting the security of ePHI.[18]
In all cases, the CE or BA must remember that the security management process is active and living and must grow and change as necessary to safeguard the confidentiality, integrity, and availability of ePHI.

Conclusion

The MCPN and CardioNet settlements are significant not because they are groundbreaking—OCR has walked the risk assessment/risk management path many times before—but because they are not groundbreaking. With these enforcement actions, OCR continues to hammer home the message that the security management process should be top-priority for CEs and BAs that create, receive, maintain, or transmit ePHI and that risk analysis and risk management are indeed foundational to achieving and maintaining Security Rule compliance. HIPAA-regulated entities should not only thoughtfully plan, carry out, and implement a risk analysis and RMP but also be mindful of organizational and environmental changes that require them to review and revise their processes to best safeguard ePHI.

For more information on HIPAA security, contact Kim Metzger, Deepali Doddi or another member of our Data Security and Privacy Group.

This publication is intended for general information purposes only and does not and is not intended to constitute legal advice. The reader should consult with legal counsel to determine how laws or decisions discussed herein apply to the reader’s specific circumstances.


[1] Source: Mark Meredith, DataBreaches.net, https://www.databreaches.net/co-hackers-tap-into-medical-groups-records-after-employees-fall-for-phishing-attempt/ (accessed April 19, 2017). The notice is no longer linked to MCPN's website.
[2] OCR’s resolution agreement with CardioNet indicates that the entity also reported another breach in February 2012 affecting the unsecured ePHI of 2,219 individuals. 
[3] 45 C.F.R. § 164.308(a)(1)(i).
[4] 45 C.F.R. § 164.308(a)(1)(ii)(A).
[5] 45 C.F.R. § 164.308(a)(1)(ii)(B).
[6] 45 C.F.R. § 164.308(a)(1)(ii)(C).
[7] 45 C.F.R. § 164.308(a)(1)(ii)(D).
[8] 45 C.F.R. § 164.306(b)(2).
[9] 45 C.F.R. § 164.306(a).
[11] NIST Special Publication 800-30, Rev. 1: Guide for Conducting Risk Assessments, (Sept. 2012); NIST Special Publication 800-66, Rev. 1: An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule (Oct. 2008), Appendix E.
[12] NIST Special Publication 800-66, Rev. 1: An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule (Oct. 2008), Appendix E.
[13] Id.
[14] 45 C.F.R. § 164.306(d)(2).
[15] 45 C.F.R. §§ 164.306(d)(2), (3).
[16] 45 C.F.R. §§ 164.316(b)(ii), (c)(1).
[17] 45 C.F.R. § 164.316(c)(ii).
[18] 45 C.F.R. § 164.316(c)(iii).

View Full Site View Mobile Optimized