Integrating risk management with Quality

How does risk management relate to Quality? There's obviously some connection. If you don't think about risks when designing a product, there's a chance it might hurt someone when it goes out to the field. And if a product hurts someone, then it's a bad product—not a quality one. But when you set up a Quality Management System and a product development process, it's not always obvious how to integrate the consideration of risk. Is there some magic spot on the flowchart where you can drop a box called "Risk" and just have done?

Last week I wrote about risk evaluation, taking my lead from a LinkedIn post by Etienne Nichols that focused on the medical device industry (where he works). I was delighted to get a detailed reply from Edwin Bills which clarified some technical points and generously offered guidance to further reading. I wasn't familiar with Bills's work at the time, but I looked around and found that he has had a long and productive technical career in Quality and Risk Management, especially (but not only) with respect to medical devices. He has also published multiple articles. One recent article addresses exactly the question I've asked here.

This article dates from May 2023, not quite two months ago, and is titled "The Intersection Of ISO 13485 And ISO 14971 Under The Proposed FDA QMSR." (You can find it here.) It focuses on the medical device industry, which is not exactly my wheelhouse, so I won't try to comment on the technical details. (Besides, if you are curious about those details you should read the article itself.) But Bills makes a number of broader points that are very valuable.

The first of these points sounds obvious at first, but has deep ramifications: there is a difference between product risks and business risks. In exactly the same way, there is a difference between a standard designed for regulatory compliance and one designed for process management. 

• With respect to the first distinction, product risks are in general a lot more detailed than business risks, and require a much more granular response. Risk analysis at the business level might highlight the need for a new policy or a change in strategy; risk analysis at the product level could identify dozens or hundreds of potential risks, of which let's say twenty or fifty are actionable. Then each of the actionable risks has to be analyzed in detail to determine exactly how to prevent it (or at least mitigate its effects).
• With respect to the second distinction, Bills observes simply that the first edition of ISO 13485 (Quality management systems — Requirements for regulatory purposes) was explicitly based on ISO 9001:1994, because the 20-element structure of the latter was very useful in supporting regulatory compliance. By the time ISO 9001:2015 came out, ISO 13485 no longer copied its structure—because ISO 9001's process approach (together with the frequent use of the phrase "the organization shall determine") made the document altogether too vague to be much help in an FDA audit.

A second general point that Bills makes is that—to answer my question in the first paragraph—there is no magic spot on the flowchart where you can drop a box called "Risk" and just have done. Bills takes considerable pains in his article to trace out the interconnections between ISO 13485 and ISO 14971 (Application of risk management to medical devices). As always, you can find the details in his article (and he provides a map at this link). Here let me say simply that the connections are many and subtle; and while he is clear that you do not have to comply with ISO 14971 in order to comply with ISO 13485, it sure helps. Bills also walks his readers through the entire product life-cycle—from design through development and into production—to show exactly what role risk management has to play at each step of the way.

There is a third point that Bills brings out that is absolutely critical for any risk management methodology. Risk management has to be a living system! It is no good to do your risk analyses and then (as Bills says) simply put the documents in the file and forget about them. In the real world, your experience with the product will continue to grow: every hiccup in production and every customer complaint tell you something you didn't know the day before. And this means you have to pull your risk analyses out of the file, update them with the new information, and check to see how that changes your results. 

For example, maybe some customer finds a way to misuse the product that you never thought of (customers are good at this) and as a result it breaks. (Or, far worse, hurts someone.) Now you know that the product won't withstand that kind of misuse. That's new data, so you have to add it to your risk analysis as an input and then see what changes.

There's a lot more, of course, and if you work in the medical device industry I strongly recommend the article. But these points should apply across all industries, so I am grateful that Bills spelled them out.