In the wake of the COVID-19 pandemic, healthcare organizations have seen a large percentage of their workforce start working remotely while many providers have begun seeing patients remotely as well. This shift has created new threats and vulnerabilities that potentially can hinder an organization from fulfilling its mission during this critical time.
It is incumbent upon organizations to understand the risk(s) of these new working environments as they are changing. From a regulatory perspective, the HIPAA Security Rule maintains that a risk analysis must be performed as new systems and technologies are implemented, or there are any material environmental changes. The new systems and processes should be analyzed to ensure patient data is reasonably and appropriately protected and existing security measures are reasonable and appropriate to protect against the risks associated with evolving threats and vulnerabilities.
My goal is to help you understand how to perform a risk analysis that aligns with the nine essential elements outlined by the Office for Civil Rights (OCR).
Element One: Scope of the Analysis
When interpreting what OCR is expecting in a risk analysis, it must be inclusive of all systems and applications that create, receive, maintain, and/or transmit electronic protected health information (“ePHI”). For the purpose of this blog, the risk analysis will be based on a fictitious Virtual Meeting Platform (“VMP”) as an example system. There is an assumption that there are about 55,000 ePHI records within the system.
The risk analysis must also include all locations and/or lines of business within the organization. If the organization is an Integrated Delivery Network (“IDN”), there are likely numerous hospitals, imaging centers, post-acute centers, specialty practices, physician groups, and so on. Those entities have to be included in the risk analysis. Regardless of whether systems are completely centralized, there are generally varying location-specific physical controls that must be accounted for.
Regarding scope of analysis, when we record a VMP meeting, there are two basic options; you can either save the recording to your desktop or device, or you can save it into the VMP cloud, which ultimately is a server that is hosted and maintained by the VMP vendor.
Element Two: Data Collection
The next step in this process is to do data collection. Within data collection, it is not just about the systems and applications. Data collections must also include traditional IT Assets/Devices associated or that interconnect with in-scope system(s). If the VMP recording gets saved locally to a laptop, then the risk analysis must account for that device, as it now is going to have a recorded file that could potentially have ePHI on it. This trend is consistent with other types of devices that interconnect with all systems within the environment that is in scope for the risk analysis. Creating an inventory of relationships between the system(s) and device(s) is going to allow you to do a one-to-many relationship when understanding scope and data collection.
Element Three: Identify and Document Potential Threats and Vulnerabilities
One of the most difficult things organizations have to comply with is the requirement to understand an inventory and include reasonably anticipated threats and vulnerabilities. This generally requires having an inventory or a library of threats and vulnerabilities that are going to drive likelihood and impact when determining risk.
Clearwater’s IRM|Analysis™ software enables an automated, off-the-shelf library of millions of combinations/permutations of threats and vulnerabilities that are each going to have different types of associated impact(s) and likelihood(s). For example, a threat of a careless user is much different than that of a malicious user. Differing threats and vulnerabilities will likely yield various risks. That is the level of granularity that OCR expects.
Element Four: Assess Current Security Measures, e.g. NIST sp800-53 r.4
Once the reasonably anticipated threats and vulnerabilities have been identified, the risk analysis must account for what controls are in place. The vulnerability of endpoint data loss and theft, for example, has five standard controls associated with it:
If other compensating controls need to be considered for this vulnerability, they can easily be added to the risk analysis process using “custom controls”.
Element Five: Determine the Likelihood of Threat Occurrence(s)
Based on the methodology from NIST sp800-30, Risk is determined as a function of Likelihood and Impact. Going back to clinical laptops for telehealth that associate or tie to the VMP for Telehealth system, an example of a reasonably anticipated threat and vulnerability would be a malicious user (threat) who has the ability to improperly access, use, or destroy sensitive data (threat event), and create endpoint data loss (vulnerability). Likelihood is generally perceived as the probability of an adverse event occurring based on controls that are or are not in place.
Element Six: Determine the Potential Impact of Threat Occurrence
When determining impact, it is generally perceived as the magnitude of harm that could come if an adverse event were to occur, i.e. a threat exploiting a vulnerability. An example of an impact measurement, based on the above threat and vulnerability scenario, would be the fact that there is an estimated 55,000 records in the VMP system. The latest Ponemon Institute research indicates that the cost of a healthcare data breach is now $429 per record1 so the potential economic harm in this example could be severe.
Element Seven: Determine the Level of Risk
As mentioned above, Risk is determined by taking Likelihood x Impact.
The risk analysis discussed has accounted for only one risk scenario associated to the clinical laptops that are accessing VMP for Telehealth. There are several more to analyze, and in each case, calculate risk independent of each of the unique threat and vulnerability combinations that come into play. This will likely be reviewed as a part of a document request from OCR during investigations. OCR generally will ask for complete copies of any security risk analyses that have been performed to comply directly with 45 C.F.R. 164.308(a)(1)(ii)(A). They expect this level of granularity and direct alignment with the final guidance published back in 2010. Organizations that are using IRM|Analysis™ can quickly pull the “Risk Rating Detail Report” which has a 100% success rate when submitted to OCR during an investigation.
Element Eight: Finalize Documentation
Once the risk analysis has been completed, giving leadership visibility to the full risk register and publishing the risk register is crucial. Leadership needs to know where the organization is at most risk, and a risk management plan should be created to effectively demonstrate how the risks that pose the most significant threats to the organization can be mitigated and reduced according to precise and informed decision making.
Element Nine: Periodic Review and Updates to the Risk Analysis
Risk analysis should be an ongoing process as a part of the greater Risk Management Program. It should not be considered a once-a-year exercise, as you could do a risk analysis, get the final report, and then two weeks later, your organization introduces a new system into the clinical environment, and by the logic of “once and done” that new system will not be risk analyzed until the next risk analysis engagement. It’s vital that as new systems and technologies are introduced, through the procurement process, a thorough risk analysis is conducted as a normal course of Risk Management Operations.
It has been proven time and time again that if the risk analysis described above is submitted to OCR, it will continue to pass muster with OCR 100% of the time as it directly aligns with the nine requirements within OCR’s final guidance. The scope of analysis has been identified, all ePHI systems have been included as well as the traditional IT Assets with a holistic inventory of those systems and devices. The risk analysis has accounted for reasonably anticipated threats and vulnerabilities, identified the current security measures by understanding what controls are or are not in place. Risk has been determined by consistently taking Likelihood times Impact, there is a system and methodology in place that enables the finalizing of all documentation with periodic review and updates as the security environment continues to change.
To get an idea where your organization’s risk analysis efforts stand, I invite you to take the Clearwater HIPAA Security Risk Analysis Self-Review™. To learn more about IRM|Analysis™, join our next live demonstration of the software.
[1] https://healthitsecurity.com/news/data-breaches-cost-healthcare-6.5m-or-429-per-patient-record
