Are we spending enough time and resources on effective Preventive Actions?

Enternationalist

Involved In Discussions
Not to mention that preventive maintenance in a medical devices sense is frequently a corrective action, proving that it is a fundamentally different concept to preventive action. We often do it to prevent known issues from reoccurring. Calibration, repairs, servicing.

"That sensor drifted out of spec after 6 months - what are we going to do about it? Calibrate it every five from now on." Preventive maintenance, perhaps, but a corrective action in the form of a process risk control.

The descriptor "preventive" is the same, but the noun it is referring to is very different in these usages - the type of thing we're preventing is important, and preventive actions offer a pretty specific definition.
 

Bev D

Heretical Statistician
Leader
Super Moderator
preventive action for a non-conformance does drive some preventive maintenance of course. And some comes from prior knowledge of the systems and it’s potential failures. A simple example is for a blood filter in a blood analyzer. Since the job of filters is to catch ’stuff’ and keep it from getting to the core stream to affect cell cell counts the filter will eventually clog and effect results. Since the stuff we want to filter is inherent in the blood, we must filter it. Calculations are done, testing is performed to determine the effective usage time and and the PM cycle to replace the filter is set. The filter is placed in a location that is easily accessible to the user. on-board monitoring is added to ensure that teh filter replacement cycle is met and remains effective.

“preventive maintenance” can and is supposed to include both a priori and post non-conformance actions.
 

Ronen E

Problem Solver
Moderator
I think that - as noted by some - Preventive Action is simply an aspect of Risk Management. Why has it received a distinct, special status? I don't know. I'm guessing it's a historical artefact and has to do with the way QMS theory and standards evolved.

I feel that at this point in the discussion the lines between best design & development practices, risk management, and other modern manufacturing best practices have blurred a little. A lot of what's been said makes sense, but I think the original topic was more around these questions:
-- Is there (or should there be) a fundamental difference between CA and PA?
-- Why are the two bundled together (in standards, conceptually, and in practice)? Should they?
-- Is there really a distinct and unique kind of activity worthy of the title "PA"?
-- Why is PA implemented relatively little in orgs (is it?), and should it be different?
-- If indeed PA is unique and should be implemented "more", does it need verification and what should this verification include?

The conceptual starting point was (or usually is) CA. CA is intended to prevent recurrence of NC. NC is a situation where a specified requirement was/is not met.
Normally, when a requirement is formally specified, it is intended / desired that it will be met. So when it's not met it's a failure of sorts, and there's an associated harm/damage (could be small, but if there is absolutely no harm/damage, why is the requirement there?). NC = a risk come true. So this too can be analysed in the framework of Risk Management. Not all risks warrant action, and indeed not every NC calls for a CA. Sometimes the consequences are so small, or we can show that the frequency can reliably be forecast to be so low that a CA is not justified. And so on...

Can the concept of PA be analysed similarly, i.e. in the conceptual framework of Risk Management?

Is it time to unify QMS thinking and scrap those "unique" (historical) concepts? I don't know about QMS standards in general, but ISO 13485 is clearly lacking in the Risk Management department, in the broader sense. In medical devices, a lot of focus is placed on Risk Management from an application perspective, and manufacturing/operations get into the mix as contributors, but there is no consistent, robust and holistic handling of risk management that starts from the manufacturer (rather than the patient/user). ISO 13485 "relies" heavily on ISO 14971 (which does a nice work in the device risk management arena but is not really a holistic, day-to-day, risk management standard) and actually leaves much to be desired in terms of general Risk Management. If that could be overhauled in the next revision, and all related concepts (e.g. PA) could be brought under Risk Management's wings, I think it could be awesome.
 
Last edited:

Steve Prevette

Deming Disciple
Leader
Super Moderator
I'll just say I've never been a fan of ISO. It just seems to create a race to the bottom of the heap to see who can do the least amount of work possible (and spend the least amount of money possible) to claim "compliance" with a standard and sell [inferior] product. Rather than market differentiation and competing to create the best product at the best price, we are racing to reach a common standard of bare minimum compliance, lowest common denominator.
 

Tidge

Trusted Information Resource
I liked every discussion point in a post above, until the very end:
ISO 13485 "relies" heavily on ISO 14971 (which does a nice work in the device risk management arena but is not really a holistic, day-to-day, risk management standard) and actually leaves much to be desired in terms of general Risk Management. If that could be overhauled in the next revision, and all related concepts (e.g. PA) could be brought under Risk Management's wings, I think it could be awesome.

I appreciate that 14971 is strictly product-focused, and expected by regulators. Trying to apply the concepts of a product-focused risk management to the non-product QMS would be a nightmare IMO. See the FDA's recent push to get manufacturer's to worry less about NPS that doesn't have product impact... if there was a "QMS-ONLY" Risk Management File, it is likely that manufacturers would find themselves backed into the rigorous (re)validation of QMS-only NPS. (I'm not saying it would be a done deal, just that there is simply not a lot of critical thinking/nimbleness in this area.)

Pure opinion: I'd support trying to translate 62304 into general (i.e. hardware) design process before I'd support trying to translate 14971 into risk management for QMS!

In the context of medical devices (13485, 14971):
  • Corrective Actions and/or Preventive Actions are focused on the QMS; a small subset of these may belong to product lines, if they lead to...
  • Design Changes and/or Risk Controls, which explicitly belong to product lines.
 

Ronen E

Problem Solver
Moderator
if there was a "QMS-ONLY" Risk Management File [...]

[...] translate 14971 into risk management for QMS!
I never intended to suggest basing the holistic/general Risk Management, that is currently lacking in 13485, on 14971 (or similar), nor replicating the RMF approach to the entire QMS.

I'm not sure I understand the distinction between "the concepts of a product-focused risk management" and "non-product QMS" risk management. To me they are essentially the same. Risk management is risk management is risk management; and there is no "non-product" part of the QMS (everything in a QMS is product-related, unless the org is providing services only). The distinction I made was more between the narrow focus of ISO 14971 (device/application/patient/user) and a broader approach - something along the lines of "risk-based thinking", only I've grown to dislike this term. I dislike it because it's mostly used nowadays without really defining and clarifying what it means and what it applies to - mostly a buzz-term that a lot of people like to use because it sounds "nice", but when you ask them concrete questions about it they start to stutter...

When I'm talking about a holistic Risk Management approach, I mostly mean:
-- Stop and think often, preferably upfront
-- Be proactive rather than react
-- Try to predict/guess/speculate what can go wrong, and how. Do it a often
-- Prioritize based on severity of consequences and likelihood of occurrence
-- Take proportional action, verify implementation, results and effectiveness*
-- Apply all the above only in the fields that are important to you (why are you doing anything that isn't?)

*) The effectiveness of risk mitigation activity is the level of reduction in risk as a result of the specific measure.

I believe that the above applies to everything an org does and there's really no reason to divide and give different names to activities in different parts of the org which are the same in essence.
 

Ronen E

Problem Solver
Moderator
Rather than market differentiation and competing to create the best product at the best price, we are racing to reach a common standard of bare minimum compliance, lowest common denominator.

Very simple - in this day and age it's all about shareholder returns. No, that's not all, actually - there's also the Agent Problem (CEOs focusing on next quarter bottom line and stock price (which is buzz driven to a large extent), not on shareholders' real interests, because that's what their bonus depends on). If minimizing "compliance" costs and selling crappy products do it - there's really no organic mechanism to drive business trends in a different direction.

We all love to romanticize how it was once different, but I honestly can't say whether it in fact was. I'd like to think that decades ago people found a lot of satisfaction in "just" making things that were truly great (e.g. excellently engineered), and believed that that would naturally also lead to commercial success (whether that was true or just naïve is a different question), but I'm not sure anymore whether that was ever true or it's nothing but wishful thinking.
 

Tidge

Trusted Information Resource
I'm not sure I understand the distinction between "the concepts of a product-focused risk management" and "non-product QMS" risk management. To me they are essentially the same. Risk management is risk management is risk management; and there is no "non-product" part of the QMS (everything in a QMS is product-related, unless the org is providing services only).

The text of 14971:2019 explicitly excludes things like "business risk management".

The following can be a touchy subject: In a practical application of 14971, it is unlikely that that implementation of controls to satisfy regulatory or legal requirements (for example: in the USA, OSHA requirements) are necessary or accounted for in a medical device's manufacturing process to end up with a safe/effective medical device. Picking a specific type of OSHA requirement: Outside of the context of 1491, I hope that we all recognize that a welder's helmet with a filtered lens is reducing the risk of injury to the welder, but such PPE could at best only indirectly appear in a 14971-compliant RM file for a medical device (such as a bed or gurney frame).

To keep this example on the topic of the thread, the QMS could implement a PA to prevent potential injuries(*1) to the welders by issuing PPE... this PA would not need to show up in the 14971-compliant RM files(*2) for the device. If one jurisdiction has implemented specific worker protections but another has not, the risk-profile of the device doesn't change simply because production moves from one jurisdiction to another.

(*1) If a welder's mask is "too obvious", consider other risks to assembler's health that may have only been more recently recognized.

(*2) ... and we'd be back to the original question about measuring effectiveness of the (here, non-medical device) risk controls! (As well as assigning meaningful S/P1/P2 ratings, if needed)


The distinction I made was more between the narrow focus of ISO 14971 (device/application/patient/user) and a broader approach - something along the lines of "risk-based thinking", only I've grown to dislike this term. I dislike it because it's mostly used nowadays without really defining and clarifying what it means and what it applies to - mostly a buzz-term that a lot of people like to use because it sounds "nice", but when you ask them concrete questions about it they start to stutter...

I agree that there is abuse of "risk-based thinking" outside of medical device risks, which is why I willingly risk accusations of pendantry in the medical devices forum on this topic. 14971/24971 are pretty clear on what the target is and what the terms mean, as well as how to assess changes in a risk profile. I'm constantly running up against folks who say meaningless things like "we'll accept the business risk" but not even consider anything like (business) risk controls. Supplement "business" with "project" and together they account for 95% of the fires I have to fight. In contrast, it has been very rare that I've been involved with design changes because something has changed about the risk profile of a device. Even simple approaches like PDCA or DMAIC can be leveraged to help businesses/projects run better, but such things are not in the scope of 13485.
 

Ronen E

Problem Solver
Moderator
@Tidge I think that between the device-use end of the risk management spectrum and what you described as the business/project end there's a vast area which, in my understanding, comes under "Quality" or QMS but is not directly / not obviously in the scope of 14971. This is the section of the spectrum that I'd like to see 13485 address better / more explicitly / more precisely. It's not strictly device-related and not strictly business-related, but it definitely affects both indirectly. I don't see it as "non-product QMS"; it certainly has something to do with the product.

Production workers safety and health risks certainly affect the final product, because an injured or unhealthy worker can't consistently produce high quality products (regardless of the level of obviousness of the specific mode of injury). The reason the welder's PPE is not in an ISO 14971 RMF is not that it doesn't affect the device's risk profile; it's because that risk is already well understood and it's mitigation is standardized (regulation is the ultimate standardization), and hence it's normally taken for granted. It's a no brainer that a welder needs eye protection, so nobody bothers to mention it. It's impractical to include everything in an RMF of a non-trivial device; every company omits a lot of trivial risks from its RMFs because the added value of including them is marginal. I think that a 14971-style RMF (or similar) is not necessarily the right approach for general Risk Management (it wasn't an accident that I didn't include it in the list of general risk management prompts). It can very easily push people into thinking that they need to document every micro risk, including ones that are already addressed well through long-established standardization, which would miss the point of "proportionality".
14971/24971 are pretty clear on what the target is and what the terms mean, as well as how to assess changes in a risk profile. [...] it has been very rare that I've been involved with design changes because something has changed about the risk profile of a device.
My "risk-based thinking" rant was not in relation to ISO 14971. Things are quite neat in that area. My rant was in relation to ISO 13485 as a general (medical devices) QMS standard. Where device risks are concerned, 13485's reliance on 14971 makes sense, and is currently sufficient IMO. The trouble starts when zooming out from aspects directly related to device-use risks - I think that currently ISO 13485 doesn't cover well (and certainly not in an elegant/efficient way) the broader risk management aspects that affect device quality (and safety) indirectly, and are not "pure business" (or "pure project management") aspects. This gap is currently under the blanket of "risk-based thinking", which sounds nice, but there's currently very little clarity and not enough concrete methods under that blanket.
Even simple approaches like PDCA or DMAIC can be leveraged to help businesses/projects run better, but such things are not in the scope of 13485.
Perhaps those methods are not in scope, but some risk management methods should be, and what I was suggesting is that concepts like PA (which is evidently somewhat vague and not broadly/consistently/decisively applied, currently) could actually be brought together, clarified and streamlined under a proper Risk Management domain in an updated 13485.
 
Last edited:

Philip B

Quite Involved in Discussions
Very enjoyable debate, thanks everyone. In 30 years plus I don't think I've ever been asked about preventive action by an ISO auditor. Nor in recent years have I been asked whether we take a risk based approach. I suspect that most auditors view this as chasing shadows and almost impossible to prove non-compliance. With limited audit time available, why bother? Just focus on the much safer ground of corrective action. Perhaps the answer is to take preventive action out of 13485 and beef up the 'risk based approach', to make it something tangible? In case I'm ever asked (I'm not holding my breath) I have a couple of examples of taking a risk based approach to the QMS up my sleeve, one being varying the frequency of internal audits based on performance and risk in a given area. I definitely think that 14971 device risk management should be viewed as separate from the QMS risk based thinking. I find 14971 mind-blowing enough without trying to apply it the entire QMS. ISO 9001 seems to be getting on fine without preventive action, why not 13485?
 
Top Bottom