I’ve helped many medical device development teams with formal risk assessment and I’m often asked, “Why do we need to do this?” This question doesn’t mean they don’t care about product safety. They just don’t see the value in the formal process and documentation. Compiling a documented risk assessment is difficult and time consuming. It requires considerable effort from key members of the project team, who are very busy, to provide the necessary multi-disciplinary input. Why is it worth all this effort?
And as anyone who has sat through long meetings performing risk analyses and compiling risk documents knows, the majority of the risks they’re documenting are already known to the team. So what’s the point?
I put together this table to answer that question. The table lists what I believe are the most important reasons we perform systematic, documented risk analysis for medical devices (in addition to the obvious reason that we are mandated to do it for regulatory compliance).
Main Reason
Reason #1: Uncovering unknown risks is, of course, the most important reason even if this occurs relatively rarely during risk analysis sessions. This is finding the flaw that everyone has overlooked up until now and would have resulted in a product recall (and maybe patient injuries). Conducting risk analysis sessions with a cross-functional team with multiple points of view is important for finding these ‘hidden’ risks.
Other Reasons
The other reasons take into account the full product life cycle, which can be many years, and the challenges of communication throughout a typical organization.
Reason #2: Focusing attention: Making sure that everyone involved with the product, not just the people sitting in a risk analysis meeting, are fully aware of the most serious risks.
Reason #3: Establishing a systematic framework: Ensuring that risk controls are implemented and verified. Note that this requires that risk management is fully integrated into your design controls.
Reason #4: Compiling a knowledge base: This is important to ensure safety over the long-term. If years later, upgrades are made to the product or a gen2 version is developed, those projects will be able to build on all the careful risk analysis of the original product.
So the next time you’re stuck in a long, tedious risk analysis meeting, keep in mind that you’re really searching for that hidden, overlooked risk that could spell disaster for the new product. And you’re compiling a valuable knowledge base that can be used for many years.
For guidance on a systematic approach for starting risk management, see this post: Using a Hazards and Harms List to Improve Risk Management