Risk management in the medical device domain

Background and related work

agile practices (McHugh et al. 2014), however McHugh et al. (2014) have concluded that the FDA General principle of software validation, accept iterative software development models and that they thereby enables for the use of agile practices.

without increasing costs or time. According to mitigation of risks, the ALARP principle considers that any mitigation can result, new risks as well (Bianco 2011).

Risk management (Boehm 1991; Hall 1998; Crouhy et al. 2006) typically includes identification of risks, analysis and prioritisation of risks, and handling and monitoring of risks. Relevant people identify risks during the risk identification and then the risks are prioritised with respect to the probability of the risk actually occurring and the potential effect they will have if they occur. According to Pfleeger (1999) the prioritisation of risks is often carried out through discussions where participants see risks in different ways and valuate them differently.

A well-defined risk management process must be applied throughout a product’s whole life-cycle process, from inception until the product is no longer in use. The risk management process presented by Hall (1998) consists of five essential elements and the risk management process presented in ISO 14971 (ISO 2012) consists of four essential elements, both processes are presented in Figure 1. How the elements in the two processes correspond to each other are indicated with arrows in the figure.

Figure 1. Essential elements of the risk management process

The two compared risk management processes use different terminology in their descriptions. Hall (1998) is referring to risk, defined as “a measure of the probability and consequence of an unsatisfactory outcome”, (e.g. similar to the risk definition in ISO 14971 presented above) and ISO 14971 (ISO 2012) is referring to hazard. Hazard, hazardous situations and harm are the key concepts in risk management

Background and related work

within the medical device domain. According to Leveson (2011) there is a problem with the definition of hazard as “potential source of harm”

(ISO 2012), since all system states have the potential to cause harm.

In a typical risk management process, the manufacturer of a medical device shall identify the hazards associated with the medical device, estimate and evaluate the associated risks, control these risks and monitor the effectiveness of the control. The risk management processes by Hall (1998) and the risk management process in the standard (ISO 1497 2012) are similar in content. The first step, risk analysis in ISO 14971, includes the two first steps, identify and analyse in the process by Hall (see Figure 1). During the risk analysis process are hazards identified and the risk(s) is estimated for each hazardous situation (e.g. assessment of severity of harm and probability of occurrence).

In the risk evaluation step shall for each identified hazardous situation, be decided if risk reduction is required or not. The decisions are based on predefined criteria. The risk evaluation step in ISO 14971 is part of the planning step in the process by Hall. The step called risk control in ISO 14971 covers the activities in part of the planning step, the tracking step and the resolving step in the process by Hall. During the risk control phase risk control measures are decided and implemented for all hazardous situations. Risks arising from risk control measures shall also be handled and residual risk evaluation performed where it shall be determined if the implemented measures have made the risk acceptable, if not must additional risk control measures be implemented. The risk control phase in ISO 14971 contains risk/benefit analysis, not included in the risk management process by Hall; neither is the production and post-production. For some occasions where the risk is greater than the criteria for acceptable risk is the manufacturer obliged to do a risk/benefit analysis to show that the benefit outweighs the risk and the users need to be informed about the remaining risks (residual risks). Information important for the production and post-production phase that are gathered and documented during the risk meetings, for example, introduction of warnings in the graphical user interface, labelling and special training, shall be documented in the risk management report.

Post-production problems reported by users, personnel who install the device, service personnel and product instructors should be discussed at a risk meeting and if so decided, the problems shall be incorporated in the risk management process.

Risk reduction can be implemented at three levels (ISO 14971 2012), at the first level, by inherent safety by design, at the second level by using proactive measures in the medical device or in the manufacturing process and at the third level, by informing the user. The risk reduction shall be introduced in this order but the three levels can also be used in combination. The most effective way to reduce defects and avoid serious consequences is, to design in safety in the software product during the development process (Ratkin 2006; Cooper & Pauley 2006). The risk management process described in ISO 14971 and the risk management process described by Hall has been carefully studied during the development of RiskUse.

The specific standard regarding risk management for medical devices is, as mentioned, ISO 14971 (ISO 2012) and the risk management standard for IT-networks incorporating medical devices is IEC 80001-1 (IEC 2010b). The responsible organisation has to coordinate a high-level risk management process of its IT-networks and the manufacturer needs to supply information about residual risks connected to their network products. Risks connected to IT-networks could for example be incorrect access, corrupt or incorrect data, and lack of traceability. Some examples of typical medical device hazard can be, incorrect measures, loss of function, incorrect output, memory failure, and use errors. It is also important to notice that there is a difference between wilful or reckless misuse of a medical device and misuse of a device because the user uses the device in other ways than intended by the manufacturer. The later misuse might be the result from, for example, misunderstanding of the use instructions, which means that it is important to consider the user instructions in the risk management process. When analysing hazards, to determine if the device can be used in ways that deviate from the intended use, is found to be difficult. (McRoberts 2005).

To provide high-level guidance in achieving regulatory compliance in the risk management field, there are guidance document published.

IEC/TR 80002-1:2009 (IEC/TR 2009) provides guidance on the application of ISO 14971 (ISO 2012) to medical device software. Two other examples of guidance documents are, Do it by design (FDA 1996), introducing human factors in medical devices development and Medical device use-safety (FDA 2000), providing guidance on how to incorporate human factors engineering into the risk management process. However the authorities do not provide any real detailed guidance or specific methods demonstrating how regulatory compliance shall be achieved,

Background and related work

even if they require a demonstration of regulatory compliance from organisations developing medical devices.

Several approaches and strategies are used in order to address risk management within the medical device domain. To trace risks in medical devices software or systems, Fault Tree Analysis (FTA) (Krasich 2000;

Hyman 2002; IEC 2006b) or Failure Modes and Effects Analysis (FMEA) (IEC 2006c; Chiozza & Ponzetti 2009; Jain et al. 2010; Xiuxu

& Xiaoli 2010) are often used. In a survey (Paper I) the findings indicated that FMEA is the most frequently applied method and FTA seems to be of lower importance. FTA (IEC 2006b) is a top–down analysis method where undesirable end events are identified and then all contributing factors, determine which failures are most critical. The fault tree analysis begins at system level and starts with a top event, that is a failure or an undesired event, then systematically identifying factors or events at lower levels contributing to the top event. The lower levels of events are combined in series by the use of Boolean logic and results in a graphical presentation of cause and effect. However the fault tree can expand widely and generate a need for tool support. FTA can be combined with other methods, for example, FMEA providing a bottom-up analysis and thereby contributing to a more comprehensive analysis (IEC 2006b). FTA is a practical method for causal analysis of the undesirable events and can be used for both single and multiple failure modes (IEC 2006b).

The main purpose of FMEA is to early in the design process identify potential problems that can affect safety and performance and take action to eliminate or minimize them (Kamm 2005)

As mentioned before, FMEA (IEC 2006c) is a bottom-up analysis method and it is used to identify each potential failure mode for all the parts in the system and trace negative effects through the system. The analysis starts with the lowest level of components and proceeds up until the effect of the system is identified. A failure effect at a lower level can become a failure mode of an item at the next higher level. The FMEA process can also provide measures according to severity, occurrence and detection and risk priority number can be calculated as a product of these three measures (Xiuxu & Xiaoli 2010). Advantages with FMEA are that it can be tailored to meet specified industry and product needs (IEC 2006c) and by using FMEA every component of the system is systematically examined (Jain et al. 2010). A limitation however, is that it can only be used for single failure modes (Jain et al. 2010).

Failure Modes and Effects Criticality Analysis (FMECA) is an extension to FMEA where severity ranking of the failure modes are made and allows prioritisation of countermeasures. FMECA investigates how the system detects and recovers from failures and for each failure mode is effects criticality and description documented (Becker and Flick 1997).

Another failure mode method is Healthcare Failure Mode and Effect Analysis (HFMEA™) developed by the United States Department of Veterans Affairs’ National Center for Patient Safety, it is based on multidisciplinary teams identifying possible failure modes using graphical described health care processes (Habraken et al. 2009). The objective of HFMEA is to systematically identify and analysis potential failure modes of healthcare processes and for those failure modes requiring further analysis make decision tree analysis. HFMEA also includes action planning and after that evaluation of the planned actions (Trucco &

Cavallin 2006). Two drawbacks with HFMEA identified by Habraken et al. (2009), the method is very times consuming and the risk assessment part is difficult to carry out.

Hazard and Operability Studies (HAZOP), is a qualitative method, for identifying hazards and operational problems with the use of guide words (more, less etc.). Emphasis is put on the meetings where deviations in every information flow of the design is identified, analysed and documented, as in an iterative process (McDermid et al. 1995; Paper I).

HAZOP can be used early in the system and software design to reduces the amount of design changes later in the process (Jain et al. 2010) and the method should preferable be used at higher levels of complex systems to remain cost effective (McDermid et al. 1995).

The medical device regulatory requirements require production and postproduction monitoring of the medical device for discovering additional or unexpected sever risks. The Corrective Preventive Action (CAPA) system is used in some cases, to collect, organises and trace failures. Information about problems and issues is collected from, for example, internal reviews or user complaints and the problems are evaluated for risk, severity and necessary action. Necessary actions are then taken to correct the problem and prevent their reoccurrence (Bills

& Tartal 2008; Lozier 2010).

Several researchers have reported on risk management on software development in general, e.g. Boehm (1991), Hall (1998), Charette (1989), and Jones (1994). In the medical domain, the published research discusses risk management from a high-level perspective; often the overall

Background and related work

risk management process is described without detail descriptions of each process step. McCaffery et al. (2009, 2010) who have developed and tested a software process improvement risk management model (Risk Management Capability Model) that integrates regulatory medical device risk management requirements with the goals and practices of the Capability Maturity Model Integration (CMMI) describes one example.

Schmuland (2005) also investigates the whole risk management process, although he focuses on residual risks, i.e. the remaining risks after the risks have been handled, and how to assess the overall residual risk of a product. It is based on the identification of all the important scenarios.

Hegde (2011) presents a case study of risk management based on ISO 14971 (ISO 2012) and concludes that the standard as guideline can ensure a safe product with an acceptable level of risk. Then, there are several studies presenting specific methods, for example, the use of FMEA in the risk management process (Chiozza and Ponzetti 2009;

Xiuxu and Xiaoli 2010; Habraken et al. 2009) and also different frameworks (Barateiro and Borbinha 2012; Iversen et al. 2004);

Padayachee 2002). Benet (2011) suggests a risk driven approach to medical device testing as a way of handling the risk verification process and assure overall safety of the medical device. There are some researchers that focus on one of the steps in the risk management process.

In the medical domain, for example, Sayre et al. (2001) in particular studied the risk analysis step. They described an analytical tool for risk analysis of medical device systems, a safety model based on Markov’s theory and argue that this safety model presents significant opportunities for quantitative analysis of several aspects of system safety. Dey et al.

(2007) have identified the need for analysing risk management issues in software development from the developers’ perspective with the involvement of the stakeholders.

The different laws and regulations, standards, guidelines and methods described in this thesis have been studied in-depth during the development of the new risk management, RiskUse. The terminology used in RiskUse is adapted to the terminology used by regulatory bodies and the requirements within the medical device domain.

To summarise, the discussed standards, guidelines and methods in this section, regarding risk management in the medical devices domain are presented in Table 2.

Table 2. Risk management standards, guidelines and methods Standards ISO 14971

IEC 80001-1 Guidelines Do it by design

Medical device use-safety Methods Fault-tree analysis (FTA)

Failure mode effects analysis (FMEA)

Failure Modes and Effects Criticality Analysis (FMECA) Healthcare Failure Mode and Effect Analysis (HFMEA™) Hazard and Operability Studies (HAZOP)

Corrective Preventive Action (CAPA)

During the development of RiskUse all the standards, guidelines and related work were closely studied and considered.