CHAPTER 26
Risk Assessment and Management
Gila Pyke
In this chapter, you will learn how to
• Participate in the process of reducing the risk of any healthcare IT product or implementation
• Identify the difference between security, privacy, and other healthcare risks
• Recognize different threats and associated mitigation strategies
Risk management is the art of enabling innovation and opportunities while preparing to manage potential negative outcomes. Risk management is not about eliminating risk (that is impossible) but instead identifying it, reducing it as much as possible, informing affected parties, and preparing to respond quickly and effectively should the risk materialize.
Healthcare technology is tasked with improving patient health outcomes and reducing certain types of healthcare risk. However, as with the introduction of any new system, the introduction of technology into the healthcare space introduces the potential for new risks that must be managed. A good example of this risk-benefit balance is the introduction of healthcare information systems that provide access to health information from laboratory tests, emergency response reports, hospital discharge summaries, and patient medical histories all in one place. The benefit that this can provide to patients is obvious, but the risk that unauthorized personnel may gain access to this information is also increased as more points of access to this information are introduced. When filing cabinets contain the health files, there is only one point from which the information can be accessed. But when you have a broadly shared healthcare information system, there are many points of access.
Fortunately, once healthcare IT risks are identified and assessed, they can also be managed and additional preventative and responsive safeguards can be implemented. In the case of risks involving unauthorized access, authentication and access controls can significantly reduce such risks and enable the technology to be used more safely.
Definitions
The National Institute of Standards and Technology (NIST) is the agency of the government that produces Guide for Conducting Risk Assessments: Information Security (NIST SP 800-30).1 The guide includes many terms relevant to risk assessment for information security that are included in this chapter. In order to better enable you to discuss risk management in healthcare, the following are definitions of some key terms:
• Asset An asset is something that needs to be protected from harm or loss. In healthcare IT security terms, an asset can refer to health information itself or devices containing health information. In healthcare privacy, safety, and other risk areas, assets consist of sensitive health information, patient safety, emotional or physical well-being, etc.
• Vulnerability A vulnerability is a weakness that leaves the asset unnecessarily exposed to harm inherent in the design or implementation of software. In healthcare IT terms, a vulnerability can be an unnecessary or insecure connection from a system hosting live healthcare data to the Internet, a lack of virus protection, or an unnecessary open port on a firewall.
• Threat A threat is a possible danger that might exploit a vulnerability and cause harm to an asset. A threat can originate from natural causes (power failures, floods, earthquakes, etc., resulting in health information being unavailable), intentional misuse or attack (e.g., spying on a Very Important Patient (VIP) patient’s files), or error (e.g., losing or misplacing valuable health information required for a patient’s treatment).
• Safeguard A safeguard is a measure taken to protect assets against threats. A safeguard, or security control, effectively reduces or eliminates a vulnerability. For example, virus scanners (safeguard) help protect our data (assets) from exposure to viruses (vulnerability) by unauthorized individuals who want to access or destroy our data (threats or threat agents).
• Risk2, 3 A risk is the likelihood that a threat will exploit a vulnerability and harm an asset, resulting in an impact on the organization or the patient.4 For example, if you are trying to protect an assault victim’s health record (asset) from being accessed by an individual with the intent to cause harm (threat), and that patient’s health record is accessible from a computer located in a public area that is often left logged in and does not require a password or any kind of credential to use (vulnerability), then there is a risk that an unauthorized individual may access that patient’s poorly protected health record and use it to cause harm to the patient.
In risk management, our goal is to reduce either the likelihood of the risk or its potential harm or impact. The likelihood of the risk just cited can be reduced by making it harder for the threat to access the records (by implementing safeguards such as moving the computer into an area restricted to staff only and providing staff with training that emphasizes the need to log out when they are not using the system). The impact of the risk cited can be reduced by removing the patient’s real name and using a pseudonym known only to authorized members of the care team to mask the patient’s identity. We will explore other ways to respond to risks later in this chapter.
Exercise 26-1: Identifying, Assessing, and Mitigating Risk
Identify the asset, vulnerability, threat, risk, and impact in the following healthcare scenario. Assign a likelihood value that this scenario may occur, and identify some potential safeguards that may help lower the likelihood or reduce the severity of the impact.
Scenario The surgical theatre in your local hospital relies on an allergy database to guide decisions on which anesthetic, medications, and other materials can be safely used on a patient during surgery. This database is also connected to the Internet for research purposes. A researcher unwittingly downloaded a virus, making the allergy database suddenly unavailable and resulting in a patient with allergies to opiates being administered morphine and suffering complications.
Risk Assessment
• Asset Allergy database
• Vulnerability Insufficiently protected Internet connection
• Threat Virus
• Risk Virus will be introduced to the system due to the insufficiently protected Internet connection and render the allergy database unavailable
• Likelihood Medium or high
• Impact Harm to patient health
Potential Mitigations
• Segregate database from research system, increase security of Internet connection (lowers likelihood)
• Install antivirus (lowers likelihood)
• Maintain paper backup of allergy data (reduces impact)
Risk Management in Healthcare IT
In healthcare IT, risk management is about assessing and reducing the risks along the spectrum of IT development—including healthcare device manufacturers, software developers, healthcare IT service providers, healthcare IT implementers, government organizations involved in healthcare, other third parties, healthcare providers, and—most importantly—patients.
Risk management in healthcare takes more lessons from the nuclear and aerospace industries than from the more traditional manufacturing or financial domains, in the sense that the ultimate impact of a risk in healthcare IT is the emotional or physical well-being of a patient. When risks can cost lives, the management of these risks becomes a priority component of healthcare IT development.
The Risk-Management Process2
The risk-management process is a cyclical, or spiral, process that begins with identification and assessment and returns there in order to ensure continual progress toward reducing the risks inherent in any development, implementation, or use of healthcare information technology.
At a high level, these are the steps of the risk-management process:
1. Identification of risks As we move through this chapter we will discuss various methods for identifying risks that may impact the security of an application, the privacy of a patient or provider, or ultimately the safety of a patient. The first step is always to identify all possible applicable risks, regardless of how likely they are. Risks will be prioritized during the assessment step.
2. Assessment of risks The risk-assessment step is the prioritization or triage step. This step takes into account the relative likelihood of a risk occurring, as well as the potential impacts of that risk, and assigns it a risk rating. A higher risk rating indicates a more serious risk that needs to be addressed first during the planning of mitigations. This prioritization is also a valuable tool for communicating with risk owners and stakeholders.
3. Mitigation planning Once priority risks are identified, the next step is planning ways to mitigate them (i.e., reduce their likelihood or probability of occurrence), or reduce the potential impact if the risk does occur.
4. Risk and mitigation tracking In order to ensure that mitigation plans are being implemented effectively, it is important to follow up with mitigation owners at predetermined intervals to provide support and ensure that mitigation plans will succeed.
5. Documentation Once the first round of risk assessment is complete, it should be documented in a report to be used to communicate to key internal and external stakeholders so that everyone is aware of how risks are being managed.
Using one or more of the methods described next for identifying risks is recommended for the initial cycle of risk identification, such as coupling a checklist with additional follow-up interviews of key stakeholders, or leveraging a standardized questionnaire with a follow-up brainstorming session with subject-matter experts. Once the initial list of risks has been identified, the risks need to be documented in a risk register. A risk register is a table used to document risks throughout the risk-management lifecycle, in support of each phase. Table 26-1 is an example of a risk register.2, 5 During the first identification phase of the risk-management lifecycle, only the leftmost columns of the risk register need to be completed.
Table 26-1 The Risk Register
NOTE Table 26-1 is available for download; see Appendix C.
For ongoing iterations of the risk-management lifecycle, risk identification should be based on the existing risk register. Questions such as “Have new risks been identified?” should be asked of key subject-matter experts and stakeholders, but conducting interviews or workshops will take less time. Often the checklists and questionnaires that are used are called “delta” or Δ assessments.
Risk Identification
The goal of the risk-identification step is to identify any and all possible risk scenarios that may adversely affect the project or solution. In order to identify risks, a project or system must be broken down into assets and scenarios so that vulnerabilities and threats can be identified.1 Depending on the type of risk—security, privacy, data criticality, or safety—there are a few different approaches to help identify a comprehensive list of potential risks:
• Creating checklists
• Using technology tools
• Using questionnaires
• Conducting interviews
• Holding workshops or brainstorming sessions
A checklist example is provided next since full coverage of all the approaches is beyond the scope of this chapter.
Checklist Example
When building a network to host healthcare applications, a list of required security controls (such as firewalls, encryption, authentication, and audit functionality) can be used to prompt risk identification. Creating a comprehensive map of the network and then verifying the checklist against each applicable path or node can create a list of gaps or vulnerabilities. Those vulnerabilities can then be combined with a checklist of the system’s assets and the potential threats to those assets to identify the security risks related to that system.
There are standardized security or safety checklists available, such as the Common Criteria Evaluation and Validation Scheme (CCEVS) produced by the National Information Assurance Partnership (NIAP).6 Organizations that routinely build or implement healthcare technology should leverage past risk assessments to build their own tailored risk-identification templates based on these and other standardized checklists.
Risk Assessment
Once a comprehensive list of risks has been identified, the next phase is to assess these risks and determine which risks must be prioritized for mitigation, which risks should be mitigated once the priority risks have been satisfactorily addressed, and which risks are sufficiently low that they can be accepted or removed from discussion. It is the responsibility of the healthcare provider to conduct the risk assessment by either utilizing staff on the healthcare IT security team or hiring consultants.
The triage of risks enables organizations to focus their resources on implementing safeguards where they are needed most. The risk-assessment process also enables subject-matter experts to communicate about priority risks with senior stakeholders using a common language of agreed-upon concepts.
Risk assessment is composed of three sequential activities:
1. Assignment of risk likelihood and impact values
2. Prioritization of risks based on assigned values
3. Reduction of risk values based on modifiers such as existing safeguards or risk detection
Assignment of Risk Likelihood and Impact Values
In order to determine the relative priority of risks, each risk is discussed in terms of two dimensions: likelihood and impact.
Risk Likelihood A risk’s likelihood is the probability that this risk will materialize in the foreseeable future. Likelihood can be measured based on quantitative statistics of past occurrence if these are available (e.g., the number of distributed denial-of-service—DDOS—attacks on a network per month, where a high number infers a high likelihood of DDOS attacks occurring in the future). If statistics are not available, then a qualitative value should be assigned.
In order to ensure that all participants in the risk-management exercise are speaking the same language, an agreed-upon likelihood table should be used to assign values. Since different projects, systems, and organizations have different risks and risk tolerances, a likelihood table should be customized to that organization. Table 26-2 is an example of a likelihood table.2, 5
Table 26-2 Example of a Likelihood Table
There are five levels of likelihood in this table. High, medium, and low are intended to be used regularly, whereas very high and very low are intended to demonstrate severe outlying events. Events such as “this happens all the time, it even happened today” would be listed as very high, and “this will probably never happen, but we wanted to document the risk anyway” would be listed as very low. An example of a very low risk could be the risk of flooding negatively impacting the availability of critical healthcare information. While the impact of such a risk is high and therefore should be considered, if the healthcare information is located in an area prone to drought that has never experienced flooding and is stored several stories above ground, then the relative likelihood of that risk would be considered very low.
TIP When the probability of occurrence is unknown due to insufficient data, a value of medium is assigned until further information is available.
Risk Impact The other dimension for discussing risks is the severity of the potential impact if that risk were to occur. As with likelihood, the scale for assessing level of impact should be customized to the organization assessing the risk and should be based on stakeholder and subject-matter-expert consensus. Where quantitative cost analysis is possible, impact should be measured in terms of cost because cost is the most measurable and widely understood impact type. Where quantitative data is not available, a qualitative value should be assigned. Often, several categories of qualitative impact are needed to be able to compare different types of risks. Table 26-3 is an example of the types of impact categories.2, 5
Table 26-3 Example of an Impact Table
In order to use a table like 26-3, where multiple categories or types of impacts are possible, the relative impact of the highest risk is the one that counts. For example, if the risk materializing may result in minor adverse attention from the media from the reputation category (which has an impact value of medium) but might also result in potential for serious injury in the safety category (which has an impact value of high), assign the risk a value of high.
TIP As with likelihood, if the potential impact of a risk cannot be estimated, a value of medium is assigned until further information is available.
Example of Assigning Risk Likelihood and Impact If the same risk of unauthorized access due to insufficient role-based access control is identified but there is no information yet available as to what information may be accessible, how this unauthorized access may affect a patient’s emotional or physical well-being, or whether it may affect the organization in terms of reputation or eventual financial cost, the impact category would be set to medium until more information is available about what data may be accessed without authorization and by whom. If, after further analysis, it is identified that the only information that can be accessed without login credentials is limited patient demographic information (i.e., name, age, and postal code) but no full address or health information, then the impact can be reduced to very low—without home-address or health information, there is likely very little cost or reputation impact for the provider or safety impact to the patient. It is important to note the impact category in the risk register or supporting documentation in order to support risk-assessment discussion with stakeholders.
If the risk of unauthorized access due to insufficient role-based access control is identified but there is no information as to the motivation or likely frequency for such unauthorized access, then the likelihood is assigned a medium value. Later, when this risk is discussed with stakeholders and other safeguards are identified that might prevent the occurrence of the risk (such as restricted issuance of login credentials to the system, reducing the availability of access to unauthorized staff), then the likelihood may be lowered. (Conversely, the likelihood value may also be raised should data supporting the likelihood of occurrence be brought forward.)
Prioritization of Risks Based on Assigned Values1, 2, 5
Once each risk has been assigned a likelihood and impact value, each risk is mapped into a visual risk matrix to establish the risk’s overall rating and relative priority. Figure 26-1 is an example of a risk map. In this example, the various risks are listed at the top of the map for ease of reading. They are then mapped using the likelihood and impact tables and placed in the appropriate box on the grid. The grid is divided into risk levels, with red indicating major priorities that must be addressed as soon as possible and where the majority of time and resources should be allocated. Orange is the next priority, then yellow, green, and so on.
Figure 26-1 Example of a risk map
NOTE Figure 26-1 is available for download; see Appendix C.
The risk-tolerance line indicates the risk tolerance agreed upon by the organization performing the risk assessment.1, 2 Risks that fall below the line can be accepted. Recovery plans may still be put in place, but further efforts to reduce the likelihood or impact of the risk are not prioritized. ISO/IEC 80001 (“Application of risk management for IT-networks incorporating medical devices”) describes this phenomenon in a different way.7 It states that the organization shall decide which of the following is most appropriate:
• The estimated risk is so low that risk reduction need not be pursued. In this case the rationale for this decision must be documented.
• The estimated risk is not acceptable. In this case risk-control measures, or in the language of this chapter, mitigations, shall be implemented.
Reduction of Risk Values Based on Existing Safeguards
Existing safeguards that reduce the potential likelihood or impact of a risk should be listed in the risk register, and the risk rating should be modified accordingly. In other words, if a healthcare information system has been designed with safeguards already in place, then the impacts or likelihoods of some risks inherent in the use of the system will be lower than upon initial assessment.
Once initial risk ratings are mapped, the next step is to identify which risks have safeguards already in place that may lower the initial risk rating. For example, for risk 1 in Figure 26-1, the likelihood of a DDOS attack on a discoverable system is high, and the impact of unavailable allergy information is very high—it can negatively impact the lives of many patients. Therefore, the initial risk rating of risk 1 is in the dark-shaded (maximum-priority) category.
Upon discussion with the security team, the following safeguards are identified as already in place:
• A well-configured firewall and intrusion-prevention system (IPS)
• An intrusion-detection system (IDS) that raises alarms if a DDOS attempt is detected
Once the safeguards have been documented in supporting documentation along with their effect on the risk rating, the readjusted likelihood and impact should be updated in the risk register along with the mitigating factors.
Risk-Mitigation Planning1, 2
There are four ways to respond to risk:
• Accept Weigh the cost of the risk versus the cost of mitigating it. Sometimes it is more prudent and effective to create a disaster-recovery plan or review audit logs regularly to identify an incident as quickly as possible than it is to try to mitigate the inevitable (or hard to avoid).
• Transfer Leverage insurance clauses, service-level agreements, and other contractual documentation to transfer the cost of recovery from a risk away from the organization. A prime example of this is liability insurance.
• Mitigate Buy antivirus software, provide awareness and training, optimize business processes, hire more people (so that staff can do their job properly without being overworked, which will reduce safety, privacy and security risks), write a profile, demand the use of encryption, or propose a controlled and well-documented activity that will reduce (not eliminate) the risk level to the point where it is either completely tolerable or at least tolerable enough that the focus of efforts can move to the mitigation of other priority risks. Formal signing of mitigation letters, or risk waivers in the case of risk acceptance, by risk owners can be an effective way of ensuring that senior stakeholders recognize risk mitigation commitments.
• Avoid Sometimes there is too much risk associated with something and no effective way to mitigate the risk, so we choose to do something else and avoid the risk altogether. This is often the least desirable or feasible action to take because it may result in losing the benefit of the avoided action as well (e.g., avoiding a risk by cancelling a project means that the benefits of the project are lost). In some cases of extreme risk, this may be the best approach: to scrap the plans and start over with a new design.
TIP For each risk in the risk register, identify which of these strategies will be employed, the details (such as developing a recovery or log-review plan, purchasing which kind of insurance, or implementing what kind of mitigation), who will own these risk management activities, and the deadline for when they must be implemented. This is necessary to enable risk tracking and reporting steps.
Risk-Mitigation Tracking
Once mitigation strategies have been agreed upon, assigned, and documented, the progress of mitigation plans must be tracked on a regular basis in order to identify issues or obstacles and provide support to risk owners to ensure that their risks will be mitigated. The frequency of tracking should be based on the risk rating—mitigation plans for extremely high risks should be followed up biweekly or monthly, whereas the progress of mitigating lower risks can be verified on a quarterly or even less frequent basis.
Documentation and Communication
There are two audiences for risk-management documentation:
• Internal stakeholders
• External stakeholders
Communicating About Risk with Internal Stakeholders1
Internal stakeholders (senior management, project owners, and internal clients) must be kept informed about risks on a periodic basis as part of established reporting mechanisms, such as quarterly risk reports to the board and weekly or monthly project meetings.
The risk register should be updated prior to each reporting cycle, including any new risks that have been identified along with their mitigations, changes to mitigation plans, updates on mitigation status, and residual risk ratings for mitigation plans that have been completed. This enables stakeholders from all levels of the organization to be kept appraised of their responsibilities as risk owners and also to provide support, such as additional resources for the mitigation of risks elsewhere within the organization.
Communicating About Risk with External Stakeholders
Communicating about risk with external stakeholders is part of the closeout phase of any project and part of ongoing maintenance of any healthcare IT system. Before a healthcare IT product can be sold to a healthcare provider, before an implementer can install the hardware and software at the healthcare provider’s site, and before the healthcare provider can begin using the product, risks must be managed along the entire spectrum—from software vendor to implementer to healthcare provider to patient.
In order for this to be possible, software and hardware vendors that are aware of residual risks in their products must clearly document and report these risks to the implementers who will install these products. Implementers who conduct risk assessments on the software or hardware implementation must document and communicate the residual risks to the healthcare providers, and the healthcare providers must in turn include these risks in their own risk identification, assessment, mitigation, tracking, and documentation activities. Risks that may ultimately affect patients must be managed along the continuum of the development of healthcare IT, from the initial conception of a software or hardware product to the daily use of that product for providing healthcare.
Domains of Risk Analysis
There are many domains of risk that may affect a healthcare IT system. The diagram in Figure 26-2 categorizes the threats associated with mitigation strategies into the following five domains: safety, security, privacy, application criticality, and data criticality.
Figure 26-2 Domains of risk
The risk-management cycle in each case follows the same steps. In many organizations a common risk register is used to document all categories or domains of risk, and common impact and likelihood tables are used to assess and prioritize them. The primary difference between these domains lies in the specific types of risks that are identified and minor deviations in the techniques used to identify them. In some cases, subject-matter experts who have a deeper knowledge of one domain (e.g., safety) versus another (privacy) are hired to conduct risk assessments.
Security Risk Analysis
Security risk analysis focuses on the triangle of security: confidentiality, integrity, and availability (CIA). All risks to healthcare IT assets are considered in terms of the confidentiality of the information contained in the assets, the integrity of the information contained in the assets, or the availability of the assets. Following are some examples of common security risks and their safeguards.
Threat: DOS or DDOS Attack
A denial-of-service (DOS) or distributed denial-of-service (DDOS) attack is an attempt to make a healthcare information system (asset) and the information hosted on it unavailable through flooding or overloading of the system.
Risk The hospital’s decision-support software may become unavailable as a result of a DOS/DDOS attack. This is an availability risk.
Mitigations
• Implementation and configuration of firewalls, switches, and routers
• Implementation of specific preventative hardware and software
• Antivirus software
• Code reviews
• Antispyware
• Security scanning (early detection)
Threat: Malware
Malware obtains its name from malicious software. This is a category of software that is purposely designed to cause damage to an information system such as a healthcare information system. Following are examples of malware:
• Viruses A virus is malicious software that can copy itself and infect a computer without the user knowing. In order for a virus to spread, the infected file must be sent to another computer or system and executed there. Viruses can corrupt computer files and make healthcare information unavailable when it is most needed.
• Worms A worm is malicious software that makes copies of itself using a network rather than being embedded in a file like a virus. Worms can also result in healthcare information becoming unavailable.
• Trojans A Trojan is named after the Trojan horse from Greek mythology and is malicious software that appears to do something desirable (such as download music files or play a video) but contains code hidden inside it that can open a backdoor and allow a malicious user to have unauthorized access to healthcare information. This is a risk to confidentiality rather than availability.
• Rootkits and backdoors Rootkits and backdoors are malicious software that can be installed without a user’s knowledge and provide access to a computer and the information on it to an unauthorized person. Rootkits and backdoors are a threat to confidentiality of healthcare information.
• Spyware Spyware is malware that collects information about a computer user, such as login and password information, without their knowledge and sends it to a third party who can use it to get unauthorized access to healthcare information. Like Trojans, rootkits, and backdoors, spyware poses a risk to the confidentiality of healthcare information.
Risk The patient files stored at the doctor’s office may be accessed (confidentiality risk) or modified (integrity) by unauthorized attackers, or the physician may lose access (availability) to critical health information that he or she needs to provide patient care.
Mitigations
• Educating users not to click on certain types of links or install certain types of software
• Restricting user accounts from being able to install software without the help of a technically savvy person
• Antivirus software
• Antispyware, or spyware removal, software
• Code reviews
• Regular security scans to detect rootkits and other malware as early as possible
Threat: Social Engineering
Social engineering is the act of manipulating people to provide confidential information or information that will permit an unauthorized person access to confidential information. In healthcare IT, social engineering could include posing as staff at a healthcare institution in order to gain access to a server room, impersonating an authorized user over the telephone, or various electronic means of posing as someone with a legitimate need for confidential information. A common example of social engineering is called phishing. With this technique the poser uses e-mail and a web page that appear to be legitimate to ask you to “verify your login information.” In fact, you are being redirected to a false page and the sender is using the information you provide to gain unauthorized access to healthcare information.
Risk Social engineering can pose a risk to the confidentiality, availability, and integrity of healthcare information.
Mitigations
• Educating users to recognize social engineering or phishing attempts.
• Effective disposal of electronic and paper media to reduce “dumpster diving.” Dumpster diving is a common technique used by attackers to gain information that they can use to make their social engineering attempt appear more legitimate.
Threat: Spam
E-mail spam, sometimes known as junk e-mail, involves thousands of e-mails sent to as many recipients as possible with the intention of selling, advertising, or phishing for information from unsuspecting users. Spam can also involve sending bulk messages over instant messaging, mobile texting, and other forms of electronic communication media.
Risk Spam can be used to transmit viruses, phishing scams, and other threats and can also result in reduced or no availability of networks and, as a result, healthcare information. In other words, spam can pose a risk to the confidentiality, integrity, and availability of healthcare information.
Mitigations
• Educating users not to sign on to untrusted sites with their e-mail addresses, how to recognize spam messages, and not to respond to them
• E-mail filtering
• Greylisting or blacklisting services
For more information on security-specific risk analysis, see NIST SP 800-30, Revision 1.
Application and Data Criticality Analysis
The purpose of application and data criticality analysis is to fulfill the HIPAA security regulation requiring healthcare organizations to have a disaster-recovery plan in place, as well as an emergency-operation plan if applications hosting critical healthcare information suddenly become unavailable. An application and data criticality analysis should identify
• Which software applications are critical to the provision of healthcare
• What data is critical to the provision of healthcare
Privacy Risk Analysis
In healthcare IT, privacy risk analysis encompasses more than the confidentiality of personal health information. It also includes
• Compliance with legislative and regulatory requirements, such as those laid out in HIPAA, and the financial or business impacts that noncompliance can have on a health organization.
• Adherence to privacy principles, such as those laid out in the OECD Privacy Principles:8
• Collection limitation Limiting how much healthcare information is collected and where it can be collected from. Consent must be given for the collection.
• Data quality Information collected and used should be relevant to the purposes for which it was collected and kept up to date.
• Purpose specification Communicating to patients why their information is being collected, when it will be used, and under what conditions it would be disclosed.
• Use limitation Limiting how and when data is disclosed and for what purposes the disclosure is being made.
• Security safeguards Security safeguards should be used to protect healthcare information.
• Openness Organizations should be open about their practices of using and protecting personal health information.
TIP Informing patients about what information is collected about them supports the principle of openness.
• Individual participation Patients should be informed about what information is collected about them, as well as with whom it will be shared, and have the ability to correct it if they can demonstrate that it is inaccurate.
• Accountability Healthcare providers should be held accountable for the protection of personal health information in their custody.
• Big data and de-identification Big data and statistical analysis is becoming more and more prevalent in the healthcare IT industry as organizations work to predict and prevent adverse outcomes based on the enormous amount of information generated by the electronic provision of healthcare services. In cases of family planning, mental health, or even broader acute care data, large collections of healthcare data may put individual patients at risk. In addition to privacy risk analysis and mitigation prior to, during, and at the end of the implementation of any big data project, de-identification is often considered to be a key mitigation for reducing the risk of identification of an individual from the data used for analysis.9
NOTE Privacy risk assessment should be conducted at the start, middle, and end of a project in order to support risk-based planning (Privacy by Design10), risk-based development, and risk-based implementation.
Safety Risk Assessment
While the risks identified by security, application and data criticality, and privacy risk analysis often relate to patient safety, independent safety risk assessments are necessary to ensure that all risks to a patient’s safety have been considered. Safety risk assessment in healthcare IT is intended to identify any areas where technology-induced errors may introduce risks to patient safety and then follow the risk-management process to reduce them as much as possible.
NOTE Errors are introduced by poorly calibrated diagnostic imaging equipment.
Medical device and hardware manufacturers use an analysis method called “failure modes and effects analysis” (FMEA) to identify potential failures in their products.3 Appendixes C and D of the ISO/NP 1497111 standard for the application of risk management to medical devices contain questions to ask when assessing device safety and conducting harm analysis. These questions can be applied to safety risk assessment in software, implementation, and healthcare-setting risk analysis as well. For example:
• What is the intended use of the device/software (in the provision of healthcare)?
• Will this device come into contact with the patient (tissues or body fluids, processing of biological materials, etc.)? What are the sterilization requirements?
• What are the accuracy requirements of the measurements?
As with all other types of risk assessment, once the risks have been identified they must be prioritized, mitigations must be assigned and tracked, and risks must be communicated with all potentially affected parties.
Chapter Review
The introduction of technology into the healthcare space reduces some risks to patients but also introduces new technology-related risks that must be managed. This chapter described the five iterative steps involved in managing risk:
1. Identifying risks
2. Assessing and prioritizing risks
3. Planning mitigations and assigning ownership for mitigation activities
4. Tracking mitigation progress and residual risk posture
5. Documenting and communicating with internal and external stakeholders
This chapter also examined the differences between security, privacy, application and data criticality, and safety risk assessment and explored the techniques used to manage risk in these specific domains.
Questions
To test your comprehension of the chapter, answer the following questions and then check your answers against the list of correct answers that follows the questions.
1. You have been put in charge of performing a risk assessment for a new software product. What should you do first?
A. Identify information assets
B. Identify the potential safety hazards
C. Identify vulnerabilities
D. Identify potential impact
2. Which of the following mitigations does not reduce the likelihood of a risk?
A. Antivirus
B. Tape backups
C. Awareness and training
D. Access controls
3. Which of the following mitigations do not reduce the impact of a risk?
A. Tape backups
B. Disaster-recovery plans
C. Firewalls
D. Encryption
E. C and D
F. A, B, and C
4. How would you mitigate the risk of clinical decision support data being sent through a wi-fi network that may be accessed by unauthorized individuals?
A. Encryption
B. Awareness and training
C. Change the network configuration
D. A and C
E. B and C
5. When should you perform a privacy risk assessment?
A. At the start of a project
B. At the start, middle, and end of a project
C. At the end of a project
D. In the middle of a project
6. How should you mitigate the risk of phishing?
A. Education and awareness
B. E-mail filtering
C. A and B
D. None of the above
7. Why is avoiding a risk the least desirable type of mitigation?
A. Because it doesn’t work to reduce the impact of the risk
B. Because it doesn’t work to reduce the likelihood of the risk
C. Because all the positive opportunities associated with the avoided action are also lost
D. Because risks are impossible to avoid
8. What is the best way to address risks introduced by big data?
A. Risk analysis
B. Risk mitigation
C. De-identification
D. All of the above
Answers
1. A. Always start with identifying what you are trying to protect, i.e., the assets.
2. B. Tape backups reduce the impact but not the likelihood of a risk by making sure that the information can be restored quickly.
3. E. Firewalls and encryption prevent risks but do not lower their impact if they do occur.
4. D. Encrypting the data will make it harder to access, as will changing the network so that the data is not sent over the public Wi-Fi.
5. B. You should conduct a risk privacy assessment at the start, middle, and end of a project.
6. C. You mitigate the risk of phishing with education and awareness and e-mail filtering.
7. C. Avoiding a risk often involves cancelling a feature, or even a whole project, resulting in the loss of the opportunities presented by the feature or project.
8. D. De-identification is a key mitigation in addition to risk analysis and mitigation for any big data initiatives.
References
1. National Institute of Standards and Technology (NIST). (2012, September). Guide for conducting risk assessments: Information security. SP 800-30, revision 1. Accessed on August 8, 2016, from http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf.
2. HL7. (2012). Cookbook for security considerations. Accessed on August 8, 2016, from http://wiki.hl7.org/index.php?title=Cookbook_for_Security_Considerations.
3. Carnegie Mellon Software Engineering Institute. (1999, December). Software risk evaluation (SRE) method description (version 2). Accessed on August 8, 2016, from www.sei.cmu.edi/reports/99tr029.pdf.
4. IEC. (2006). Analysis techniques for system reliability: Procedure for failure mode and effects analysis (FMEA). IEC 60812. Accessed on August 8, 2016, from https://webstore.iec.ch/preview/info_iec60812%7Bed2.0%7Den_d.pdf (search document ID=60812).
5. IHE International. (2008, Oct. 10). IHE cookbook: Preparing the IHE profile security section (risk management in healthcare IT) whitepaper. Accessed on August 8, 2016, from https://www.ihe.net/Technical_Framework/upload/IHE_ITI_Whitepaper_Security_Cookbook_2008-11-10.pdf.
6. National Information Assurance Partnership (NIAP). (2011, Aug. 1). Common criteria evaluation and validation scheme for IT security (CCEVS), version 1.2. Accessed on August 8, 2016, from https://dev.niap-ccevs.org/Ref/What_is_NIAP.CCEVS.cfm.
7. ISO. (2012, July). Application of risk management for IT-networks incorporating medical devices. IEC 80001. Accessed on August 8, 2016, from www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=57934.
8. Organisation for Economic Co-operation and Development (OECD). (2013, July 11). Guidelines governing the protection of privacy and transborder flows of personal data. Accessed on March 8, 2017, from http://www.oecd.org/internet/ieconomy/privacy-guidelines.htm.
9. IHE International. (2014, June 6). IHE IT infrastructure handbook for de-identification. Accessed on March 8, 2017 from https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_WP_Analysis-of-DeID-Algorithms-for-FP-Data_Elements.pdf.
10. Cavoukian, A. (n.d.). Privacy by Design: The 7 foundational principles—Implementation and mapping of fair information practices. Accessed on June 13, 2016, from https://iab.org/wp-content/IAB-uploads/2011/03/fred_carter.pdf.
11. ISO. (2007, March). Medical devices: Application of risk management to medical devices. ISO 14971:2007. Accessed on August 8, 2016, from www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=72704.