Content Detail

• Content META

  Title	HIPAA Security Rule Resolves To Hit the Gym and Bulk Up prev next
  ID	5755631
  External ID	7452947974
  Author	Unknown
  Published Date	Jan. 9, 2025, 9:57 a.m.
  Summary	HHS proposes overhaul of security rule with additional details and requirements, but the incoming Trump Administration will decide whether this new year's resolution sticks For more than 20 years, th
  Tags	None
  URL	https://www.lexology.com/library/detail.aspx?g=3cf33c7e-ccfd-4b21-be99-b90adc844262
  Sentiment	Negative: 0.05122    Neutral: 0.82808    Positive: 0.12070
  Relevance	0.00418

• Content Details

  Content ID	3479854
  Key	7b430802-4f48-4011-abc1-913d9f679a87
  Content	HHS proposes overhaul of security rule with additional details and requirements, but the incoming Trump Administration will decide whether this new year's resolution sticks For more than 20 years, the HIPAA Security Rule has been virtually unchanged other than extending its scope beyond covered entities to also include business associates. During that time, technology has changed, cybersecurity threats against the healthcare sector have increased exponentially, and the U.S. Department of Health and Human Services Office for Civil Rights (OCR) has gained significant experience with enforcing the rule. To start off the new year, OCR has issued proposed changes to the Security Rule, adding more detailed requirements for controls, increasing requirements to regularly review and update procedures and mechanisms, and doing away with the concept of "addressable" implementation specifications. The proposed rule fails to address certain longstanding problems with the Security Rule and may go too far in requiring encryption of electronic protected health information (ePHI) in practically all instances. Covered entities and business associates (Regulated Entities) should familiarize themselves with the new requirements, consider submitting comments (either directly or through associations) in support or opposition of new requirements, and begin preparing for potential implementation of many of the proposed changes. Comment Period and Likely Future of the Proposed Changes On January 6, 2025, OCR published a Notice of Proposed Rulemaking (NPRM) to strengthen the protections for ePHI in the Security Rule. Comments are due by March 7, 2025. If finalized, Regulated Entities would have 240 days to come into compliance with the final rule (60 days until it becomes effective and an additional 180 days to come into compliance). Regulated Entities would have until a year after the effective date of the final rule (a year plus 60 days) to update business associate agreements. With the change in administration, a big question is whether the Trump Administration is likely to finalize the NPRM in the foreseeable future. Although we expect that the Trump administration will not finalize most Biden Administration proposals, this NPRM may be an exception. There historically has been bipartisan consensus for the need for improved healthcare information security, and the prior Trump Administration's enforcement of the Security Rule generally was consistent with that of prior Democratic (and Republican) administrations. Accordingly, while the Trump Administration generally is focused on decreased regulation, it may be willing to proceed with finalizing this NPRM. An Increased Level of Detail Historically, one of the Security Rule's biggest strengths was also its biggest weakness. The Security Rule is technology-neutral, describing categories of administrative, physical, and technical controls that a Regulated Entity must address, but without any detail regarding how to implement these controls. For example, although the Security Rule requires authentication procedures, it does not specify what level of authentication (e.g., multifactor authentication versus only password-based authentication) a Regulated Entity must employ. The strength of this high-level approach is that it has allowed the Security Rule to withstand the test of time, since it did not mandate particular technologies that have since become outdated. A primary weakness with the approach, however, has been a lack of clarity, especially for less sophisticated Regulated Entities, as to what measures constitute HIPAA compliance. For example, Regulated Entities often did not employ certain security measures, such as multifactor authentication, because the Security Rule did not unambiguously require them. The current Security Rule's high-level and flexible approach likely has made it more difficult for OCR to enforce. For example, OCR often cannot point to an unequivocal regulatory violation, but rather has to demonstrate that the Regulated Entity's measures were unreasonable notwithstanding the flexibility that is afforded them in the rule. In response to these issues, the NPRM proposes considerably more detailed requirements, including: A written inventory of technology assets, including identification, version, person accountable, and location; A network map illustrating the movement of ePHI throughout the Regulated Entity's electronic information systems; Specific required elements for a Regulated Entity's "accurate and thorough" risk analysis, consistent with requirements set forth in past OCR guidance Patch management, including a requirement to patch, update, or upgrade configurations to address a critical risk within 15 calendar days and a high risk within 30 calendar days; Termination of a workforce member's access to ePHI no later than one hour after the end of employment (or other arrangement for non-employed workforce members); Notification of another Regulated Entity within 24 hours of a change or termination of access where the workforce member is or was authorized to access ePHI or relevant electronic information systems at the other Regulated Entity; Establishment and implementation of network segmentation that can deny or impede an intruder's lateral movement; Training of new workforce members on security requirements within 30 days of granting access to relevant electronic information systems; A security incident response plan; Verification that a business associate has deployed technical safeguards in accordance with the Security Rule by obtaining a written verification at least every 12 months, including both: (1) a written analysis by a person with appropriate cybersecurity knowledge and experience, and (2) a written certification that the analysis has been performed and is accurate; Controls to disable or suspend a user's or technology asset's access to relevant electronic information systems after a reasonable and appropriate predetermined number of unsuccessful authentication attempts; Technical controls for configuration management of relevant electronic information systems, including workstations; Anti-malware protection, removal of extraneous software, and disabling of network ports in accordance with the Regulated Entity's risk analysis; Technology assets and/or technical controls that monitor all activity in relevant electronic information systems in real time, identify indications of unauthorized activity, and alert workforce members of such indications; Multifactor authentication (with certain limited exceptions related to FDA-regulated technology or legacy systems), including for any action that would change a user's privileges, and technical controls that require users to adopt unique passwords that are consistent with the current recommendations of authoritative sources; Automated vulnerability scans at least every six months and penetration testing by a qualified person at least every 12 months; ePHI backups with a recovery point objective of no more than 48 hours (meaning data must be backed up at least every 48 hours), recovery time objective of 72 hours for critical relevant electronic information systems (meaning restoration of systems within that time period), and monthly testing of ePHI backup and restoration; Technical controls to create and maintain backups of relevant electronic information systems (in contrast to ePHI-level backup and recovery) and testing of the effectiveness of such controls at least every six months; and Business associate agreements and plan documents that require a business associate or plan sponsor, respectively, to notify the covered entity of the activation of a contingency plan within 24 hours of activation. It Would No Longer Be Enough To "Implement" Policies and Procedures The current Security Rule requires Regulated Entities to implement a robust set of policies and procedures and to "implement mechanisms" to record and examine information system activities, encrypt ePHI, and check integrity of ePHI. In University of Texas M.D. Anderson Cancer Center v. HHS , however, the 5th Circuit held that a covered entity met its regulatory requirement with respect to encryption by putting encryption mechanisms in place, even if doing so did not necessarily result in the encryption of all ePHI. The court held that the Security Rule requires only a mechanism for encryption without regard to the effectiveness of such a mechanism: "[the covered entity] satisfied HHS's regulatory requirement, even if the Government now wishes it had written a different one." In response to the court's opinion, OCR is proposing that Regulated Entities now go further and "deploy" the Security Rule's required technical controls and safeguards and "ensure that [they are] in place, configured for use, and actually in use and operational throughout the regulated entity." Accordingly, even if a Regulated Entity has implemented a policy, procedure, or mechanism, it would be noncompliant if it fails to deploy the corresponding technical controls. Additionally, the current Security Rule does not include any specific time frames, other than the 6-year retention requirement for compliance documentation. For example, OCR regularly emphasizes the importance of periodically conducting a risk analysis, but the current regulatory requirement does not specify how often the risk analysis must occur (or even state that it must occur periodically). In the NPRM, OCR proposes to require Regulated Entities to perform a wide array of security tasks on at least an annual basis. The proposed revisions to the Security Rule use the term "every 12 months" 28 times. For example, every year a Regulated Entity would need to: Review and update its written inventory of technology and network map; Review, verify, and update its risk analysis and risk management plan; Review and test a number of policies and procedures, such as those governing patch management, sanctions, and media disposal and reuse; Provide security awareness training to all workforce members; Test its security incident response plan and document the results of the testing; Review and test contingency plans; Obtain written verification of implementation of technical controls from each business associate; and Perform and document an audit of compliance with the Security Rule. Encryption Is No Longer Addressable, But Additional Exceptions to Encryption Seem Necessary The Security Rule includes standards and implementation specifications. Under the current Security Rule, a number of implementation specifications are "addressable." This means that a Regulated Entity must implement the addressable implementation specification if it is reasonable and appropriate to do so. A Regulated Entity does not need to implement an addressable implementation specification, however, if it documents why it would not be reasonable and appropriate to do so and implements any reasonable and appropriate equivalent alternative measure. While the Security Rule includes a number of addressable implementation specifications, the ones that have garnered the most attention are the implementation specifications for encryption of ePHI at rest and in transit. Although OCR often has emphasized that "addressable" does not equal "optional," some have questioned whether the Security Rule should more broadly require encryption of all ePHI, especially as financial and operational costs of encryption have decreased since the rule was first published. In the NPRM, OCR proposes to eliminate the concept of "addressable" implementation specifications entirely. Instead, all implementation specifications would be required. For encryption, this means that Regulated Entities generally would be required to encrypt all ePHI at rest and in transit. The only exceptions would be: (1) if the technology asset does not support encryption of the ePHI and the Regulated Entity establishes and implements a written plan to migrate to a technology asset that does support encryption; (2) if an individual requests access to PHI in an unencrypted manner pursuant to the Privacy Rule's right of access and has been informed of the corresponding risks; (3) if encryption is unavailable in an emergency; or (4) if the technology is regulated by the FDA and certain conditions apply. The proposed broader encryption requirement raises a number of questions. For example, the proposed changes seemingly prohibit the sending of appointment reminders via text message or unencrypted email. The NPRM does not even make an allowance for such communications at the patient's request (since an individual's preference for how the covered entity communicates PHI is distinct from the Privacy Rule's right-of-access provision). Prohibiting these unencrypted communications could have an adverse impact on patient care. Additionally, HHS broadly interprets the scope of PHI to include any information that identifies someone as a patient or plan member. A Regulated Entity arguably cannot even send a text message or unencrypted email indicating that a secure message is waiting, since the unencrypted notification arguably is itself PHI if it identifies the individual as a patient or plan member of the sending covered entity. There also is no exception for PHI that is not readily identifiable, such as a limited data set. Instead of requiring encryption of PHI in all instances, a better approach may be requiring encryption of PHI if certain categories of identifiers are present and the PHI includes certain content, such as certain direct identifiers and descriptions of a health condition, diagnosis, treatment, or information that could be used for purposes of identity theft. Unsuccessful Security Incidents Remain a Problem A longstanding problem with the Security Rule is that it defines "security incident" to include both "attempted or successful" incidents. In other words, a failed attempt that is successfully stopped by the Regulated Entity still qualifies as a "security incident." Historically, the biggest problem with this broad definition has been that a business associate agreement must require the business associate to report "any security incident." This arguably results in a reporting requirement that may be infeasible for the business associate and of little (or no) value to the covered entity. Instead of revising the definition of "security incident" to remove unsuccessful attempts, the NPRM compounds the problem by creating additional requirements for security incidents. For example, HHS proposes that a Regulated Entity must "eradicate the security incidents that are suspected or known." It is unclear how a Regulated Entity can eradicate all known unsuccessful attempts, such as every ping on a Regulated Entity's firewall. Additionally, unsuccessful attempts are not necessarily bad and something that should be eradicated, but rather may demonstrate the strength of the Regulated Entity's safeguards. NPRM Fails To Reflect a Shared Security Model The NPRM also continues to require each Regulated Entity to separately implement each standard and implementation specification. This can be problematic in a cloud computing environment, where compliance may be a shared responsibility. For example, OCR previously issued guidance stating that "in cases where a [cloud services provider (CSP)] is providing only no-view services to a covered entity (or business associate) customer, certain Security Rule requirements that apply to the ePHI maintained by the CSP may be satisfied for both parties through the actions of one of the parties." The current Security Rule and the NPRM both fail to recognize this shared security model, instead indicating that each Regulated Entity must independently implement each Security Rule obligation. Not only does the NPRM fail to recognize a shared security model, but it worsens the problem by requiring a business associate to provide written verification that it has implemented all technical controls. This is inconsistent with the shared security model and past OCR guidance, which recognize that it may fall to a customer to implement certain technical controls. For example, a CSP may offer encryption functionalities, but may rely on the customer to turn on encryption and encrypt the ePHI that it stores on the CSP's servers. Any final rule may benefit from OCR specifically addressing the shared security model and recognizing that a business associate is not responsible for technical controls that are under its customer's control. Opportunity for Comment Organizations have until March 7, 2025, to submit comments to OCR regarding the NPRM. Organizations may wish to comment on: Whether any of the newly proposed requirements may prove infeasible or overly burdensome; Whether it will be feasible for every organization to review their policies and procedures, risk analyses, and risk management plans, and to test numerous categories of procedures and mechanisms, on an annual basis; Whether the annual requirement for covered entities to receive written verifications from all of their business associates will be particularly burdensome; Whether additional exceptions are needed for encryption requirements; Whether the definition of "security incident" should be amended to remove unsuccessful attempts; and Whether the Security Rule should explicitly permit a shared security model where responsibility for implementing technical controls is shared between Regulated Entities. Additionally, OCR has requested comment on particular questions at the end of many sections.
  Content Reference URL	None

• Publisher

  Publisher Name	Lexology (#2656)
  Publisher URL	https://www.lexology.com/
  Description	None
  Trust Flow Score	30
  Citation Flow Score	48

• Data Source

  Data Source Name	Quantexa News (#5)
  Data Source Type	news
  Data Source URL	https://app.aylien.com/dashboard
  Description	Welcome to Quantexa News API — the most powerful way to aggregate, filter, and integrate global news data into your apps and models.
  Weight	10