Questions about the Risk-based approach to QMS processes

QE1993

Involved In Discussions
1. I keep reading, "you're probably already doing it since the standard has always implicitly required it. It just makes it more explicit now." If that's the case, then what exactly needs to be changed?

2. I don't know if this will be worded properly, but we've already "approached" our processes, meaning we've already implemented all of our processes, so is the standard now requiring to retrospectively do a risk-analysis on those processes? We do not have documented risk-analysis on our processes, but I believe we already have many risk-mitigation tools in place (i.e. control plans, first piece, in-process, and final inspection sheets, work routers, PMs, change orders, contract review, etc.). I just don't know if all of this is enough to fulfill the heightened risk requirements.

3. Some of our processes are risk-mitigation activities themselves, such as change orders, contract review, inspection, etc. Do we then have to do a risk-analysis on the risk mitigation activities? On that note, risk management is a process in itself, so do we then have to do a risk-analysis on the risk management process?

4. Which leads me to the question: am I getting too detailed with my QMS process? Should they be more high level, such as Production and Purchasing?

5. Am I overthinking everything?

6. What major changes have you implemented at your company to follow the new 2016 standard?

Thank you all.
 

Mark Meer

Trusted Information Resource
... 5. Am I overthinking everything? ...

I think you may be overthinking a bit.

Always ask yourself: what value does the risk analysis have? How would different outcomes of risk assessments influence your decisions? Only use it when it makes sense...

For example:
- Supplier approval criteria may be driven by consideration of what the worst-case of them supplying non-conforming product would be.
- Disposition of non-conforming product may be driven by consideration risk of continuing to use as-is.
- Whether to initiate an investigation into an incident or non-conformance may be driven by consideration of risk were the incident/NC to recur.
- Scope of change activities may be driven by consideration of the risk of any new hazards potentially introduced.
- Training/qualification requirements may be driven by assessing the risk if the assigned roles are not executed correctly/reliably.

As you can see from these examples: they are all decisions to be made, and it makes sense to base each of these decisions on an assessment of risk.

... we already have many risk-mitigation tools in place (i.e. control plans, first piece, in-process, and final inspection sheets, work routers, PMs, change orders, contract review, etc.). I just don't know if all of this is enough to fulfill the heightened risk requirements.

Consider: You say you've got a bunch of risk-mitigation tools in place? Why? What drove the decision to institute these controls? Are they appropriate, or even necessary, given the risk?

Good risk-based approach would answer these questions by documenting how risk assessments influenced decisions (activity/decision -> risk assessment -> need for mitigation -> development and implementation of controls commensurate with assessed risk).

Hope this helps somewhat...
Good luck!
MM
 

somashekar

Leader
Admin
1. I keep reading, "you're probably already doing it since the standard has always implicitly required it. It just makes it more explicit now." If that's the case, then what exactly needs to be changed?

2. I don't know if this will be worded properly, but we've already "approached" our processes, meaning we've already implemented all of our processes, so is the standard now requiring to retrospectively do a risk-analysis on those processes? We do not have documented risk-analysis on our processes, but I believe we already have many risk-mitigation tools in place (i.e. control plans, first piece, in-process, and final inspection sheets, work routers, PMs, change orders, contract review, etc.). I just don't know if all of this is enough to fulfill the heightened risk requirements.

3. Some of our processes are risk-mitigation activities themselves, such as change orders, contract review, inspection, etc. Do we then have to do a risk-analysis on the risk mitigation activities? On that note, risk management is a process in itself, so do we then have to do a risk-analysis on the risk management process?

4. Which leads me to the question: am I getting too detailed with my QMS process? Should they be more high level, such as Production and Purchasing?

5. Am I overthinking everything?

6. What major changes have you implemented at your company to follow the new 2016 standard?

Thank you all.
Hi..
You are not overthinking, but tending towards it.
If you know your business well and can explain all that with conviction what you have detailed in 2. of your post., and look at other weaker links in your process and make fact based decisions to change them to align with your business, .... then you will either meet up a good auditor who will align with your flow OR a bad one who will be forced out to re-train on the 2016 standard LA training.
Just know your business and context well and support the same with your QMS processes that aids the business and is good enough to address the dynamic risks and keeps you aware of the opportunities and threats.
 
Last edited:

yodon

Leader
Super Moderator
Let's be careful about making a parallel to risk-based thinking in 9001:2015 with the risk-based approach in 13485:2016. 13485 is very clear about what the focus for risk management is:

When the term “risk” is used, the application of the term within the scope of this International Standard pertains to safety or performance requirements of the medical device or meeting applicable regulatory requirements.

Clearly the standard writers are expecting manufacturers to focus on the risks related to product / end users (and regulatory) whereas in 9001, it incorporates business risks as well (not a bad idea just recognize the differences).

@Mark Meer is spot on with his examples.

It's probably a fine line but I think the distinction is important to recognize.
 

stevegyro

Involved In Discussions
@ Mark Meyer and
@ Yodon

Very helpful and spot on.

Thank you.


Sent from my iPad using Tapatalk
 

Talja

Starting to get Involved
Dear colleagues,
Please advise me with risk-based approach.

We are working on software development for other companies and we are certifying only some small part of our company with ISO 13485.
So we divided processes and documentation into Corporate and Project level. The main idea that everything that is related to the project is compliant with IEC 62304 and FMEA approach.

The rest of the QMS processes on a corporate level does not have any risk management. Please advise how we implement this risk-based approach required from ISO 13485? How to cover risk management requirement in our case overall??
 

yodon

Leader
Super Moderator
Be careful not to confuse "the FMEA approach" with risk management. FMEA is one tool that can be used in Risk Management but it is not the do-all, end-all. Nor is FMEA a prescribed tool.

Nearly every process your company goes through can affect the product or regulatory compliance. Just consider what can go wrong in those processes that could lead to product or regulatory noncompliance. Further, there are varying degrees of risk that you can consider to help scope your efforts.

Consider supplier qualification, approval, and management. Some suppliers will be far more critical to ensuring product and/or regulatory compliance. It's pretty typical, then, that you have some kind of ranking system for suppliers and those at the higher end of the risk scale get more scrutiny / oversight than those at the lower end.
 

RichardJ_CH

Registered
Hi Talja
To me your wording has a dangerous flavor "The rest of the QMS processes on a corporate level does not have any risk management."


The notion is that a QMS has a certificate (e.g. 13485). If 13485 requires process RM, then this applies to ALL its process.


Thus, if your company claims to develop medical device SW, it needs to name ALL processes listed in the 13485, whether their own or not, and CONTROL them.


As stated earlier, the risk-based approach wants you to look at ALL processes of your QMS and assess their impacts on the safety and performance of your device (SW in your case).


Hope this helps,
Richard
 

Talja

Starting to get Involved
Thank you for the answer, but what about our business, we do not have such suppliers that can affect what we do, we have only suppliers of computers, monitors, peripherals, internet, electricity that are used by our developers in work but it cant affect the quality of the code it can affect the time of development. And we do not have any physical medical devices, it is just a code.
 
Top Bottom