The Office of the National Coordinator for Health Information Technology (ONC) released a Security Risk Assessment Tool (SRA Tool) on March 28. According to the User Guide for the SRA Tool (available here), the Tool is designed to help small and medium-sized healthcare practices “evaluate risks, vulnerabilities, and adherence to the HIPAA Security Rule.” User Guide, 1. ONC defines small and medium-sized practices as those including 1-10 healthcare providers. Id. The SRA Tool can be downloaded from the HealthIT.gov website here. ONC asks that users submit comments here by June 2 to help improve the Tool.
The SRA Tool is impressive in many ways. It downloads quickly, includes information about each Security Rule requirement it evaluates, provides useful definitions of key words and phrases, stores and retrieves information quickly, and produces reports that can be exported in.pdf and Excel formats. The challenges of developing well-working software should not be minimized. (Consider the initial rollout of the healthcare.gov website). ONC should be recognized for building a well-functioning tool.
The User Guide for the Tool notes that a provision of the HIPAA Security Rule, 45 CFR 164.308(a)(1)(ii)(A), requires covered entities and business associates to conduct risk assessments of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information. User Guide, 2. The Guide states that the purpose of the SRA Tool is to support the risk assessment process. Id.
The Guide cautions, however, that using the Tool does not guarantee compliance with the Security Rule and that “[s]tatements of compliance are the responsibility of the covered entity and the HIPAA Security Rule regulatory and enforcement authority.” Id.
The HHS Office for Civil Rights’ recent HIPAA enforcement actions show that it intends to enforce the risk assessment requirement: OCR’s settlements in several recent matters include references to covered entities’ failure to conduct risk assessments and the settlement amounts imposed by OCR presumably take into account potential fines that the agency could have imposed for the entities’ failure to perform risk assessments. See, e.g., Adult and Pediatric Dermatology (Dec. 24, 2013); Affinity Health Plan (Aug. 7, 2013); Idaho State University (May 13, 2013); Hospice of Northern Idaho (Dec. 31, 2012); and Massachusetts Eye and Ear Infirmary (Sept. 17, 2012). If small and midsized healthcare practices use the Tool in good faith and document their use of the Tool, they should be able to demonstrate they complied with the risk assessment requirement.
The ONC suggests that covered entities will need to do more to meet all their responsibilities under the Security Rule than simply to complete reports using the Tool. For example, if the Tool shows that a healthcare practice has not complied with a Security Rule requirement, the practice must take steps to correct that non-compliance. If the healthcare practice fails to do so and OCR has reason to investigate the healthcare practice, perhaps in response to a patient complaint following a data breach, reports generated by the Tool could be used to show the practice knowingly failed to address noncompliance with a Security Rule requirement. Although the Tool cannot help a covered entity comply with all HIPAA Security (or Privacy) Rule requirements, it provides a user-friendly mechanism to conduct a form of a HIPAA Security Rule risk assessment.
The risk-rating features of the SRA Tool, however, need to be improved. The Tool allows users to rate as “Low,” “Medium”, or “High” the “Likelihood of harm” and the “Impact of harm” related to each Security Rule requirement the Tool evaluates. Yet the Tool offers incomplete guidance regarding why the risks associated with each requirement should fall into the “Low” category as opposed to the “Medium” or “High” category. Users are left to guess whether failing to comply with a requirement would have a low, medium, or high likelihood of affecting the confidentiality, integrity, or availability ePHI, and whether the impact of such an effect would be “Low,” “Medium,” or “High.”
For example, SRA Tool question T34 asks:
§164.312(d) – Required
Does your practice have policies and procedures for verification of a person or entity seeking access to ePHI is the one claimed?
Yes ? No ? Flag ?
The “Threats and Vulnerabilities” information included for this question states:
Some potential impacts include:
• Human threats, such as an unauthorized user, can vandalize or compromise the confidentiality, availability, and integrity of ePHI.
• Unauthorized disclosure (including disclosure through theft and loss) of ePHI can lead to identity theft.
This information does not identify recognized threats, such as “An employee or contractor without authorization to access ePHI may access and copy confidential information, such as patients’ insurance or payment information, and use the information to commit insurance fraud or to make fraudulent charges on patients’ accounts.”
Threat-based risk assessments, such as those described in NIST SP 800-30, include a step that requires users to determine which threats are most likely to impact the business and which threats would be most harmful to the business. Such threat-based assessments help users prioritize remediation efforts. Resources to counter threats (and risks) to ePHI are limited, of course, especially for small and medium-sized healthcare entities such as those that ONC intends to use the Tool. If the SRA Tool gave more guidance about how to rate the likelihood and impacts of harm, e.g., by explaining the threats and impacts each Security Rule provision is intended to address, the risk ratings would better serve their purpose. Although the Tool currently allows users to generate colorful charts showing the number and relative amounts of “Low,” “Medium,” and “High” risks, the lack of guidance in the Tool regarding how to apply the ratings will cause the charts to have little meaning.
The SRA Tool does not enable a threat-based approach and instead suggests that an entity must focus equally on all of the Security Rule requirements identified in the Tool. The text reports generated by the Tool, which are stated in the sequence of Security Rule requirements, reinforce this suggestion by listing whether the entity is in compliance with the listed Security Rule requirements rather than showing which real-world threats to ePHI are most likely to cause harm to the entity and its patients.
In short, the current version of the SRA Tool will provide an efficient way for small and medium-sized healthcare practices to gauge their compliance with the Security Rule requirements included in the Tool. The risk-rating features of the Tool should be improved by identifying threats to ePHI to help entities prioritize their remediation efforts.
Healthcare entities and other businesses that plan to conduct information security risk assessments should consult their information technology managers, information security officers, and the heads of the business units that process and store sensitive data. These individuals should know where confidential data is stored and where it is most vulnerable. The company’s general counsel should also be included in planning the assessment. A lawyer who is a Certified Information System Security Professional (CISSP) can be a valuable member of the team to guide the assessment, to retain technical consultants to perform penetration tests and vulnerability scans, to provide confidential legal advice regarding potential liability related to assessment findings, and to help plan security improvements needed to address any gaps identified in an assessment.