Risk management question: how much control can be assumed?

Bill Hansen

Principal Engineer, Quality and Risk at Terumo Heart, Inc.

February 2017

< 1 min reading time

When writing a Hazard Analysis or FMEA, how much “pre-mitigated” control and design work can be assumed? The pre-mitigated risk level, which is used to drive design decisions, needs to be based on some “baseline” level of risk. But that “baseline” could, arguably, include design decisions that are not optional (meeting a standard), or were made in previous device projects (device family safety features). This seems like a reasonable approach to take but verification of implementation and effectiveness are still required. Also, the risk document may not reflect the risk level if these things are not in place, and experience with production issues shows that sometimes even the most “foolproof” mitigations can be undone. Quality decisions may need to know the residual risk without the mitigation, in those cases.

Does anyone have any advice? Where should the “baseline” be set? Is there a formulaic answer?

This becomes a struggle between the pessimists of Quality and the defensiveness of Design. (I’ve been both, so I try to sympathize…)

Marked as spam

Posted by Bill Hansen

Asked on February 8, 2017 12:00 am

158 views

	Private answer Aaron Liang I think the most straightforward approach is to assume the base-line pre-mitigated risk as basically all worst case hazardous situations and/or causes taking place based on the use of the product regardless of whether they would be addressed by conformity standards or existing controls. That way, your baseline is essentially all of the hazards and then you work your way through applying various mitigations, some of which automatically come to mind via conformity standards or are inherently built into the device because of existing features or designs. I think this way it clearly draws the line between hazard analysis, identifying and then applying risk controls. Otherwise I find that when you mix all 3 activities together you often end up muddying the waters. Marked as spam Report spam
	Private answer Why are you making assumptions on pre-mitigated risk controls? One should have solid objective evidence about the design and its associated characteristics and how it will address hazardous situations that could cause harm. Based on the OE and evaluation of external products and risk acceptance criteria, decisions are made against state of the art to decide if company has done enough to market a safe and effective product. Marked as spam Report spam
	Private answer Bill Hansen @Aaron: thank you. This is the approach I'm familiar with, and definitely prefer, for the reasons you state. But, design teams are pushing back, saying that of course certain design steps will be taken; industry norms, personal experience, etc. They don't want to consider the possibility that they would not make those choices. @Ken: nice to hear from you. Perhaps I shouldn't have said "assumed"... yes, we will expect OE of any claims. My question is how many of those (verified) risk controls can or should be claimed in the "pre-mitigated" side of the chart. FMEA strategy (per Ed Bills, so I'm told) is to start the activity when the design is "finalized", but 14971-compliant RM needs to start much sooner. In reality, it tends to lag the design effort. So, we end up asking busy design engineers to predict how much more likely a situation would have been if they hadn't already designed in their risk control... and they don't like to answer. Marked as spam Report spam
	Private answer G M Butcher Also, it may seem like a problem, but when viewed a certain way it may not. Of course engineering makes use of knowledge based on pre-existing standards, etc. Many times these arguments arise because the differing risk analysis (FMEA) types or points of view are confused. There are three basic types, design, m'f'g/production, and user/customer. For design, the 'pre-mitigated' risk is easily addressed by a single line in the FMEA. Mitigation for that line could read (among several choices) qualification of the designers FMEA thru job descriptions, education, training in those standards. Here the use of 'standards' is generic. In the device world certain standards are well known and there should be proof the designer is aware of those, not forgetting previous complaints. Marked as spam Report spam
	Private answer Sri Vishnubhotla if the design is similar to previous designs you could base the baseline probability on data Marked as spam Report spam
	Private answer Beluh Mabasa Ginting It is not easy to identify known and foreseeable risks and to mitigate these risks in the design, production and use of the medical device although the manufacturers able to demonstrate to the regulatory authority that their product complies with the Essential Principles and has been designed and manufactured to be safe and perform as intended use or purpose during its lifetime. Base on ISO 14971, control must be start or beginning from the life cycle of medical device: pre-market, post- market and post market (conception and design, manufacture, packing labelling, advertising, sale use and disposal). Marked as spam Report spam
	Private answer Chad Johnson @Bill, Good questions. I'm with Mr. Butcher...when we consider the "Design" FMEA, the coverage from Design Rules, Guidelines, Experience, etc. can be expressed as a single Preventative action IFF (if and only if) the design and/or requirements (application) are same as previous designs. The degree of deviation from the known scenario puts you on a sliding scale with the Occurrence rating. Once the design and requirements deviate significantly, you need to pull this line from the FMEA actions and default back to high Occurrence ratings commensurate with the uncertainty. Further, this approach requires that the feedback loop to the design rules and guidelines is intact and evidence can be given to show how previous problems lead to direct modification of these rules and guidelines. Marked as spam Report spam
	Private answer Antonin Cuc There are the technician conditions to safety usage Medical Devices described in the Protocol "CE" Conformity Assessment, so as in the instruct firm Videorecords from Delievers with detail edicatived usage firm instruments, firm measurermement, so as in the Firm processing Clinic Planning, Hall activities of staff, preliminary mandatory Health status of Patients. All by the universal technicians requirements of Laws. There are mostly internal mistakes in User praxes - when in internal regulations of Hospital Standards are "the blind" situation with some intuitive medical processing contrary fixed Technician requirements of Laws - you have never accept the "intuitive views on RTG Images" - when there are duties to take the Orthopadic screen and firm radiologic mask to controll accuracy of mechanical coaxialities between the stem and femoral bone - there are out of mental human views to guarancy the coaxiality in mandatory Producer defined tolerancy +/- 1 grad. Marked as spam Report spam
	Private answer Marcelo Antunes There's no baseline, and you should not use any control. What happen,s is that, for some uses (for example, using requirements from international product safety standards), you might not need to estimate the risk (such as described in the flowchart of ISO TR 24971). JWG 1 its meeting this week to begin the revision process of ISO 14971 and 24971 and we will be discussing this topic (in fact we just discussed this topic in a general way some minutes ago for planning of activities) and we will have a clarification in the future documents. Marked as spam Report spam
	Private answer Jonathan Wacks If it is the very first FMEA for the product, the baseline should presume no standards applied to the Design or application. You can then drop the overall RPN via application of a standard, design principle (e.g., redundant processors), or label copy/warning. In this fashion, you have demonstrated design intent/control. FMEA updates would be selective, based upon real-world data. Marked as spam Report spam
	Private answer Bill Hansen The responses seem to be divided between "claiming no controls" and "claiming standards and previous designs." I'm curious: is it a difference in industry background? For instance, automotive FMEA guidance says to use previous-model-year levels as the starting point. But 14971 seems to lean away from that presumption. This is a Medical Devices group, but are any of your answers founded in other industry practice? ( G M Butcher, Sri Vishnubhotla, Chad Johnson in particular) Or is the difference based on FMEA being a supporting work, and Hazard Analysis (or similar) being the main 14971-fulfilling work? Marked as spam Report spam
	Private answer Aaron Liang I think for design projects that are built off an existing design project, depending on the nature of the design (e.g. all the electrical hardware remains the same, purely a software change) you could continue off the existing risk framework and apply the existing risk controls to the new design as a foundation and add mitigations based on the gaps from changes. In a way you would be "assuming" a baseline level of risk controls based on the existing design principles and then adding new mitigations based on the changes. However, I think you would have to be careful with when and how this approach is used because design scope, implementation or feature changes could shift your design principles such that it renders some of your baseline risk assumptions invalid which can result in some back and forth. Marked as spam Report spam
	Private answer Marcelo Antunes The answers seem different because we are talking about two different thigs, FMEA and risk management. There's lot of confusion about failure analysis tools such as FMEAs being understood as risk management (this os something that we will also tackle in the revision of ISO 14971), and the practices of, for example, the automobile industry (which is historically focused ob FMEAs) do not translate correctly into risk management. In fact, you would be better comparing aviation risk management instead. Marked as spam Report spam
	Private answer Marcelo Antunes Als, please note that ISO 14971 does not preclude using an risk analysis from an older device as a initial starting point to a current device analysis (see Note 1 in 4.1), however, the extent of the use should be justified, and plainly using risk controls is not a good engineering practice Marked as spam Report spam
	Private answer Sri Vishnubhotla my perspective is based on medical devices, as always using best judgement on no controls versus previous designs should be excercized. when the risk management team knows that previously conducted design and mitigation activities apply there is no reason to do additional work. the document is not the end product it is the mitigation work that is driven from it which matters... Marked as spam Report spam
	Private answer G M Butcher @Bill Hansen Very keen of you to catch that distinction. This contributors risk activities began with HACCP in chemical plant operations, then evolved in automotive, devices, and biotech. Because 14971 does not mention a path does not mean it cannot be used. And vice versa. Use what is effective for your purposes, keeps the engineers happy, and gets them to contribute properly to the effort. Chad Johnson / Sri Vishnubhotla state good points about including previous problems handled as separate line items. Marked as spam Report spam
	Private answer Eddie Anderson, RAC We've had similar issues with our design team; "they don't like assuming risk for something they have already designed into or intend to design into the device." One way we have improved our RM process to address this, is that we documented a separate "hazard list" for each of our products / product families. The hazard list identifies all of the know hazards for the device and the severity level, which normally does not change. So, when we start a new RM project, we already have a good starting point for pre-mitigated risks. All we have to do is determine probably prior to risk control and identify any new risks that have not been accounted for. Seems to work pretty good for us and saves a lot of the conflict over the "assumed" risk control or risk control that attributed to normal design process, however you prefer to refer to it. Marked as spam Report spam
	Private answer Daniel Feller It depends on whether 1) the 'control' is already part of the item function you are assessing, and 2) the quality of the information used to support the assessment of the cause-mode-effect relationship for that item function. When assessing occurrence you should also consider the quality of info, for example: no background=10; assumption=9,6,or3; similar data/experience=8,5,or2; actual data/experience=7,4,or2 (if you're using a 1-10 scale). Ideally when you are developing the application, product, or mfg process, the team would be designing with robustness in mind and therefore be selecting functional configurations that offer low failure rate (e.g. LED vs bulb) therefore there is always going to be some level of inherent control thereby less risky. You want the risk assessment to expose those items with lack of inherent control and/or those functions that you have poor quality of cause-mode information. Marked as spam Report spam
	Private answer Julie Omohundro I'm wondering WHY the design team doesn't like assuming risk for something they have already designed into or intend to design into the device? Seems to me they are essentially discounting the value they put into their design in terms of reducing risk, where I'd have thought they would want to showcase it. Marked as spam Report spam
	Private answer A big factor in risk management relates to when you start the activity. Your risk management documentation should reflect the current device. If you start the risk management process very early, you should identify many risks that require additional controls and/or mitigations. Risk management is an evolutionary process. Marked as spam Report spam

« Back to Previous Page

Meet your next client here. Join our medical devices group community.