Featured Video
This Week in Quality Digest Live
FDA Compliance Features
Scott Gottlieb
A plan for digital health devices
InfinityQS
How to keep your profits from going flat
AssurX
Medical device manufacturers want clarity
AssurX
CDRH is walking the talk and expects device manufacturers to do the same
Ryan E. Day
Zimmer Biomet uses PULSE and SmartQuality solutions for FDA compliance and continuous improvement

More Features

FDA Compliance News
The FDA’s RMAT designation goes live
Awards help states implement multiyear produce-safety systems
The future of medical product development?
Manage risk while meeting regulatory requirements and compliance
FDA believes you can use openFDA to create products that promote public health
Company headquarters and 30 jobs in Dayton, operations in Europe, stay in place
Four guidelines for industry offer useful tools for manufacturers

More News

Jon Speer

FDA Compliance

Why FMEA Is Not ISO 14971

Medical device risks aren’t solely a function of failure

Published: Wednesday, April 20, 2016 - 16:46

If you’re still using failure mode and effects analysis (FMEA) as your methodology to capture medical-device risk management activities, then your risk management process is out of date. Let me tell you why.

Here’s the definition of “risk management” as defined in ISO 14971:2007—“Medical devices—Application of risk management to medical devices”: Risk management is “a systematic application of management policies, procedures, and practices to the tasks of analyzing, evaluating, controlling, and monitoring risk.” (See clause 2.22 on ISO’s online browsing platform.)

And to be fair, I’ll also share a definition of FMEA from ASQ: FMEA is “a step-by-step approach for identifying all possible failures in a design, a manufacturing or assembly process, or a product or service.”

Medical device risk management needs to be systematic. It considers the comprehensive use of a device, whether that use is correct or incorrect.

The basis of risk management is built on identifying hazards (i.e., potential sources of harm) and hazardous situations (circumstances in which people, property, or the environment are exposed to one or more hazards).

Once hazards and hazardous situations are identified, the severity of potential harms resulting from them are estimated. The probability of occurrence of these harms is also estimated. This estimation of severity of harm and probability of occurrence is what defines risk management.

FMEA is slightly different in its scope and purpose. The basis of FMEA is identifying failure modes. However, medical device risks are not solely a function of failure. A medical device might never exhibit a failure mode yet still have risks.

Don’t misunderstand me: FMEA is a very good tool and can be extremely helpful for design and development teams while evaluating the materials, components, and subassemblies that compose medical devices.

But FMEA is more of a reliability tool rather than a risk management system.

FMEA and risk management confusion

ISO 14971 uses terms such as “risk, hazards, hazardous situations, harm, severity, probability of occurrence, risk acceptability,” and “risk controls.”

FMEA uses terms such as “failure modes, effects of failure, severity, causes of failure, occurrence, process controls, detectability, risk priority number,” and “recommended actions.”

It’s pretty clear just by comparing the terminology of ISO 14971 and FMEA how this can be confusing.

“Hazards” and “hazardous situations” do sound similar to failure modes.

“Harm” seems similar to “effects of failure.”

“Risk” seems similar to “risk priority number.”

Certainly the terminology of FMEA seems close enough to risk management. Besides, you’re used to using FMEA, right? I get it. Everyone on the product development team is familiar with and somewhat comfortable using FMEA. You were using FMEA long before ISO 14971 become a harmonized standard. The intent and terminology is close enough... so why change?

Because doing only FMEA means that you will not comply with the ISO 14971 medical-device risk management standard.


Figure 1: ISO 14971 vs. FMEA comparison (courtesy of Gantus)

The medical device regulatory world has embraced ISO 14971

It’s clear from medical device regulatory bodies throughout the world that sound risk management processes are paramount for medical device companies. So much so that ISO 14971 was harmonized several years ago by most regulatory agencies, including the FDA, Health Canada, and the EU’s national competent authorities. (Note that the European Union published a harmonized risk management standard a few years ago called EN ISO 14971:2012.)

Regulatory agencies expect medical device companies to document risk management activities. And since ISO 14971 exists and is broadly accepted in the medical device regulatory world, I highly recommend using this standard as your framework.

Risk management is a system

As noted, ISO 14971 describes an entire system approach for risk management, as summarized in the following chart.

Figure 2: An entire system approach for risk management as described in ISO 14971

In a nutshell, a risk management process should include:
• Risk management planning
• Risk analysis
• Risk evaluation
• Risk controls
• Overall residual risk acceptability
• Risk management report
• Risk management file
• Production and post-production information

As you can see, ISO 14971 describes an entire system. It’s a process intended to be applied throughout the entire life cycle of a medical device.

Risk management needs to be useful

Keep in mind that the whole idea behind risk management for medical devices is to ensure that medical devices are as safe as possible.

Regulatory bodies aside, make sure that your risk management process is established and implemented in such a way that it’s actually useful.

Let me leave you with a few tips from a previous post to help you:
1. Get a copy of ISO 14971:2007 and ISO TR 24971:2013—“Guidance on the application of ISO 14971” (and EN ISO 14971:2012—especially if you are based in the European Union).
2. Establish a risk management policy and procedure.
3. Keep your severity, probability, and risk levels simple.
4. Use risk management as a tool during design and development.
5. Use risk management as a tool after design and development.

First published March 10, 2016, on the greenlight.guru blog.

Discuss

About The Author

Jon Speer’s picture

Jon Speer

Jon Speer is the co-founder and vice president of quality assurance and regulatory affairs at greenlight.guru, a software and services company that produces beautifully simple quality management software exclusively for medical device companies. greenlight.guru provides consulting as well for regulatory compliance, quality management, and risk management. Follow Speer on Twitter @creoquality.

Comments

Advantages of FMEA Based 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.

FMEA is not Risk Management

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

Taking ISO 14971 To The Next Level

Ed,

Reading your response brings back memories of my first contact with a medical device company.  I had written an article for Quality Digest (http://www.qualitydigest.com/june99/html/articles.html) titled “How to Get More Out Of Your FMEAs” in June, 1999.  The article talked about the five stages companies go through when implementing FMEAs beginning with thinking they understand how to use them when they do not.  The article also explained why RPN should not be used to determine what to work on.  The medical device company told me that they had read the article and researched my background and believed I had a good understanding of FMEAs.  They said they wanted to improve their FMEAs and believed I could help them.   Knowing that my background was automotive, they advised me that they were a medical company and consequently they would require “special” techniques when applying FMEAs to their products and processes.

I asked to see one page from a Design FMEA and Process FMEA that the company had created.  After performing a review, I informed them that the medical industry was not “special” and the standard Design FMEA and Process FMEA processes would work very well if implemented correctly.  In very simple terms using their documents I showed them that their main problem was that they did not understand how to properly perform and integrate the Design FMEA and Process FMEA.  To the company’s credit they were very open minded and we were able implement a risk management system that an FDA auditor said was the strongest he had ever seen during his entire career.

Based on my personal experiences over the last 15 years including reading this article and its posts about the problems with FMEA, very little has changed with respect to the understanding of FMEAs within the medical industry.  Most people I meet in the industry have a FMEA understanding that is based on concepts that were proven not to work over 10-15 years ago.  I must admit that I am a bit surprised that given your position on such an important committee that you do not have a more current understanding of FMEAs.  If you want to understand why RPN is never used by people who understand FMEAs you may want to read the Quality Digest article referenced above.  It will show you how the “Class Matrix” (automotive version of ISO 14971 Risk Matrix) is used to determine a risk category for every failure mode/failure cause combination.  A symbol representing the risk category is placed in the “Class” column of the FMEA.  Rows with insignificant risk are given no symbols.  The combination of the risk category and the occurrence rating are then used to determine and prioritize what must be worked on.  The “Class Matrix” was first actively used to determine what to work on in Design and Process FMEAs around 1987. 

If a company wishes to successfully manage risk in the most efficient manner it must be managed at the root cause level.  The following describes how risk is managed using Risk Based PLM® which uses the RRA®, Design FMEA, Usage FMEA and Process FMEA as its core risk management tools.  In Risk Based PLM(® the core risk management tools are integrated with each other and other critical product development tools such as the Design Verification and Design Validation Plan in sixty different ways.

As you have correctly stated the management of risk is a complex process.  Potential root causes of hazards can be created during any moment of a products life from definition of its intended use through to use and disposal of the product.  The same root cause can lead to multiple hazards which can have different probabilities of occurrence.  Finally, the mitigation of a potential root cause for one hazard can lead to the increased probability of another hazard occurring.

It is also very common that multiple harms can occur due to the same hazard and at different probabilities.  It is typically very difficult if not impossible to determine the probabilities of each of the potential harms.  For this reason, Risk Base PLM® requires that the level of harm assigned to the hazard for risk management purposes is defined based on the worst case harm.  Although this may lead to an overstatement of risk, it provides the greatest level of safety for everyone whose life can be impacted by the incident.  Risk Based PLM® primary method of reducing risk through mitigation of the root causes. It is important to note that Risk Based PLM® also advocates the reduction of the level of harm when a hazard occurs as a means of reducing risk if the reduction is possible. 

Risk Based PLM® was developed to manage risk in the most efficient way possible.  It accomplishes this in three steps.  First it strives to mitigate the root causes of hazards during the individual product development stages when they are created and before transfer to the next product development stage.  Secondly, it attempts to define and mitigate the root causes of hazard exposure when a product is being properly used and functioning correctly through multiple methods including modification of the properly functioning design.  Finally, it attempts to define and mitigate the root causes of hazard exposure during the disposal of the product.  

To show how Risk Based PLM® can be used to manage risk I am going to use a medical implant that I recently assisted a company with.  We are going to limit the discussion to a single hazard (physical change to the implant after insertion) that has multiple potential root causes that could be created during different stages of the product development process.  While analyzing the implant physical change, it was determined by the team that multiple harms could occur and that the different harms would most likely occur at unpredictable probabilities.  Per the Risk Based PLM® guidelines the worst case harm was used to set the set the severity for use in determining the risk category for all root causes.

The first group of potential root causes of the implant physical change occurring was the possibility of improper definition of design inputs.  If the usage environment issues that the implant would be exposed to were not properly defined, the product could be designed to survive conditions that were much less severe than the implant will actually see.  The RRA® was used to define the potential problem design inputs and their individual risk contribution.  Required modifications were made as required based on risk impact prior to the release of the design inputs to the design group. 

The second group of potential root causes of the implant physical change occurring was the possibility of improper implant material and dimensional specifications.  The Design FMEA was used to define the potential problem specifications and their individual risk contribution.  Required modifications were made as required based on risk impact prior to the release of the specifications to the manufacturing group. 

The third group of potential root causes of the implant physical change occurring was the possibility of improper site preparation.  The Usage FMEA was used to define the potential problem package insert site preparation instructions and their individual risk contribution.  Required modifications were made as required based on risk impact prior to the release of the package insert. 

At this time, the process that will be used to manufacture the implant has yet to be defined.  Consequently, potential root causes that deal with the physical changes due to the implant not being manufactured to specification have not yet been identified.  These potential root causes will be identified, their initial risk contribution determined and required modifications made to the process and process controls based on risk impact using the Process FMEA prior to the release of the process for manufacture of the product.

Risk cannot be managed efficiently when the impact of the root cause is not included in the probability calculation of the definition of risk.  Defining risk based on the probability of the harm occurring and the severity of the harm is insufficient to properly target a company’s resources since it does not identify the most important root causes of the hazard leading to the harm.

The mistake of not including the impact of the root cause in risk management activities is pretty common and has been occurring for years.  The mistake can be found in many of the FMEA reference documents people use to learn how to perform a Design FMEA, Usage FMEA and/or Process FMEA.  If one looks at the definition of the occurrence in these manuals that is used in the risk determination, it is defined as the probability of the failure mode and not the probability of the failure mode due the cause.  Unfortunately, these reference documents are developed by committees that require consensus for publication.  Change is very slow.  It took twenty eight years for a major FMEA reference standard to declare that RPN should not be used.  We are going on thirty four years plus for the wrong definition of occurrence.  Having said this, the existing FMEA references have some excellent information that if filtered using common sense.

ISO 14971 is an excellent starting point for risk management.  If defines many key steps that have been proven over the years.  However, there are many ways in which the risk management methodology defined by ISO 14971 can be improved.  Fortunately, by design the standard is non-prescriptive and gives companies plenty of room to develop powerful risk management systems that exceed the requirements of ISO 14971.  The power of the RRA®, Design FMEA, Process FMEA and Usage FMEA should not be underestimated.  When they are properly performed and integrated with the each other and other key tools within Risk Based PLM® they are considerably more powerful than the classical hazard driven matrix based methodologies currently in use throughout the medical industry.  I would love to present the power of Risk Based PLM® before your committee.  I think your opinion of FMEAs will be changed forever and the end result could be improved medical devices through better risk management.

Richard Harpster

richard.harpster@harpcosystems.com

Is an FMEA acceptable?

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.  

Management and Analysis

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

Article Severely Understates the Power of FMEAs

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.

ISO 14971 is the risk management standard for medical devices

Rick - I appreciate your detailed analysis and feedback on all the benefits of FMEA. THANK YOU!

Yes, I agree that FMEA is a very good methodology and approach for evaluating failure modes and single-fault failures. 

All I am trying to communicate is that if a medical device company only uses a FMEA-style approach, then the company will fall short of meeting the risk management requirements defined within ISO 14971.

Quoting part of the article above:

The basis of risk management is built on identifying hazards (i.e., potential sources of harm) and hazardous situations (circumstances in which people, property, or the environment are exposed to one or more hazards).

The basis of an ISO 14971 approach to risk management builds on hazards and hazardous situations. 

A medical device can be used exactly per indications for use, instructions for use, and perform correctly yet still will pose hazards.

Just something to consider.

Rick - Would you have interest in participating in the greenlight.guru Global Medical Device podcast? This would be a really fun session that I'm sure listeners would enjoy.

Let me know.

Podcast

Jon,

I would enjoy participating in a Podcast discussing the use of a product developemnt system for medical devices which uses the RRA and FMEAs for risk managment versus systems which use other methods that anyone else would like to present.

ISO 14971 Compliant Systems That Use FMEAs

Jon,

The FMEA based product development system that I described in the initial comment and describe in this comment has passed FDA Audit.  One auditor commented that in his eighteen years of auditing it was the most comprehensive risk management system he had ever audited.  He stated that although he looks for traceability of risk from the voice of the physician through to the controls on the manufacturing floor it was the first time he had ever seen it.  He was even more impressed when the client showed how the risk analysis information was used for other activities such as design change impact investigations and complex structured problem analysis.  The time required for these activities that normally would take weeks or months was reduced to minutes.

Unfortunately, I believe your understanding of what constitutes a properly performed Design, Process and Usage FMEA is severely dated.  Hazard analysis is a component of any properly constructed Design FMEA whether the product is medically related or not.   Your paper also talks about the use of the risk priority number which is no longer used to determine what to work on by anyone who understands FMEAs (Note: We first instructed our clients on the weaknesses of using RPN and recommended its non-use in 1990). The RPN has been replaced by a risk level defined using a risk matrix which is very similar to the risk matrix in the article.  Another previous weakness of FMEAs was addressing failures that required multiple causes to be present at one time. We have invented a concept called multiple integrated cause analysis to handle this issue.

By design, all ISO standards are designed to be non-prescriptive.  The goal of ISO 14971 is to define the key elements that a risk management system should have.  The standard is not designed to define a specific way of implementing the elements.  Your article is similar to the standard in that it provides an overview of the required elements of a risk management system but does not provide detailed instructions on how to implement them.  The software which you sell is one method you are suggesting for meeting the requirements.  It is not the only method.

If one reads the ISO 14971 standard one will find that the standard recognizes the need for FMEAs or equivalent tools for analysis of hazards.  The following can be found:

"H.2.4.2 Relationship to performance characteristics

Failure to meet specifications for any of the performance characteristics related to safety (see H.2.3) should be evaluated in order to determine if a hazardous situation could result. Tools for analysing such hazards, such as Preliminary Hazard Analysis (PHA), Fault Tree Analysis (FTA), Failure Mode and Effects Analysis (FMEA), and Hazard Analysis and Critical Control Points (HACCP), are described in Annex G."

Finally, one of the benefits of properly implemented and linked RRA®, Design FMEA, Process FMEA and Usage FMEA for managing risk is that the group of tools provides a very structured way of identifying all the sources of risk from definition of intended use through to and including the use of the product.  In your response you stated “A medical device can be used exactly per indications for use, instructions for use, and perform correctly yet still will pose hazards." I would respond that it is impossible to design and manufacture any type of product, medical or not, that does not expose its user to risk.  The key is to make sure the product provides an acceptable risk/benefit ratio and that the ratio has been optimized.

One of the most important advantages of the RRA®, Design FMEA, Process FMEA and Usage FMEA is that when properly performed they always drive to the root cause of the risk.  If you do not get to the root causes of risk, it cannot be managed.  One common mistake that I have seen in many risk management systems is that they use risk management techniques that do not drive to root causes.  Unfortunately, the systems had previously passed FDA audit and the companies were under the illusion that they were effectively managing risk when they were not.  The cost of such an misunderstanding can be quite large.

What is FMEA?

@Jon, what an excellent article, you are spot on. 

@Richard, it would be interesting to know what you mean by FMEA? When I talk about FMEA, I refer to IEC 60812 and Stammatis´Failure Mode Effect Analysis: FMEA from Theory to Execution from ASQ. If FMEA is done according to those sources, then you can't start working on your risk assessment until both the product and process are relatively mature, you would not consider both normal and fault condition (FMEA only addresses fault condition). Furthermore, the D-FMEA, P-FMEA and U-FMEA has a tendency to neglect the life cycle phases between "P" and "U", as well as after "U". All things going into the FMEAs you refer to can be put in a table that is aligned with the process described in ISO 14971. FMEA (assuming it is done in accordance with IEC 60812) will never be anything than one out of many tools that could be used within the process as it is described in ISO 14971. Please describe what you mean by FMEA Richard? 

Peter Sebelius, 

gantus.com/iso14971

 

What is FMEA

Peter,

If you are interested in ever experiencing the true power of FMEAs, I highly recommend that you obtain more current references and that when reading the references you apply engineering common sense before accepting anything the references say.  Mr. Stammatis’s book was published in 1995 and FMEAs have come a long way since then.  Mr. Stammatis’s book was based on the FMEA theories in practice in the automotive industry in the early 1990’s that had significant errors of both omission and commission.  One of the problems with the early FMEA theory was that it did not provide adequate definitions about what the meaning of each column was and what should be entered into it.  There were also inappropriate beliefs on when the FMEAs should be done which I will address in this response.

Published in 2006, the second edition IEC 60812 contained the FMEA theories that were present at the time.  It was influenced heavily by the AIAG FMEA Manual 3rd Edition which was published in July 0f 2001.  It is interesting to read the following forwards that can be found in the AIAG FMEA Manual 3rd Edition:

AIAG 1st and 2nd Version Forwards: “This manual provides general guidelines for performing an FMEA.  It does not give specific instructions on how to arrive at each FMEA entry, a task best left to each FMEA team.  This manual is also not intended to be a comprehensive reference source or training document.”

AIAG 3rd Version Forward: “This manual does not define requirements; it does provide general guidelines intended to cover situations normally occurring when preparing FMEAs during the design phase or process analysis phase.

All versions of the AIAG were created by committee.  As a result, they do not represent a best practice document but an agreement that tends to legitimize all the mistakes being made in the use of the process at the time.  There is a reason why the AIAG clearly states that it is not a requirements document.  They knew it was not a best practice.  There are considerable flaws in the AIAG 3rd Edition FMEA manual which unfortunately can be found in the IEC 60812 reference.

The most commonly used FMEA reference manuals currently in use are:

1.     “Potential Failure Mode and Effects (FMEA) Reference Manual, 4th Edition, June 2008;

2.     SAE Surface Vehicle Standard J1739 JAN2009 “Potential Failure Mode and Effects Analysis in Design (Design FMEA), Potential Failure Mode and Effects Analysis in Manufacturing and Assembly Processes (Process FMEA);

3.     VDA Volume 4: Product and Process FMEA, 2012 (European Standard);

4.     Mil-Std-1629 A 24-November-1980 “Procedures for Performing a Failure Mode, Effects and Criticality Analysis” (Notice of cancellation issued Air Force, Army and Navy on August 4, 1998).

Although I have seen it still in use, the Mil-Std-1629 was cancelled due to weaknesses in the methodology discovered during the space shuttle investigation.  The other three standards were developed by committee and have errors of omission and commission due to both committee and commercial influences.  During a seminar I recently presented for ASQ titled “Using Risk Based Management to Achieve ISO 9001:2015 Compliance” I identified and explained the impacts of eleven critical mistakes if the FMEA reference documents I have just identified are followed as written.

In summary these references have excellent information but they are not perfect.  Use engineering common sense before applying anything the manuals recommend.

As for your original question, “what is an FMEA”, there is no such thing as an “FMEA”.  One must identify the type of FMEA before a definition can be provided.  As an example, the Design FMEA is a systematic assessment of the risk the company and all people whose life will be impacted by the product will be exposed to if the Hardware Specifications and/or software code that define the product are released for use.  The risk assessment is accomplished via a structured decomposition of the design.  Its outputs are used to determine where the hardware specifications and/or software code must be improved due to unacceptable risk as well as to determine when the hardware specifications and/or software code can be released for use (acceptable risk/benefit ratio). 

It should be obvious that definition of FMEA in the article that “FMEA is a step-by-step approach for identifying all possible failures in a design, a manufacturing or assembly process, or a product or service” is not accurate.  Although identification of possible failures is an important step regardless of FMEA type, it is only one step in a comprehensive, multi-step risk assessment process.

Based on this definition of Design FMEA, it should also be obvious that your sources’ statement that “you can't start working on your risk assessment until both the product and process are relatively mature” cannot be true. 

Since I don't understand your concept of what a U-FMEA looks like, it is difficult to respond to your statement  “the D-FMEA, P-FMEA and U-FMEA has a tendency to neglect the life cycle phases between "P" and "U", as well as after "U".  Since the properly conducted Usage FMEA takes place before the Usage Instructions are released and has nothing to do with the manufacturing process, i don't understand what you mean by the cycle phase between "P" and "U".  There is a cycle phase between the Design definintion and Usage Instruction definition and Design definitiion and manufacturing process definition.  It is also important to understand that the the Design FMEA determines the content of the Design Verification Plan, Usage FMEA determines the contents of the Usage Verification Plan and the Process FMEA determines the contents of the Process Validation Plan.  The output of the use of these three tools is critical in establishing risk levels. 

Based on the posts, it is clear there is a need for increased understanding of the critical role properly performed FMEAs can have in supporting a fully compliant ISO 14971 risk management system.  I am very thankful for Jon’s offer to participate in a Global Medical Devine podcast where I can clear up any misconceptions about FMEAs.  Hopefully, Jon we will be able to schedule it soon. I have also approached Quality Digest about writing an article on how RRA® and FMEAs can form the backbone of an effective ISO 14971 compliant risk management system.  Hopefully, they will accept my offer.

If you have any questions, fell free to contact me.  Thanks for your comments.

Richard Harpster

richard.harpster@harpcosystems.com

Richard, thanks for the many

Richard, thanks for the many references to more literature on FMEA. 

Regarding D-FMEA, P-FMEA and U-FMEA, I was refering to Design, Process and Use (whatever that means). The problem that many experience with that approach is that risks relating to service, decommissioning and shipping are not found anywhere because there is a focus on the D, P and U. 

If I am to guess, your FMEAs are pretty close to what the ISO 14971 describes. Then this just becomes a question of semantics. Would be interesting to see an example of what you call FMEA? If it starts with hazards or components/process steps or something else? 

Peter Sebelius

gantus.com/iso14971