To fulfill the base measure requirements for the Promoting Interoperability category, MIPS-eligible clinicians must complete an annual Security Risk Analysis (SRA). Simply submitting “yes” when reporting may make this measure appear easy, but healthcare organizations should be prepared to provide sufficient evidence of analysis in case of an audit.
An SRA is not only good business practice, but it is also required by the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Security Rule. Many organizations have questions about completing an SRA as the requirements can seem vague. CMS is aware that all organizations are different sizes and have unique resources and operations; therefore, there is not one specific template.
An SRA should review all areas of an organization that receive, transmit, or store electronic protected health information (ePHI). This includes many different aspects of an organization other than just the electronic health record. When completing an SRA, an organization should consider administrative, physical, and technical safeguards. The goal of all safeguards is to protect the confidentiality, integrity, and accessibility of ePHI.
Administrative safeguards make up 50 percent or more of the security rule.
HIPAA defines administrative safeguards as “administrative actions, and policies and procedures, to manage the selection, development, implementation, and maintenance of security measures to protect electronic protected health information and to manage the conduct of the covered entity’s workforce in relation to the protection of that information.”
Examples of administrative safeguards include:
• Assigning security responsibility to a security officer
• Providing ongoing security training for staff
• Periodically reviewing information system activity
• Documenting security incidents based on a written policy
Physical safeguards are often overlooked as they may seem obvious to an organization, but they require a thorough analysis as well. HIPAA defines physical safeguards as “physical measures, policies, and procedures to protect a covered entity’s electronic information systems and related buildings and equipment, from natural and environmental hazards, and unauthorized intrusion.”
Examples of physical safeguards include:
• Implementing log-off procedures
• Protecting workstations from the view of unauthorized users
• Ensuring there are policies for the disposal and reuse of hardware and electronic media
• Completing an inventory of all physical systems, devices, and media
As technology advances in the healthcare industry, technical safeguards are becoming more and more important. HIPAA defines technical safeguards as “the technology and the policy and procedures for its use that protect electronic protected health information and control access to it.” Examples of technical safeguards include:
• Requiring unique user identification
• Implementing mechanisms to authenticate ePHI and ensure it has not been altered
• Monitoring activity in information systems through audit control mechanisms
• Ensuring there are policies for encrypting ePHI when deemed appropriate
In addition to analyzing safeguards, an organization must also identify potential threats and vulnerabilities that could affect the privacy and security of ePHI. Consider the following:
• Natural disasters, such as wildfires, damaging winds, floods, hurricanes, and tornados
• Man-made disasters, such as vandalism, hackers, theft, disgruntled employees, and accidents
• Infrastructure issues, such as a database crash, power outages, and building hazards
Organizations must determine the likelihood that each threat will occur and the impact that each threat could have on the confidentiality, integrity, and availability of ePHI. This process can be accomplished by giving each threat or vulnerability a rating of low, medium, or high. For example, a possible threat could be a breach going unreported due to the lack of established communication requirements with a third-party. For this threat, the organization must consider their contracts with third party vendors. Do their business agreements have language that describes the need to communicate relevant security changes? If the answer is yes, the likelihood of this threat would probably be low, but the impact of it actually happening could still be high.
Once an organization has documented the likelihood and impact of threats and vulnerabilities to their systems and programs, a risk score should be calculated for each. Then, the organization must decide how they will mitigate the risks. Will they internally mitigate the risk, outsource the risk, or accept the risk as doing business? Keep in mind that not all risks can be reduced to zero.
At a minimum, MIPS-eligible clinicians should be able to show a plan for correcting or mitigating deficiencies and provide evidence that steps are being taken to implement that plan. Any security updates that are identified should be included in the clinician’s risk management process and implemented as dictated by that process.
Remember, a security risk analysis is not a “one and done” activity; it is an ongoing process. An SRA should be updated as changes occur to an organization’s systems or policies. MIPS requires a unique analysis for every reporting period. Unique does not mean that a practice must start from scratch every year, but it is a good idea to review the completed SRA from the previous year and update it with new information.
Qsource and atom Alliance have a Security Risk Assessment that can be used to meet the measure as well as a set of example policies and procedures. These two tools cover all necessary aspects of the HIPAA rule. Reach out to the advisors at Qsource for more information on this topic and check out the links below.