From ISO 14971:
“FMEA is a technique by which the consequences of an individual fault mode are systematically identified and evaluated. It is an inductive technique using the question “What happens if … ?”. Components are analysed one at a time, thus generally looking at a single-fault condition. This is done in a “bottom-up” mode, i.e., following the procedure to the next higher functional system level.”
What does it mean?
FMEA stands for Failure Modes and Effects Analysis, it is a step-by-step approach for identifying all possible failures in a design, a manufacturing or assembly process, or a product or service.
Contrary to a typical Hazard Analysis (required by ISO 14971), FMEA is a bottom-up approach, meaning that it starts at a low level of the product or process, working its way up to the effects to the system of subsystems.
It is not strictly required by ISO 14971 or any other standard (unlike the Hazards Analysis) and it does not necessarily deal with the consequences on the patient or user.
So why should you use it?
FMEA is a tool to ensure that you have captured all possible causes and failure modes of your system. In a top-down analysis (like the Hazards Analysis) it is difficult to identify correctly all the low level causes and sometimes, with complex systems, it is not all that practical.
FMEA can bridge these issues, allowing you do identify what component can cause which failure, without making your Hazards Analysis too cumbersome, and consequently less useful.
FMEA is also used in several circumstances to comply with specific requirements. For example, referencing IEC 62304, FMEA is a great way to address the potential effects of failures of software items. It is also a useful method to identify critical/key features of your product.
Is there a standard template for FMEA?
Not really. The FMEA follows the same principle of any other risk analysis tool, starting with the low level components on the left side and progressing to effects, causes, initial evaluation, risk mitigation activities and final evaluation.
Severity and Occurrence are the two parameters always used to score each item, with Detection added sometimes to assess the effects of inspection or other verification activities.
A simple FMEA table would look like this:
What is the difference between FMEA & Hazards analysis?
The relationship between the bottom-up approach of FMEA, and the top-down approach of Hazard analysis is shown in the diagram below:
Let’s look at the similarities and differences of the FMEA and the Hazard Analysis with the help of an example.
Let’s look at a generic device, which has a casing mounted on a frame using one bolt.
Following is a simplistic view of FMEA – the retaining bolt can fail due to a breakage caused by wrong dimensions. The effect is that the casing can come loose and fall on the user’s foot (hazardous situation):
The same case in a top-down approach of Hazard Analysis – the hazard of falling objects can result in a hazardous situation where the foot of the user is just below the loose case falling down. This can be caused by the retaining bolt breaking, because of its wrong dimensions:
Remember that in the Hazard Analysis, the severity rating for a certain harm must always be the same. Similarly, the risk mitigation for the same cause-effect risk items must report the same activities and so should their verification activities.
To summarize, the main link between the FMEA and the Hazard Analysis is at the Cause level: a certain failure mode has the potential to result in a hazardous situation; and the hazard related to this hazardous situation is caused by (among others) that failure mode.
Quick tips for your FMEA!
Like all risk management activities, remember to use it to ensure that the team feels confident in the technical solutions adopted and no major issue was missed.
An average FMEA should be in the range of 100 to 300 risk items. With less than 100 and, if the system is not extremely simple, you may have missed important items. More than 300 will make it difficult to manage.
1. Break down your product into subsystems if necessary, to keep each FMEA lean and meaningful;
2. FMEAs can easily be nested into each other, with lower level FMEAs feeding into parent FMEAs.
For more information about medical device risk management system in Atlassian JIRA – SoftComply Risk Manager