By the EHR Association Privacy & Security Workgroup

This three-part blog series shares the EHR Association’s stance on OCR’s proposed changes to the HIPAA Security Rule to Strengthen the Cybersecurity of Electronic Protected Health Information. Part one is focused on our overarching concerns and issues with proposed definitions.

Proposed changes to the existing HIPAA Security Rule, released as HIPAA Security Rule to Strengthen the Cybersecurity of Electronic Protected Health Information, include some long-overdue updates. However, the resources and costs required by healthcare provider organizations, health IT developers, and other regulated entities to comply with the sweeping changes will be too great for many to bear.

That was one of several important messages we shared with the HHS Office of Civil Rights (OCR) in our comment letter on the proposed rule. 

The Association has long advocated for enhanced protection of sensitive health data, something many of the updates within the proposed rule would accomplish by enhancing the cybersecurity baseline. Additionally, healthcare ecosystem stakeholders will appreciate the clarity and specificity of whichever requirements are ultimately finalized. However, it will be essential for finalized policies to remain flexible to avoid adding excessive or unmanageable burdens for smaller organizations with limited resources available to manage compliance. 

When the OCR estimated the costs that regulated entities and plan sponsors can expect to incur in the first year of implementing the proposed regulatory changes, it dramatically underestimated the substantial time and cost required for EHR vendors to develop and implement the necessary technology to enable these functionalities.

One of our most significant concerns with the proposed rule is the cost of compliance. When the OCR estimated the costs that regulated entities and plan sponsors can expect to incur in the first year of implementing the proposed regulatory changes, it dramatically underestimated the substantial time and cost required for EHR vendors to develop and implement the necessary technology to enable these functionalities. Our analysis shows that this would require 12,572 hours, equivalent to more than 314 person-weeks, which is well over OCR’s estimate. This significant additional burden must be factored into expected compliance timelines and regulatory requirements to ensure EHR developers can effectively meet expectations without disrupting essential health IT services.

Definition Concerns and Recommendations

Along with costs, we shared several recommendations, concerns, and support for proposed changes to key definitions.

For example, we suggest modifying the definition of “information system” to acknowledge that both providers and EHR vendors have direct management control over the ePHI in a cloud-based EHR. We suggest that this and similar examples be clarified to reflect that EHR vendors may have direct management control, depending on the specific arrangements with their healthcare provider customers, but do not always. Doing so recognizes that while an EHR developer may manage certain aspects of the technology or environment, such as the data center, it likely does not control other elements, like the physical environment from which a clinic accesses the system. This would help ensure compliance expectations accurately reflect the division of responsibilities between vendors and providers.

Other recommendations around proposed definitions are:

• Adding a definition of “multi-factor authentication” (MFA) that aligns with National Institute of Standards and Technology (NIST) standards to ensure flexibility in authentication methods and enable regulated actors to implement state-of-the-art authentication methods as security threats evolve.
• Adding a definition of “relevant electronic information system” that achieves OCR’s intent to clarify compliance obligations while avoiding an unintentional expansion of the rule’s compliance scope by requiring an entire enterprise to comply if any part of the organization interacts with ePHI, even if only one line of business provides services to regulated entities. 
• Clarifying the definition of “security incident” to align with NIST standards to ensure consistency in cybersecurity incident response expectations across different contexts and to remove or clarify references to “attempted” breaches to avoid unnecessary reporting burdens for routine network activity, such as pings, which do not constitute meaningful security threats. 
• Adding/refining a definition of “technology asset” to ensure feasibility in its application throughout the rule by focusing on the system components themselves rather than what those components contain, ensuring that security measures align with real-world implementation practices.
• Adding a definition of “threat” that aligns with NIST standards to maintain consistent terminology across regulatory frameworks, thereby enhancing clarity, reducing confusion, and ensuring that healthcare entities can apply standardized risk management practices without needing to interpret multiple variations of the same concept.
• Clarifying the definition of “workstation” that aligns with the NIST definition of “endpoint” to ensure consistency across security frameworks and define servers separately or incorporate them within the broader definition of technology assets rather than workstations.

It is also unclear how the proposed definition of “workstation” would apply to non-managed devices that access or process ePHI, such as patient smartphones accessing a portal or personal devices used by clinicians. These devices raise distinct security considerations, particularly regarding physical safeguards and access controls, which may not be adequately addressed under the workstation definition. Therefore, we ask OCR to clarify how security requirements apply to personal and unmanaged devices while ensuring compliance expectations remain practical for regulated entities.

Part two and part three of this blog series focused on the EHR Association’s reaction to proposed standards within the HIPAA Security Rule.