As someone with over 29 years of experience in implementing FMEAs on a wide variety of products including medical products such as molecular assays, immunoassays, spinal implants and cancer treatments I must say that the author shows that he knows very little about the proper use of FMEAs in the management of risk for the design, manufacture and use of medical devices.  If the author understood what an FMEA was he would know that the Design FMEA, Process FMEA and Usage FMEA (there really is no such thing as an ‘FMEA’) are extremely effective tools for defining the risks a company faces during the different stages of product development.  The author would also know that the knowledgeable users of these tools use the information they provide about the current inherent risk in the product design and manufacturing processes to make key decisions such as design release, design change implementation, manufacturing process release and packaging insert release.

When the three FMEA types are integrated with the Requirements Risk Assessment and other key product development tools which they drive (Design Validation Plan, Design Verification Plan, Process Control Plan, Process Validation Plan), they form the backbone of an ISO 13485 and ISO 14971 compliant risk based product development system.  If you are interested in implementing “Risk Based Thinking” in your medical product designs you will have a very difficult time finding more powerful tools to assist you than the Requirement Risk Assessment, Design FMEA, Process FMEA and Usage FMEA.

Proper use of FMEAs can provide a company with tremendous benefits.  Following is a comment from one of our clients:

“Rich was asked to help us put together a Design Control and Risk Management program for our Immunodiagnostics products. Rich worked with us to build the necessary infrustructure to make the system comprehensive for the level of complexity needed to handle our products. During this time, Rich was not only helpful in putting the system in place, but also educating us on the throught process to evaluate product design and process control. In doing so, Rich provided us with the fundamental concepts to be able to decompose any product or process problem to arrive at an effective solution. He has left a lasting impression on our organization.” (Manager, Risk Management at Abbott Diagnostics)

If you would like to learn more about effectively implementing FMEAs to manage risk, feel free to contact me at richard.harpster@harpcosystems.com or call me at 248.374-1718.

This is certainly a good debate and there are some really good points being made here. Regardless of terminology, I think it is vital to establish what an organisation needs to get out of this process, now and in the future. I also think it is critical to have a clear understanding of the definitions. ISO14971 is an excellent standard which defines the requirements for managaging an intergrated process of risk management, FMEA and its many variants, are, at the fundamental level,  one of thetechniques that can be used to conduct the analysis of risk withing the overall management process. Personally, I have found FMEA to be my method of choice with my clients to conduct analysis of hazards and hazardous situations identified through the risk management process. Some of these comments suggest very sensible use and expansion of FMEA to support a life cycle model. FMEA to me is a very flexible analysis tool which can configured to represent the actual market size a company is operating in. I certainly needs to be regularly reviewed with post market data to ensure assumptions are representative of real world experience.

Regardless of the techniques, I think now, more than ever, we need to focus of the integration of this critical management process into the everyday decisssion making processes of an orginaisation. Proposed changes to European regulations will drive manufacturers to seek solutions which are flexible, intergrated into their business. The risk management process will have to perform a central role is supporting periodic device safety assessments, as well as being sensitive to changes in the post market experience of the product for many years. Linkages with vigilance processes, document control and design control are some of the many management systems a company has will be vital to deliver a robust risk management process that delivers on regulators expectations from the initial identification of user needs throughout the product life cycle.

Richard Young

richard@acclaimbiomedical.co.uk

Based on Figure 1 there are three major process differences:

1. Risk Management Planning

2. Overall Residual Risk

3. Production and Post-production Info.

Now, I don't think any of these are major process steps that cannot be included in an FMEA. In fact, most of them are if the FMEA is run properly. For example,

1. The Risk Management Planning activity is part of activity that determines on what part of the product, process or service an FMEA should or should not be performed. 

2. Overall Residual Risk can be estimated based sum of probabilities of occurrence or from the total expected cost of system failure reported with each update of the FMEA.

3. The FMEA documentation process should be run through document control and each meeting revision would include the actions taken and the results achieved both in terms risk reduction (RPN)  and expected cost (EPN). This includes implementation, production and post-production failure estimates and costs.  

Jon has done a fairly good job on a complex topic. Perhaps more discussion would buttress his case.

ISO 14971 is a medical device product safety standard identifies a risk management process developed over the last nearly 20 years, which has been studied in the development of other risk management standards such as the pharmaceutical guidance on risk management ICH Q9, and even the enterprise risk management standard ISO 31000.

The basis for ISO 14971 are some key definitions:

• risk- the combination of the probability of occurrence of harm and the severity of that harm
• harm- physical injury or damage to the health of people, or damage to property or the environment
• hazard- potential source of harm
• hazardous situation- circumstance in which people, property, or the environment are exposed to one or more hazard(s)

These (and other) definitions are the key to understanding the standard.  However, note that the term "detectability" does not appear anywhere in the standard's requirements, that is a term found in IEC 60812 the standard for reliability analysis using the failure mode and effects analysis technique.  Note also that the term "hazard analysis" does not appear in the standard, purposely, as the standard is about the analysis of risk and not the analysis of hazards.

OK, now that we have done some of the basics, lets look at the section of ISO 14971 on risk analysis, Clause 4.  Clause 4.1 establishes the risk analysis process and in Note 2 refers to Annex G for some risk analysis techniques (a total of 5). And Annex G.4 does refer to FMEA as a "technique by which consequences of an individual fault are systematically identified and evaluated".  Annex G.4 also points to IEC 60812 for more information on FMEA.  Now, you must know that the annexes are not requirements, but information to provide assistance on implementing ISO 14971, so Annex G is only information.  Another very useful and more expansive document providing information on risk analysis techniques is ISO/IEC 31010, with over 32 techniques identified, some of which may be useful in medical device risk analysis.

Clause 4.2 indicates that we should start risk analysis with identification of the intended use and the identification of characteristics related to safety of a device.  For instance the intended use should include the patient population, the environment of use, the health professional or other user of the device, as a minimum.  Also characterisitics related to safety might include the device is electrical or emits radiation or other characteristics (Annex C provides questions to help identify these characteristics).

Clause 4.3 contains probably the most important and overlooked statement in Clause 4, "The manufacturer shall compile documentation on known and foreseeable hazards associated with the medical device in both normal and fault conditions."  Note that it does not say "single fault failures" and it also says that we must identify hazards in normal condition.  This statement is a key to understanding why FMEA is not risk management.  FMEA is a tool used to analysis faults in a product, one at a time (single fault failures) , it is not a risk analysis tool. Though the FMEA standard does use the term "risk", itdoes not define what it means. FMEA is a fine tool for identifying single fault failures.  It does not identify all failure modes, nor does it identify normal condition hazards, which occur when there is no fault in the device.  Another important limitation of FMEA is the requirement that you must have a rather detailed level of knowledge about the design, thus FMEA is a tool used at the design output stage of the development process.  Now, ISO 13485 in both the 2003 and 2016 editions requires the output of the risk analysis be a design input.  FDA also agrees with this concept.  From a manufacturers point of view, it is much cheaper to conduct a risk analysis, identify hazards, evalute risk, and develop risk controls at design input rather than at design output, which may require significant redesign effort, thus adding cost and time to the development process.  But, FMEA is a tool that may identify some issues that may not be found until the design is more identified, and therefore is a valuable tool to provide assurance that the design is a reasonably good one.  

Medical device risk management does not use the concept of detectabilty as part of the definiton of risk.  While some may think detectability is useful, it has definite limitations.  Dectability should not be something usedafter the device leaves the manufacturer's control.  The late Mike Schmidt wrote a great article, Use and Misuse of FMEA in MD&DI in 2004 (still accessible in their archives on-line). In that article he discusses detectability.  One thing he did overlook, is that dependence on the user detecting a failure prior to use of the device is a great opportunity for the product liability attorney, and a large opportunity for loss by the manufacturer.  Another aspect of detectability is the use of a technique called RPN where detectability, probability, and severity (of effect) are multipled to give a score which is used to identify those hazards that must be addressed.  In medical device risk management, all unacceptable risks must be addressed, regardless of any score obtained by such calculations.

A more useful tool at the beginning of a design is the first one identified (purposely) in Annex G, G.2 Preliminary Hazard Analysis [PHA].  PHA points to the existance of information on the known hazards, which may be identified in published information such as FDA's MAUDE database, a manufacturer's own complaint files, clinical literature, and product safety standards.  Using this information at the beginning give the design team good information on already identified issues for the design team to incorporate in the design requirements while the design effort is still beginning. PHA is identified in IEC 31010 and also in IEC 60300-3-9:1995 A.5. 

Another useful risk analysis tool, which is almost required, is Fault Tree Analysis [FTA], which deals with a major shortcoming of FMEA, that of hazards caused by multiple issues.  That is, a hazard that requires two or more occurences for the manifestation of the hazard.  Another valuable aspect of FTA is that probabilites can be calculated using Boolean Algebra along with the FTA analysis.  A Fault Tree may have as the top event a Hazard or an Event (in the case of Event Tree Analysis).  Typically you can go as far as 5 levels (the 5-Why technique) to help identify the root issue to address.  There is also a standard for FTA, IEC 61025. 

Normal condition hazards (when the device is working as designed) are usually the province of usability engineering, which is defined in the standard, IEC 62366-1, and usability techniques are identified in AAMI HE-75, which is the basis of a develpment activity for IEC 62366-2 currently in process.  FMEA is one of the techniques that may be used, but again, it is not the only technique nor is it complete by itself.

So, in summary, to meet the requirements of ISO 13485 we must start risk analysis as early as Design Planning to provide the design inputs required at the beginning of development, a definite limitation of FMEA, but a strength of PHA, which aids in identifying known hazards.  To identify all foreseeable hazards, we must use techniques that go beyond single fault failures, such as FTA.  FMEA helps in providing a cross-check to make sure nothing was overlooked. In manufacturing where pFMEA is usually the only tool used, a very useful risk tool, which works well in combination with Process Validation is HACCP, identified in Annex G.6 of ISO 14971.

Ed Bills
ISO TC210 JWG1, Medical device risk management

My past posts have explained why the FMEA is an excellent risk management tool.  Risk management systems such as Risk Based PLM® that use properly performed and integrated RRA®, Design FMEA, Usage FMEA and Process FMEA as their core risk management tools have considerable advantages over the typical risk management system found in the medical industry which uses the classical Hazard Traceability Matrix (HTM) as its core risk management tool.

One major advantage that Risked Based PLM® has over HTM based systems is that Risk Based PLM® manages risk at the “root cause of the hazard level” while the HTM based system manages risk at the “harm due to the hazard level”. 

It is not uncommon that a single hazard can have multiple root causes (I have seen as many as 200 potential root causes for a single hazard).  The harm or harms that one experiences due to the hazard are independent of the type or quantity of root causes.  In HTM based systems, risk control measures are targeted based on the severity and probability of harm.  There is no way to prioritize which of the multiple root causes of a single hazard should be worked on first.  Only risk control measures dealing with the probability of harms or severity of harms due to the hazard can be prioritized.

When a hazard occurs, it is typically much easier and cost effective to reduce the probability of the hazard occurring than to attempt to reduce the probability or severity of the harm or harms.  The only way to reduce the probability of the hazard occurring is to eliminate or reduce the probability of the root causes of the hazard.  One must be able to identify which of the root causes have the highest probability of causing the hazard. 

When properly performed, the four core risk management tools of Risk Based PLM® always drive to a root cause.  The four core Risk Based PLM® tools use the probability of the hazard due to the root cause and the worst case harm that can occur when the hazard occurs to manage risk.  Consequently, unlike HTM driven systems, the core tools of Risk Based PLM® identify the most important root causes to address to get the maximum reduction in risk.

It is also important to note that many companies who use the HTM do not identify root causes of the hazard when completing the “Reasonably Forseeable Sequence or Combination of Events Column” of the HTM.   I believe there are several reasons for this but I won't go into them now.  Without a root cause or combination of root causes identified in this column it is difficult to identify the appropriate “Risk Control Measures” and to verify their effectiveness.