Proactive Risk Management
Risk management then: A child dies in 1986 at Seattle Children’s Hospital. Power and ECG cable connectors were compatible, electrocuting the child.
Risk management now: Covidien issues field alerts in 2015 due to cross-manufacturer interfaces.
Why had no one anticipated these scenarios? Is this reasonable? What can be learned from this when considering the new product development of medical devices?
The answer lies between the Utopia of Nothing and the Pandemonium of Everything, depending upon the maturity of your risk management process. Let me explain.
Every marketed product or process has inherent and residual risks. This is indisputable and reasonable. Afterall, the process of driving risks out of a product is called risk management, not risk avoidance. Responsible manufacturers should diligently anticipate how things can go wrong and what can be done to minimize the consequences. This is a significant cost to manufacturers and a great concern by regulatory bodies. For example, consider the mentions of risk in ISO 14971, IEC 62304, ISO 62366, and IEC 60601.
Manufacturers living in the Utopia of Nothing have perfect and ingrained processes, perfectly safe products with flawless and controlled interfaces, functionality that is completely documented, understood, and implemented. Everyone is happy because there are never any risks to manage. Anyone involved in this company, please speak up… Crickets? I thought so.
Manufacturers living in the Pandemonium of Everything live in panic, because everything is a risk, and risks scare people. Teams get tied up out of fear and churn or delay programs, and don’t deliver projects. Part of that fear is regulatory rejection. Another part is the constant fear of having missed something. This is where the practical application of ISO 14971 seems to miss out because ISO 14971 gives you principles, not practicum, in the execution of your risk practice.
We are all somewhere in the spectrum between Utopia of Nothing and the Pandemonium of Everything.
We must understand how our products or processes fall short before we can create and implement effective improvements. To miss this fundamental premise is to be in the Pandemonium of Everything. How is this done in risk management?
As team members we have to understand the various ways we can help identify and reduce the risk in our products or processes. A partial list includes:
- Identifying all stakeholders. Users are stakeholders, but there are influencers too. Regulators, Management, KOLs, Government bodies, Distributors, and Engineering are all important stakeholders whose needs must be considered.
- Describe the system boundary. All products or processes have boundaries. Some boundaries can be controlled, others not. Regardless of category, the interface must be keenly understood.
- Define the system functionality. What does the system do? When? How does it change? What influences the system functionality? How does a user interact with the system? What can go wrong and how?
- Document the outcomes. What do you want to happen? What scenarios need to be avoided? Is there feedback? Are there dependencies? Are there special circumstances?
Obviously, No one intended for a child to be electrocuted due to a failure in electrode hookups. However, had they invested the time necessary to understand all the stakeholders, the necessary system controls, how the entire system operated, and the operational environment, and what needed to be avoided, perhaps the accident could have been avoided.
What about you? Have you adequately anticipated the risks in your system? What other areas of risk mitigation need to be considered in our products and processes?
If you’d like help in identifying the risks in your program, or if you’d like help defining a stronger risk identification and management program, please reach out to us. We’d like to help you manage risks, so they don’t become issues.