In its most recent Cybersecurity Newsletter, OCR focuses on the intersection of HIPAA and information security.  To be sure, HIPAA requires covered entities and business associates to address their organizations’ information security. This obligation stems from HIPAA’s requirement that covered entities and business associates assess the potential risks and vulnerabilities to the confidentiality, integrity and availability of their electronic protected health information. This is referred to as a “risk assessment” or “risk analysis” and is a core element of HIPAA’s Security Rule. But it is not enough to simply assess or analyze the risk; HIPAA requires that the risks be mitigated. This is particularly important when it comes to information security risk. As OCR states in its newsletter:

The scope of the risk analysis and risk management processes encompasses the potential risks and vulnerabilities to all ePHI that an organization creates, receives, maintains, or transmits. This includes identifying and mitigating risks and vulnerabilities that unpatched software poses to an organization’s ePHI.  Mitigation activities could include installing patches if patches are available and patching is reasonable and appropriate. In situations where patches are not available (e.g., obsolete or unsupported software) or testing or other concerns weigh against patching as a mitigation solution, entities should implement reasonable compensating controls to reduce the risk of identified vulnerabilities to a reasonable and appropriate level (e.g., restricting network access or disabling network services to reduce vulnerabilities that could be exploited via network access).   Security vulnerabilities may be present in many types of software including databases, electronic health records (EHRs), operating systems, email, applets such as Java and Adobe Flash, and device firmware.

A helpful resource for tracking these issues is the United States Computer Emergency Readiness Team (US-CERT), which collects and publishes information on cybersecurity threats for stakeholders in the public and private sectors. Readers can sign up for US-CERT emails that contain alerts, tips and other updates by using the link above.

OCR’s newsletter also discusses software patching at length. OCR recognizes that patches can have unintended consequences, especially when dealing with highly interconnected systems or those that contain legacy (i.e., no longer supported) software. To deal with these and other nuances, OCR recommends that the following steps be included in an effective patch management strategy:

• Evaluation: Evaluate patches to determine if they apply to your software/systems.
• Patch Testing: When possible, test patches on an isolated system to determine if there are any unforeseen or unwanted side effects, such as applications not functioning properly or system instability.
• Approval: Once patches have been evaluated and tested, approve them for deployment.
• Deployment: Following approval, patches can be scheduled to be installed on live or production systems.
• Verification and Testing: After deploying the patches, continue to test and audit systems to ensure that the patches were applied correctly and that there are no unforeseen side effects.

OCR ends its newsletter on an important practical consideration related to patching and other system modifications: activities like patching, and the modifications that are sometimes necessary to apply patching, may themselves necessitate a reevaluation of the risk assessment. This point helps to underscore that compliance with HIPAA’s Security Rule is an evolving process that does not end after an entity’s initial risk assessment.