Part 1: Overview, Key Takeaways and New Terms Defined
In Part 1 of this blog, I provide an overview of OCR’s proposed changes to the HIPAA Security Rule, some commentary on the background, rationale and the potential impact on healthcare, descriptions of key changes in definitions, and OCR’s broader themes. In Part 2, I will dive into specific proposed new or updated standards and implementation specifications and speculate on what may happen next.
Overview
On December 27, 2024, the Office for Civil Rights (OCR) at the U.S. Department Health and Human Services (HHS) issued a Notice of Proposed Rulemaking (NPRM) to modify the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Security Rule to strengthen cybersecurity protections for electronic protected health information (ePHI). OCR states that it seeks to strengthen cybersecurity for regulated entities by updating the Security Rule’s standards to better address ever-increasing cybersecurity threats to the health care sector.
The Notice of Proposed Rule Making (NPRM) as published in the Federal Register is located here and OCR has published a fact sheet located here.
Impact on Healthcare Organizations Should the Security Rule Updates Go into Effect
For some organizations, particularly those larger healthcare providers, payers or business associates, who are well funded and have a strong culture of cybersecurity, many of the new definitions and requirements will be familiar, and to a large degree, already implemented in their organizations. That is because these requirements are derived from industry standards that include NIST CSF, 405(d) Health Industry Cybersecurity Practices (HICP) CISA CPGs, HHS CPGs, and others, and are considered “minimum cyber hygiene.” Some of these organizations may find they need to add documentation or perhaps adjust their implementation of the standards to meet OCR’s interpretation. For example, they may need to adjust their risk analysis to “asset based”, assessing unique risks that exist with certain information systems and their components, rather than just perform a higher “enterprise”-level risk assessment.
In a perfect world, all healthcare organizations would already be meeting minimum industry cybersecurity practices. But if that were the case, we would not need the HIPAA Security Rule. The reality is that too many organizations in the healthcare sector are not meeting basic standards today, or at least not meeting them consistently, let alone documenting them to the degree OCR expects.
Many of these organizations are not well educated or lack strong security leaders. Some are on a pathway to conform with standards, or mature their programs, and may have implemented some or most of these standards to some degree, but not fully across their organizations. Unfortunately, there are others that simply choose not to implement strong security and risk management programs, as they don’t want to invest the money, don’t understand the risk, or are willing to accept a level of risk to patient safety or protection of their ePHI that OCR (and most patients) finds to be unacceptable.
Other organizations may have the desire to have a stronger security program, but not the means. For example, many rural health organizations, nonprofits, and other regulated entities that are financially constrained will find it difficult if not impossible to meet all the requirements without financial assistance. For them, choosing to invest in security and risk management programs means diverting money from other much needed priorities. These organizations need financial support to implement stronger security programs to meet basic standards (regardless of the HIPAA Security Rule) and need it now, as threat actors are not waiting for the industry to catch up.
In summary, OCR states that it is updating the Security Rule for the following reasons
- The Security Rule, originally introduced in 2003, has not been updated since 2013. Since then, advancements in healthcare technology have necessitated stronger security measures to adequately protect electronic protected health information (ePHI).
- OCR believes it must better define the scope of the Security Rule, including the information systems and related components (what OCR also calls “technology assets”) that constitute these information systems, to ensure regulated entities are comprehensively deploying the intended security practices and controls.
- Based on investigations, enforcement actions, case law, technical assistance, and other interactions with regulated entities, OCR has observed that many regulated entities misinterpret OCR’s intentions. Consequently, clarifications—such as updated definitions, new definitions and additional implementation specifications— are needed.
- The increase in ransomware attacks and breaches affecting the healthcare sector demonstrate that many regulated entities are currently not implementing sufficient security programs to protect confidentiality, integrity and availability of ePHI. OCR proposes that the Security Rule should “include specific minimum cybersecurity hygiene requirements that are reflective of modern industry best practices.”
- Many regulated entities fail to conduct risk analyses appropriately, potentially due to a lack of specificity in the Security Rule. OCR regards risk analysis as one of the most crucial requirements of the HIPAA Security Rule and is therefore providing specific requirements for conducting it.
- Continued ransomware attacks on the industry have limited the availability and threaten the integrity of ePHI. Additionally, they have hindered recovery efforts of ePHI or the systems that create, receive, transmit or store ePHI. OCR seeks to update the Security Rule to require the establishment and testing of processes that enable regulated entities to implement security measures that support resiliency during events that adversely impact the entity.
Notable Key Changes
Some of the notable changes to the Security Rule include the below. Please read further for more detailed explanations of some of these proposed changes and others.
- Removal of the distinction between the “required” and “addressable” implementation specifications, making all implementation specifications mandatory, with specific, limited exceptions.
- Requirements for written documentation of all Security Rule policies, procedures, plans, and analyses.
- Detailed specifications for the risk analysis requirement. (Please see below risk analysis Q&A for more information).
- Clarification of existing terms and introduction of new definitions, intended to reduce ambiguity, and communicate OCR’s intentions more clearly.
- Elevation of certain implementation specifications to standards, with new required, implementation specifications for each standard.
- Requirement to maintain a system inventory of all in-scope information systems and technology assets, as well as a network map documenting flow of ePHI, including transfers to third-party systems, or business associates.
- Requirement for certain regulated entities to provide notification within 24 hours when a workforce member’s access to ePHI or related information systems is changed or terminated.
- Stronger requirements for contingency planning and responding to security incidents.
- Implementation requirements for certain technical controls and processes, including multi-factor authentication, encryption at rest, anti-malware protection, removing extraneous software from relevant electronic information systems, and disabling network ports where appropriate.
- Requirements to conduct and document testing to validate technical controls are implemented and perform as expected, perform vulnerability scanning at least every six months, complete penetration testing at least once every 12 months, and review and test certain security measures at least every 12 months.
- Requirement to implement network segmentation.
- Requirement for business associates to verify for covered entities at least once every 12 months that they have deployed technical safeguards as required by the Security Rule.
- Requirement for business associates to notify covered entities (and subcontractors to notify business associates) upon activation of their contingency plans, without unreasonable delay and no later than 24 hours after activation.
- Requirements for separate technical controls for backup and recovery of ePHI and relevant electronic information systems.
- Requirement to conduct a compliance audit at least every 12 months.
Aligning to Best Practices and Standards
OCR states that the proposed standards and implementation specifications in the updated Security Rule consider not only those promulgated by NIST, but also guidelines, best practices, methodologies, processes, and procedures published by CISA, the HHS 405(d) program, CMS, State governments, and other entities.
Removing Ambiguity
One of OCR’s largest objectives is to remove ambiguity from the HIPAA Security Rule. It does this in numerous ways, including by updating definitions of terms, adding new definitions, and clarifying what it states was its original intent. OCR notes that these clarifications are required based on its enforcement and technical assistance experiences, and recent case law including the University of Texas M.D. Anderson Cancer Center v. HHS case.
Creating Standards and Reducing Flexibility
OCR states that it is concerned that regulated entities believe that flexibility overrides the need for them to protect all ePHI and do not uniformly treat addressable implementation specifications as needing to be met if they are reasonable and appropriate.
OCR proposed to remove the distinction between ‘‘addressable’’ and ‘‘required’’ implementation specifications; this would require regulated entities to comply with both the standards and implementation specifications.
OCR states “the Security Rule sets a floor for cybersecurity protections and that its flexibility is in allowing [regulated entities] to choose the manner in which they meet the standards and implementation specifications, not whether they meet them.”
OCR has also proposed to elevate existing implementation specifications to standard level and create specifications defining how these standards must be met going forward. Additionally, OCR proposes to eliminate from the addressable implementation specifications the choice not to implement a specification or alternative, and instead require regulated entities to implement the specification or adopt a documented reasonable alternative.
OCR proposes to require specific minimum cybersecurity hygiene requirements such as a qualified information security official, elimination of default passwords, adoption of MFA, institution of offline backups, installation of critical patches within a reasonable time, and transparency of impact and vulnerability disclosures.
Scope of Data considered ePHI
OCR clarifies that the requirements of the Security Rule apply not only to electronic information systems but also to other information systems connected to or otherwise affecting electronic information systems that create, receive, maintain, or transmit ePHI. An electronic information system is considered to ‘‘otherwise affect’’ ePHI if it contains information related to an electronic information system that creates, receives, stores or transmits ePHI or to another electronic information system that otherwise impacts the confidentiality, integrity, or availability of ePHI (e.g., a system storing IDs and passwords).
Scope of Information Systems and Assets Covered by the Security Rule
While OCR aims to broadly define the scope of information systems in the Rule, common sense would state that all information systems that impact the organization’s sensitive data and its operations should be protected, with security controls implemented so as to reduce risk to an acceptable level. From a security perspective, Clearwater recommends at least meeting minimum security standards and also conducting risk analysis on all systems, regardless of what is proposed in the HIPAA Security Rule update.
The proposed update to the Security Rule may impose additional requirements to your current security practices depending on how your organization currently implements security measures, the level of documentation, or the frequency with which it performs the activity.
“Technology Asset” (Component), Information System Inventory and Network Map
OCR states that “Regulated entities cannot understand the risks to the confidentiality, integrity, and availability of their ePHI without a complete understanding of these asset” and that “the inventory forms the foundation for a fulsome and accurate risk analysis.”
OCR proposes that regulated entities maintain an inventory and network map, which includes all information systems and their ‘‘technology assets’’. Technology assets are defined as the components of an electronic information system (including but not limited to hardware, software, electronic media, information, and data).
OCR clarifies that the Security Rule requirements apply to all the components of each electronic information system and that the inventory and network map must be updated at least every 12 months (or sooner when changes to their environment occur) and inventory of their information systems and their technology assets.
Clarifying the Definition of Risk Analysis
OCR states that “despite our having made available an abundance of free and widely publicized guidance tools, OCR unfortunately has learned through its compliance and enforcement activities that regulated entities often do not perform compliant risk analyses.”
It proposes eight implementation specifications for the risk analysis standard, which are generally consistent with previously issued guidance described above. (1) review asset inventory, (2) identify threats, (3) identify vulnerabilities, (4) assess and document security measures (controls), (5) assess likelihood, (6) assess impact, (7) determine risk level, and (8) assess risk of entering into business associate agreement. The 8th element (related to BAs) is new compared to the 2010 Final Guidance. Additionally, while documentation is not listed as a specification, it is discussed elsewhere. OCR now also requires updating the risk analysis at least every 12 months (or when changes occur), as compared to the previous requirement to update periodically.
The updated of risk analysis guidance in the proposed Rule aligns very well with OCR’s past statements, enforcement actions and Clearwater’s interactions with OCR. OCR adopts terms and concepts that Clearwater has historically incorporated into its risk analysis such as “technology asset” and “component” (which make up parts of an information system). We believe this is good news for anyone who has adopted Clearwater’s “OCR Quality” and “technology asset based” risk analysis or are implementing a similar methodology that meets these requirements.
OCR has added specifications to the risk analysis standard, not previously included in its 2010 Final Guidance. These include:
- A potential increase in the scope of information systems included in the risk analysis (see above).
- A requirement to review a system inventory and network map in conjunction with conducting the risk analysis.
- An assessment of risks to ePHI posed by entering into or continuing a business associate agreement.
- A requirement to review and update the risk analysis when changes occur, but no less than every 12 months.
Many in the industry, including Clearwater, consider these specifications to be best practices. Many of our clients are already systematically and on an on-going basis conducting risk analysis, which helps to improve operational efficiency, in addition to identifying risks more quickly.
Clarifying What Constitutes Meeting Requirements
OCR notes repeated experiences of regulated entities meeting HIPAA Security Rule requirements only partially. OCR clarifies that requirements must be implemented for all systems in scope (as more clearly and inclusively discussed above). Additionally, creating policies and procedures for technical controls is not enough. The controls must be implemented and deployed. OCR clarifies that to meet these requirements, regulated entities must ensure the controls are working as expected through testing, and that they must document the implementation and deployment across all technology assets. Additionally, while the minimum requirements serve as a baseline, regulated entities must evaluate the residual risk through their risk analysis, and apply additional controls as needed to reduce risk to an acceptable level.
Formalizing and Maintaining the Risk Management Plan
OCR proposes that as a standard all regulated entities must establish and implement a plan for reducing the risks identified through its risk analysis activities. The risk management plan would require documented steps to reduce risks identified by the risk analysis to a reasonable and appropriate level, require updates at least every 12 months (or as changes to risks occur), prioritization of risks identified in the regulated entity’s risk analysis based on the risk level, and implementation of security measures in a timely manner.
Focus on Resilience
OCR clarifies that in addition to protecting ePHI, regulated entities must take reasonable and appropriate steps to ensure that they are able to make ePHI available during a security or other incident, and that they can recover data following an event. They must take into account when deciding whether a particular security measure (e.g., a technical control) is reasonable and appropriate for implementing a standard and its associated implementation specification: the effectiveness of the security measure in supporting the resiliency of the regulated entity, e.g. ability to recover data.
Documentation
OCR clarifies in most of its proposed changes that regulated entities must ensure that they have well documented policies and procedures and procedures, and that they must review and update these procedures as changes occur in their environment or business (e.g., technology upgrades, mergers), as a result of their risk analysis, when they have changes in business associate agreements, as a result of testing, and so on.
Terms Updates
Within the NPRM, OCR takes steps to clarify several terms:
- Clarifying: Access: Expands the definition of access, to ensure that the regulated entity establishes policies and procedures for ensuring that workforce members have appropriate access to ePHI as appropriate for today’s technology environment.
- Clarifying: Administrative Safeguards: Updates definition to be consistent with physical and technical safeguards. Additionally, clarifies that the safeguards have to include “related” administrative actions, that these actions are in addition to policies and procedures, and that safeguards have to be maintained.
- Clarifying: Authentication: Clarifies the definition to mean corroboration that either a person or technology asset is the one they are claiming to be.
- Clarifying Availability: Clarifies the definition of availability by specifying that availability means the property that data or information is accessible and usable upon demand by not only an authorized person, but also an authorized technology asset.
- Clarifying Confidentiality: Clarifies the definition of confidentiality to specify that it means the property that data or information is not made available or disclosed not only to unauthorized persons or processes but also technology assets.
- Adding Deploy and Implement: The Security Rule changes would clarify that technical controls must be put into place, configured, in use, and work as expected, and that they are fully deployed for all systems and components that create, receive, store or transmit ePHI.
- Adding: Electronic Information System: Whilst the Security Rule uses this term already, it does not define the term. The update would define the term as an interconnected set of electronic information resources under the same direct management control that shares common functionality, and would include hardware, software, electronic media, and information.
- Modifying: Information Systems: Modifies the definition of ‘‘information system,’’ to clarify that an information system ‘‘generally’’, not just ‘‘normally,’’ includes hardware, software, data, communications, and people as it more accurately reflects the typical components of an information system and the full extent of resources that are addressed by the Security Rule.
- Modifying: Malicious Software: Expands the current limited definition of “virus” to mean software or firmware intended to perform an unauthorized action or activity that will have adverse impact on an electronic information system and/or the confidentiality, integrity, or availability of electronic protected health information
- Adding: Multi-factor authentication: Defines specific levels of authentication for accessing relevant electronic information systems with three categories (1) information known by the user, including but not limited to a password or personal identification number (PIN) (2) item possessed by the user, including but not limited to a token or a smart identification card, and (3) personal characteristic of the user, including but not limited to fingerprint, facial recognition, gait, typing cadence, or other biometric or behavioral characteristics.
- Clarifying: Password: Further clarifies what constitutes a character, and adds ‘‘such as letters, numbers, spaces, and other symbols’’ to the existing definition.
- Clarifying: Physical Safeguards: Clarifies that the policies and procedures referred to in the definition are those that specifically are related to physical measures, and to replace ‘‘buildings’’ with ‘‘facilities’’. Clarifies that it has always intended that the physical safeguards apply to any location where a regulated entity might possess ePHI.
- Adding: Relevant Electronic Information System: Defines an electronic information system as one that creates, receives, maintains, or transmits ePHI or that otherwise affects the confidentiality, integrity, or availability of ePHI.
- Adding: Risk: Defines ‘‘risk’’ as the extent to which the confidentiality, integrity, or availability of ePHI is threatened by a potential circumstance or event.
- Clarifying: Security or Security Measures and Security Incident: States that Security Measures may not only be part of an information system, but may include measures applied to them and defines two types of security incidents: (1) affecting the protected information, (2) affecting the operations of the systems themselves
- Adding: Technical Controls: Defines technical controls as technical mechanisms contained in the hardware, software, or firmware components of an electronic information system that are primarily implemented and executed by the electronic information system to protect it and the data within the electronic information system.
- Modifying and Adding: Technical Safeguards: Modifies the definition of ‘‘technical safeguards’’ to expressly include ‘‘technical controls.’’ Adds language that would clarify that the technology, technical controls, and related policies and procedures in this category govern the use of the technology to protect and control access to ePHI.
- Adding: Technology Asset: Distinguishes between the requirements that apply specifically to each component of an electronic information system and those that apply to the electronic information system as a whole. Defines the term ‘‘technology asset’’ to mean the components of an electronic information system, including but not limited to hardware, software, electronic media, information, and data, and clarifies that Security Rule requirements apply to all the components of electronic information systems,
- Adding: Threat: Defines as any circumstance or event with the potential to adversely affect the confidentiality, integrity, or availability of ePHI (derived from NIST, modified for healthcare).
- Clarifying: User: (Technical correction) Clarifies the definition of ‘‘User’’ by removing the reference to an entity. Because the definition of ‘‘person’’ includes an entity, including entity in the definition of ‘‘user’’ is redundant and could cause confusion.
- Adding: Vulnerability: Adopts substantially the same definition as NIST – a ‘‘weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source” with minor modifications relevant to healthcare.
- Clarifying: Workstations: Clarifies that this term includes all types of endpoints, including smart phones, tablets, and even personal digital assistants.
As mentioned above, in Part 2 of this blog, I will review the proposed new or updated standards and implementation specifications and provide commentary on what may happen next, and how to best prepare in the time being.