December 20, 2012

Webinar Recording: Leveraging Traceability in Your Risk Management Strategy

Helix ALM
Requirements Management
Thank you to everyone who participated in the Leveraging Traceability in your Risk Management Strategy webinar. The recording is now available if you weren’t able to attend or if you would like to watch it again. http://youtu.be/aDVmKOLula0

Questions & Answers

Are there benefits for using an FMECA process instead of an FMEA methodology? FMEA is Failure Mode Effects Analysis; what is the failure mode and what is the effect on the device or the patient. FMECA adds the C which stands for criticality, and allows you to prioritize the order or amount of control you want to do in place. The criticality piece is important, but not sure if it ultimately impacts the overall risk management process. It’s better to have it than not, but criticality is also embedded in the severity of the failure modes, so again not sure it will help immensely in the risk management process. You imply that whether a review of a specific risk control measure has been held can be included in the RCM. How can this be done? When you use TestTrack, you can add custom fields to the records to do this. During the TestTrack demonstration, Michael showed the risk management table. You can add a custom field, which becomes a column attribute for each of those rows. Then simply make that a field you fill in manually, as part of your process. How do you decide that you’ve done enough risk analysis? Great question because it’s a common struggle in the medical device development process. Take the FDA 14971 standard, for example. It talks about residual risk and continuing with risk management strategies until you’ve reached an acceptable level of residual risk. If you keep chasing the links in that 14971 document, you reach a point where they say “this might be really hard to do” and then they move on. In our experience, most people try to use a quantitative approach that includes some kind of scoring model with thresholds to help the team decide when they’ve done enough risk analysis. Another approach, and one that we believe yields better results, is to also incorporate a qualitative approach. This involves reviewing failure reports and looking at how those failures and risks were mitigated. The MDD recently changed its approach to risk management in that the "soft controls" are no longer considered an acceptable risk control measure. Yes, there’s a bit of back and forth going on here with the standards. In other parts of the standard, they’re starting to require the validation of “soft controls” so there’s some contradiction in those two changes. Thanks for pointing that out. When you do this analysis with clients, do you work primarily with business analysts? Developers are usually not familiar with risk analysis. You’re right that most developers typically don’t think of their software or hardware ever failing, much less causing serious harm to another person. So it’s always good to get other parts of the business involved in these discussions to broaden the view of analysis. Most of my job in these kinds of meetings is to ask questions like “what happens if?” and see where the answer leads. Often, we get into really deep discussions on these topics and end up learning some very interesting things about the device and possible risks. Is the ALARP method being phased out of the RM process? I’m not sure I would say it’s being phased out as much changing what “as low as reasonably practicable” means. As the FDA 14971 standard has evolved, it has become better at defining the methodology of incremental refinements of the risk management strategy. As mentioned earlier, it’s still a bit vague in helping you determine when you’ve done enough risk analysis, and that’s really where the quantitative and qualitative methods come into play. For a software risk analysis how far do you need to go from a system level? All the way down to the functions/routines or line by line? You can look at software in isolation because it can’t really harm anyone if it’s not hooked up to or within a device that connects to the patient. So what we’re really talking about here is the system level; software failure mode analysis and software hazard analysis. Identifying hazards that can lead to harms and the effects of those harms. Risk analysis is not a one-time activity; it needs to happen throughout the device’s lifecycle. How long does it take to generate a report like the ones we viewed today in TestTrack? All of the reports shown today were run in real-time. There’s no need to batch reports or schedule them to run overnight. Just define your report data and layout and pick a filter to limit the result set—running the report takes no more than a couple seconds.