With the rapid pace of technological change and surging cybersecurity threats, few would argue that modernizing the HIPAA Security Rule, which establishes national standards to protect individuals’ electronic protected health information (ePHI) by requiring safeguards to ensure its confidentiality, integrity, and security, is overdue. This was the goal of the US Department of Health and Human Services (HHS) Office of Civil Rights (OCR) with its release of the HIPAA Security Rule to Strengthen the Cybersecurity of Electronic Protected Health Information.
The proposed rule would strengthen ePHI protections by enhancing the cybersecurity baseline, an improvement that the Electronic Health Record (EHR) Association has long supported. However, while recognizing the need for modernization, there is concern that the resources and costs required to comply with the sweeping changes could overwhelm many healthcare organizations, health IT developers, and other regulated entities. Additionally, while the clarity and specificity within the proposed rules are appreciated, flexibility in the final iteration will be essential to avoid adding unmanageable mandates, particularly for smaller organizations with limited resources for managing compliance.
Those are high-level takeaways from our workgroup’s analysis of OCR’s proposed overhaul of the HIPAA Security Rule. At a more granular level, we identified several concerns we hope to see addressed before finalization, including the time and cost of compliance for EHR vendors to develop and implement the necessary technology to enable required functionality. When the OCR estimated the costs that regulated entities and plan sponsors could expect to incur in the first year of implementing the proposed regulatory changes, we calculated they underestimated the impact on technology developers by nearly 12,600 hours (more than 314 person-weeks). This more accurate analysis must be reconsidered as OCR considers final compliance requirements to ensure EHR developers have sufficient time to effectively meet expectations without disrupting essential health IT services.
Definition Concerns
Costs were just one area of concern that emerged from our analysis. OCR also proposed changes to several key definitions that merit a closer examination. For example, the proposed definition of “information system” overlooks the fact that both providers and vendors have direct management control over the ePHI in a cloud-based EHR. The definition should be revised to reflect that control depends upon specific arrangements between the vendor and their healthcare provider customers.
Acknowledging this variable 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 helps ensure that compliance expectations accurately reflect the division of responsibilities between vendors and providers.
Similarly, we recommend 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. As proposed, the definition would oblige an entire enterprise to comply even if only one line of business provides services to regulated entities or interacts with ePHI.
A definition of “technology asset” should also be added or refined to focus on the system components themselves rather than on what those components contain. This would ensure feasibility in its application throughout the rule and that security measures align with real-world implementation practices.
Several proposed definitions should be aligned with National Institute of Standards and Technology (NIST) standards in the final rule, including:
- Multi-factor authentication (MFA), to ensure flexibility in authentication methods and enable the implementation of state-of-the-art authentication methods as security threats evolve.
- Security incident, to ensure consistency in cybersecurity incident response expectations across different contexts. References to “attempted” breaches should also be removed or clarified to avoid the need to report routine network activity.
- Threat, to help maintain consistent terminology across regulatory frameworks, enhancing clarity, reducing confusion, and ensuring that healthcare entities can apply standardized risk management practices.
- Workstation, to enable servers to be defined separately or incorporated within the broader definition of technology assets, ensuring consistency across security frameworks.
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. This can be resolved by clarifying how security requirements apply to personal and unmanaged devices while ensuring compliance expectations remain practical for regulated entities.
Clarifying Expectations
Our analysis of the proposed changes to the HIPAA Security Rule also identified several expectations that would benefit from greater clarity or refinement to ease compliance requirements while achieving the intended outcomes.
Regarding expectations for risk assessments in the context of change management, clarity is needed to ensure organizations can effectively comply during inspections and audits. The proposed rule implies that risk management assessments should be conducted as part of system changes, suggesting that a formal change management process is expected. If so, OCR should clearly define what constitutes a required change, the scope of necessary assessments, and the level of documentation needed. Doing so would allow organizations to align security practices with compliance expectations.
Further, while we support OCR’s distinction between the expectation that a patch be applied versus developed, patching expectations should align with NIST timelines to ensure consistency with established cybersecurity frameworks. Additionally, providing clear guidance on reasonable timeframes that consider risk severity, vendor dependencies, and testing requirements would help regulated entities implement security updates while maintaining system stability.
Another concern is the uncertainty created by the contradictory language regarding whether entities are expected to have already mitigated identified risks or if they are to develop a mitigation plan. Clarifying whether risk management should be proactive (addressing risks immediately) or strategic (requiring a documented plan for future mitigation) would help organizations align their security programs with the rule’s intent while ensuring practical and achievable implementation.
Greater clarity and/or flexibility are also needed in the following sections:
- Information System Activity Review: A clear distinction is needed between security audit logs and general system logs, and expectations for their management and review must be clarified to allow tailored responses based on the nature and severity of observed anomalies. Instead of focusing on rigid testing protocols, an annual efficacy review would ensure organizations can update and improve monitoring procedures as threats and operational needs evolve.
- Workforce Security: The proposed one-hour requirement for revoking system access is impractical for routine departures. A better approach would be to establish a clear policy and process for timely deactivation, including risk-based notification requirements that take into account the terminated employee’s specific access.
- Security Incident Procedures: Defining what is considered a security incident is essential to prevent unnecessary administrative actions, such as the need to report routine occurrences such as failed login attempts due to incorrect usernames or passwords that should only be considered security incidents if an actual attempted breach is indicated.
- Contingency Plan: Rigid adherence to the proposed 72-hour contingency plan requirement is problematic as it may, in some cases, be beyond an entity’s control. Instead, the focus should be on taking reasonable steps to restore critical operations within that timeframe when feasible while allowing exceptions when a guaranteed return to operations is not possible.
For Business Associate Agreements, specific examples of what is considered sufficient assurances are needed within the final rule, e.g., ISO certifications, SOC 2 Type II reports, or similar industry-recognized security attestations. This would streamline compliance efforts and ensure consistent security expectations across the healthcare ecosystem.
Finally, clarification is needed from OCR on which components of Facility Access Controls require testing to ensure security-relevant aspects are prioritized over administrative processes. Specifying key areas for testing, such as physical entry controls, authentication mechanisms, and emergency access procedures, would allow the implementation of targeted and meaningful security measures without incurring unnecessary administrative burdens.
Risk-Based and Industry-Aligned Recommendations
Several proposed expectations would benefit from a risk-based approach or closer alignment with industry standards. For example, encryption as a best practice for data at rest and in transit is good. However, hardware and performance implications must be considered to strike a balance between security and system efficiency. Clear guidance is also needed on what constitutes acceptable encryption levels within a system to avoid unnecessary hardware expenditures or performance costs.
The distinction between “testing” and “auditing” in the Configuration Management requirements also needs clarifying. Testing evaluates the effectiveness of technical controls, while auditing ensures they are appropriately implemented and maintained. Aligning regulatory expectations with industry best practices would help healthcare provider organizations and other regulated entities ensure effective security management without imposing unnecessary operational requirements.
Other sections that would benefit from greater clarity or industry alignment are:
● Audit Trail and System Log Controls: A risk-based approach to audit trail and system log control requirements focused on systems impacting safety and clinical decision-making would reduce unnecessary operational and financial burdens, which OCR should also consider when establishing compliance timelines.
● Multi-Factor Authentication: The burden MFA can place on end-users should be considered along with related cost implications. Rather than a blanket MFA requirement, organizations should be required to document their risk analysis and implement MFA wherever it provides significant security benefits, ensuring both security and operational feasibility.
● Vulnerability Management: Expectations for vulnerability management, patching, and penetration testing should align with NIST and other industry standards to ensure consistency and feasibility for regulated entities.
A unified “technical control testing” framework that consolidates testing requirements across the Security Rule should also be considered. Penetration testing can be a comprehensive evaluation that incorporates elements of vulnerability management, system monitoring, and patch management. This strategy could reduce redundancy while still ensuring robust security assessments. Further, a risk-based approach tailored to system criticality would enhance security without imposing excessive costs or resource demands.
A risk-based approach is also recommended for backup and recovery practices, enabling flexibility based on system criticality and the role of different entities in managing ePHI. The proposed 48-hour data retrieval requirement should consider varying use cases, and expectations should differ based on system criticality and whether an entity is a Covered Entity or Business Associate. This would help ensure compliance efforts align with actual operational and patient care needs.
Finally, while real-time monitoring and monthly restoration testing are good practices, organizations should be allowed flexibility in how backup integrity is validated based on risk assessments. Alternative approaches should be permitted to ensure recoverability without imposing unnecessary efforts, particularly for downstream systems that do not require continuous availability. A flexible, risk-based approach would best provide reliable data recovery while balancing resource constraints and technical feasibility.
A Needed Overhaul
It has been 20 years since the HIPAA Security Rule was first implemented and 12 years since it was last updated. In that time, the risk environment has expanded dramatically as technology has advanced and become more deeply embedded in nearly every facet of health care.
Few question the need for a sweeping overhaul of the only regulations governing healthcare security. However, a risk-based approach with clear definitions and achievable timeframes is necessary to achieve regulatory intent without creating unnecessary financial or administrative requirements.
