In September we shared an article from our Head of Quality Dr Dirk Hüber on the purpose and methodology differences between a Risk Analysis and a Failure Mode and Effects Analysis (FMEA). The article outlined how risks from a Risk Analysis and failure modes from a Design or Process FMEA are not independent from each other. In his follow-up article below, Dr Hüber explains how this relationship can be built into your risk management file in a transparent and manageable way.
In the previous article, we explained that a design failure, a usability failure, or a software failure may lead to a risk for a patient. In a similar way, a process failure may lead to a design failure that in turn may also lead to a risk for a patient. Consequently, the risk arising from, for example, a design failure, must be assessed in the Risk Analysis. Furthermore, for a known risk, the design failure leading to that risk should be analysed in the Design FMEA. Where a process failure leads to a design failure, and where a design failure is caused by a process failure, the design failure and process failure must be analysed in the respective Design and Process FMEAs. In short, the Risk Analysis and the different FMEA types are connected to each other – they are not isolated documents.
This follow-up article aims to build upon the concepts developed in our previous piece, covering the structure of a risk management file, populating the content of a risk management file, and finally its formal implementation.
Reviewing the structure of a risk management file will enable us to map the relationship between the Risk Analysis and the different FMEA types. There are three layers within this relationship:
In reality, both Design and Process FMEA will usually contain many FMEAs covering various aspects and scopes of the product and manufacturing process.
Our previous article outlined which elements constitute a risk and a failure. But how are these elements connected to each other when we want to establish the relationship depicted in the figure above?
The three elements describing a risk or a failure are connected by horizontally shifting the elements in each layer by one element against each other, as depicted in the figure above.
For example, if a (known) risk is caused by a (new) design failure, the hazardous situation or failure mode of the risk becomes the potential effect of the design failure, and the failure cause of the risk becomes the failure mode of the design failure. The failure cause of the (new) design failure must then be determined in the Design FMEA.
On the other hand, if a (known) design failure leads to a (new) risk, the potential effect of the design failure becomes the hazardous situation or failure mode of the risk, and the failure mode of the design failure becomes the failure cause of the risk. The harm to the patient, user, or environment must then be determined in the Risk Analysis.
Let’s take this academic explanation and apply it to a simple, practical example.
Consider a prefilled syringe that will be administered to a patient. The harm to the patient that we want to analyse here is the potential feeling of pain when the syringe is administered to them. Below, the goal is to analyse why the patient may feel pain:
In a layer diagram, that looks like this:
This may remind you of something you’ve seen in a different context – the 5-Why principle, applied in risk management:
As you work through your risk management file, you may trigger further ideas regarding the risks and failures already discovered:
For example:
So, after you have begun to analyse a risk top-down and its causes on a design and process level, you can start to populate your risk management file on the various levels with new risks and failures, which themselves will be escalated and de-escalated to higher and lower levels respectively for further analysis. Once you begin to analyse these escalated and de-escalated failures and risks, more ideas about further risks and failures may be stimulated, and so on.
This approach can be depicted as follows, whereby we assume we want to build a risk management file for a new product:
Of course, when completing the various documents within your risk management file, you should always apply an appropriate systematic, e.g.
But when you additionally follow the explained logic of escalating and de-escalating risks and failures, practise has proven the ability to populate a Risk Analysis and FMEAs efficiently and effectively. This in turn will really help you to achieve good specifications for your product and manufacturing process, as all mitigations defined will be included in these specifications.
At this point we should remind ourselves that as Risk Analysis, Design FMEA, and Process FMEA evaluate different things, they are complementary to each other:
These entities are associated with one another, and the approach we’ve introduced here ensures the proper connection of these entities in the risk management file, so that all aspects of failures and risks related to a product may be covered appropriately.
Risk management must start very early in development and continue throughout the development stage to deploy its full value. Then once your product is in market and you need to maintain your risk management file, the same principles apply and help as you analyse any newly detected risks or failures.
A risk management process following the approach we’ve outlined here may be implemented and maintained through a paper-based solution or with the help of an electronic tool. The key to ensuring successful implementation involves:
Finally, below we show as an example how a Risk Analysis table might be presented with these principles implemented, with some further hints on what needs to be included in your Risk Analysis to ensure compliance with the current version of EN ISO 14971.
Should you have a challenge relating to Risk Management, our Quality team is ready and happy to help. Simply get in touch to start the conversation.