Risk Based Approach for ISO 13485:2016 Form/Procedure

[SLandry92]

Hi everyone, first post, but I've been lurking a bit. I dove head first in the medical sector after 5+ years in oil & gas as QA manager.

Since we're a small company (~50 employees), I'll be doing an "as simple as I can" method for evaluating risks for complying with 4.1.2 (b).

Basically, there is result low, medium and high in a grid of occurence versus impact. Medium and High need actions put in place, while low does not.

Changes/risks will have two categories, one for ressources changes and the other for all other change types with each level of risk (low, medium and high) along with each set (level / hierarchical) of staff required to approve the action plan. For example, high level risks for ressources need the management commity, while medium level risks require QA, engineering and affected departement manager while low level risks if, deemed worthy of an action plan would require only the departement manager (and RH if ressources).

This would make a 3*3 grid for evaluating the risk itself, while a 2*3 grid for specifying who needs to approve the action plans, which will be detailed in the procedure managing this form.

Would this be enough to satisfy requirements?

 

[yodon]

If you're talking about product risk, you need to get a copy of ISO 14971 and follow that. Depending on your target market, you may need 14971:2012 which throws quite a few curves, especially regarding requirements to mitigate ALL risks to the greatest extent possible (i.e., you can't just waive low risks). (I'm not sure how well a "simple" approach and 14971 align - you'll have to judge).

Change approval is not addressed in the standard (but certainly the impact to the risk analysis from the change is).

If you're not talking about product risk, apologies, I misunderstood.

 

[HelviReg]

Slandry mentioned section 4.1.2 b) of the ISO 13485:2016, so I guess he's not focusing only on product risks but also on meeting applicable regulatory requirements as stated in the standard.

The main challenge here is to properly detail the main risks originating from your firm processes without getting bogged down.
Once you've done that, the mitigations (what you call "actions put in place") shall be what you currently do to control your processes : procedures / KPI / review / etc.

One can then, for instance, justify using or not KPI for some parts of a process, from a risk-based approach.

Concerning your approbation matrix, I think you'r beyond the formal requirement

 

[Ronen E]

ISO 13485:2016 s. 4.1.2(b) requires that The organization shall apply a risk based approach to the control of the appropriate processes needed for the quality management system.

The processes needed for the QMS shall be determined by the organization (4.1.2(a)).

What are the "appropriate" processes to which the requirement in 4.1.2(b) applies? Based on s. 0.2, they are the ones necessary for allowing the product to meet its requirements; for compliance with regulatory requirements; for allowing corrective actions; and for risk management. Essentially, all or most of the QMS processes...

S. 4.1.2(b) relates to the "control" of the appropriate processes. What is "control"? It is the application of measures to ensure that the controlled entity is kept within predefined boundaries. In my understanding, "control" of QMS processes means ensuring that they take place as prescribed. So the question that remains is what measures need to be applied to ensure that the QMS processes take place as prescribed.

S. 4.1.2(b) provides part of the answer - it says that the determination of those measures should be risk-based. To me this means that the higher the risk of a given QMS process not taking place as prescribed (ie going out of specification), the more action / stricter measures need to be taken to counter the risk.

Effective control involves monitoring and feedback. In this case a properly functioning internal audit process can provide such feedback, so that the perceived risks and effectiveness of mitigation means can be continuously adjusted.

 

[Wolf.K]

Finally, I updated our QMS for the risk-based approach by updating our "quality planning" procedure with a short "risk-management for processes" chapter for all (!) QMS processes, and renamed our "risk management" procedure to "product risk management".

So, all QMS processes requiring a formal risk management according to 14971 (e.g. during design and development) reference to the SOP "product risk management", and the control of all QMS processes is controlled by the SOP "quality planning".

Next month we are audited by our notified body - then I will know if this approach is alright...

 

[JDay76]

I think many of us here would be very curious to hear how that portion of your audit goes...

 

[love02eat]

So how did your audit go? Was the CB satisfied with your changes?

 

[Wolf.K]

So how did your audit go? Was the CB satisfied with your changes?

It takes place in two weeks...

 

[Tatian]

We are taking the following approach; all my QMS major processes (4.1.2a/c) had their risks individually evaluated and the mitigation actions specified (in turtle like diagram) as well as their KPI (Key Performance Indicator).
As 4.1.2 b does not require a documented procedure, I did not document a specific procedure. The quality manual specifies that the QMS processes are mapped and that the controls are stablished, the method is left in open.
Any thoughts?

 

[Ronen E]

We are taking the following approach; all my QMS major processes (4.1.2a/c) had their risks individually evaluated and the mitigation actions specified (in turtle like diagram) as well as their KPI (Key Performance Indicator).
As 4.1.2 b does not require a documented procedure, I did not document a specific procedure. The quality manual specifies that the QMS processes are mapped and that the controls are stablished, the method is left in open.
Any thoughts?

I think that in essence you comply. The question is whether a stiff auditor will accept it (I guess not, which is a shame). Today it seems that auditors prefer piles of non-value-adding documentation with questionable implementation over a lean org that actually works according to what they say and according to the standard.