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. Part one focused on our overarching concerns and issues with proposed definitions. Part two focuses on several of the proposed standards.

Our analysis of proposed changes to the existing HIPAA Security Rule, released as HIPAA Security Rule to Strengthen the Cybersecurity of Electronic Protected Health Information, revealed a mixed bag of positive changes and areas of concern. In the first installment of this blog series, we noted the EHR Association’s appreciation for its enhancements to the cybersecurity baseline. However, we expressed concern about the resources and costs required for regulated entities to comply with the overhauled mandates. We also reviewed the feedback we shared with OCR on its proposed changes to key definitions.

In this installment, we highlight our concerns with several of OCR’s proposed expectations, drawing attention to the need for greater clarity and offering recommendations to ease compliance burdens while achieving intended outcomes. 

For starters, clarity is needed regarding expectations for risk assessments in the context of change management (Section 164.308(a)(3)(i)—Standard: Evaluation) 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 their security practices with compliance expectations.

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.

Further, while we support OCR’s distinction between the expectation to apply a patch versus developing one (Section 164.308(a)(4)(i)—Standard: Patch Management), we recommend aligning patching expectations with NIST timelines to ensure consistency with established cybersecurity frameworks. Providing clear guidance on reasonable timeframes for patch application that considers risk severity, vendor dependencies, and testing requirements would help regulated entities implement security updates while maintaining system stability.

Other areas requiring greater clarity include:

• Section 164.308(a)(5)(i)—Standard: Risk Management: The contradictory language around whether entities are expected to have already mitigated identified risks or to develop a mitigation plan creates uncertainty regarding compliance expectations. OCR must clarify whether risk management should be proactive, addressing risks immediately, or strategic, requiring a documented plan for future mitigation. This will help regulated entities align their security programs with the rule’s intent while ensuring practical and achievable implementation.
• Section 164.308(a)(7)(i)—Standard: 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. Not all system events are security events. Organizations should be able to tailor their response based on the nature and severity of observed anomalies. Clarity is also needed on how organizations can demonstrate compliance with this requirement during audits or inspections. Instead of focusing on rigid testing protocols, an annual review of the process’s efficacy would ensure organizations can update and improve monitoring procedures as threats and operational needs evolve.
• Section 164.308(a)(9)(i)—Standard: Workforce Security: Greater flexibility is needed in terms of workforce termination procedures, as the proposed one-hour requirement for revoking system access is impractical for routine departures. A better approach would require a clear policy and process for timely deactivation, emphasizing expedited termination when necessary. Notification requirements should be risk-based and consider the terminated employee’s specific access for proportionate action.
• Section 164.308(a)(12)(i)—Standard: Security Incident Procedures: While we support the general approach to security incident response procedures, it is essential to define what is considered a security incident to prevent unnecessary administrative burdens. For example, failed login attempts due to incorrect usernames or passwords and other routine occurrences should not be considered security incidents unless they indicate an actual attempted breach.
• Section 164.308(a)(13)(i)—Standard: 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 time frame when feasible while allowing exceptions when a guaranteed return to operations is not possible. 

In terms of Business Associate Agreements, specific examples of what is considered sufficient assurances are needed, such as ISO certifications, SOC 2 Type II reports, or similar industry-recognized security attestations (Section 164.308(b)(1) and (2)— Standard: Business Associate Contracts and Other Arrangements). Doing so would streamline compliance efforts and ensure consistent security expectations across the healthcare ecosystem.

Finally, clarification is needed on which components of Facility Access Controls require testing (Section 164.310(a)(1)—Standard: Facility Access Controls) to ensure security-relevant aspects are prioritized over administrative processes. By specifying key areas for testing, such as physical entry controls, authentication mechanisms, and emergency access procedures, organizations can implement targeted and meaningful security measures without incurring unnecessary administrative burdens.

Part three of this blog series focuses on the EHR Association’s reaction to the remaining proposed standards within the HIPAA Security Rule.