Risk Assessment for ISO 13485:2016 section 7??

[AliceQA]

Hi there,

I was hoping someone could help me, we received a very strange NC (IMO) from a certification body recently.

The NC states 'Process of risk management is not fully effective as: The organization shall document one or more processes for risk management in product realization. Records of risk management activities shall be maintained.'

We are a SaMD manufacturer, and when the auditor asked for evidence of process risk assessments, I stated as we are a SaMD manufacturer, still in development, the main processes affected are design controls, risk management, SDLC and process and computer system validation.
All of which, within the body of the procedures have details of process control steps, risk categorisation of activities and requirements associate with each risk level, roles, responsibilities and competencies of staff working in the development and those responsible for approval etc.

We will have a design risk assessment in line with ISO 14971, and do risk assessments of each software tool we use in development.

The auditor stated this was not appropriate, and I should have a risk assessment for every line of section 7 product realisation of ISO 13485, I've worked in a number of ISO 13485 certified QMSs in the past and have never seen such a process risk assessment for a process which does not generate a physical product.

The example given by the auditor was 'In your audit process, you need to assess, document and control the risk of an internal audit being performed by someone who is not independent of the process', to me, this is basic - write a control step in the SOP, I feel like creating a risk assessment is overkill.
(PS, I know audits are in section 8, this was the e.g. I was given)

I am wondering has anyone else experience of this kind of request? or knows of a way around it without creating a risk assessment, which will effectively mirror the quality manual compliance table, for the sake of it.

Thanks in advance,
A

 

[Sidney Vianna]

The auditor stated this was not appropriate, and I should have a risk assessment for every line of section 7 product realisation of ISO 13485

You have to engage with a Technical Manager at the CB and push back on the validity of the finding. Apparently this auditor is close minded on acceptable paths to demonstrate conformity with the standard and must be corrected.

 

[Tidge]

The example given by the auditor was 'In your audit process, you need to assess, document and control the risk of an internal audit being performed by someone who is not independent of the process', to me, this is basic - write a control step in the SOP, I feel like creating a risk assessment is overkill.
(PS, I know audits are in section 8, this was the e.g. I was given)

I think you correctly identified that audits are not part of product realization. Furthermore, you have correctly identified 14971 as the applicable consensus standard (referenced within 13485) as the mechanism for risk management. With the information as presented, this sounds to me like a serious mistake on the part of the (external) auditor.

Product realization happens within a quality management system, so it wouldn't even make sense that a product realization plan would consider risks inherent to another part of the quality system itself. If a specific feature of the QMS is defective (in the example provided: 8.2.4) in some way the finding is first against the defective element of the QMS.

 

[yodon]

I love posts like this, it makes me think. I try to think of if there could really be some fire behind that smoke. I'm not saying the auditor is wrong but I expect your 14971-based efforts are related to product failure. There *is* a bit of a "manufacturing process" with software: the build and subsequent management of the binaries.

I've seen cases where builds were done on one machine and the product tested then the "official release to the field" build was done on a different machine and it pulled in different library versions, resulting in software failures.

I've also seen where updated binaries somehow didn't get to the person installing and product was released with the wrong version.

In theory, those could be considered in a (probably really short) PFMEA but the point is that maybe there could be some things to consider.

But then there's:

should have a risk assessment for every line of section 7

And that's obviously ludicrous.

Oh, and I believe there's been discussion here about any data collected and maintained in the system being customer property. So that may be something that wasn't considered, either.

 

[somashekar]

Hi there,

I was hoping someone could help me, we received a very strange NC (IMO) from a certification body recently.

The NC states 'Process of risk management is not fully effective as: The organization shall document one or more processes for risk management in product realization. Records of risk management activities shall be maintained.'

We are a SaMD manufacturer, and when the auditor asked for evidence of process risk assessments, I stated as we are a SaMD manufacturer, still in development, the main processes affected are design controls, risk management, SDLC and process and computer system validation.
All of which, within the body of the procedures have details of process control steps, risk categorisation of activities and requirements associate with each risk level, roles, responsibilities and competencies of staff working in the development and those responsible for approval etc.

We will have a design risk assessment in line with ISO 14971, and do risk assessments of each software tool we use in development.

The auditor stated this was not appropriate, and I should have a risk assessment for every line of section 7 product realisation of ISO 13485, I've worked in a number of ISO 13485 certified QMSs in the past and have never seen such a process risk assessment for a process which does not generate a physical product.

The example given by the auditor was 'In your audit process, you need to assess, document and control the risk of an internal audit being performed by someone who is not independent of the process', to me, this is basic - write a control step in the SOP, I feel like creating a risk assessment is overkill.
(PS, I know audits are in section 8, this was the e.g. I was given)

I am wondering has anyone else experience of this kind of request? or knows of a way around it without creating a risk assessment, which will effectively mirror the quality manual compliance table, for the sake of it.

Thanks in advance,
A

What the NC states is not qualified because there is no objective evidence mentioned in the NC (assuming that the full NC statement is put)
The risk assessment is a continuous process, and the client has to keep visiting the risk assessment and update them as they progress. However if the audit trail has led to a situation that a potential risk is identified and agreed and that it is not assessed and controls applied., then this could be a NC with the noted evidence as objective.
The auditor is not there to perceive risks for the client.

 

[AliceQA]

The objective evidence was against the process and computer system validation assessment performed for one of our QMS tools (not related to product realisation), the auditor felt because we were using the tool for the QMS, we needed a detailed assessment of all potential process hazards across the QMS.

Thank you all for your feedback!
After more digging, I think I understand where the auditor was coming from, but I think citing against 7.1 with the QMS tool as an example have confused things.

I think the want for evidence of process risk assessment is coming from ISO 14971(ref's below) - but this is only for processes associated with the device. For software this should include risk assessment of processes and tools used in development if the output cannot be fully verified.
Thankfully, we have already identified the need for process FMEAs for installation and maintenance processes from our device risk assessment.

ISO 14971:2019 4.1 'Where documented product realisation process exists, it shall incorporate the appropriate parts of the risk management process', and NOTE 2, where 'a documented process within a QMS can be used to address safety in a systemic manner, [...]'.

 

[Tidge]

In my company's software development efforts, we subject development tools (i.e. software) to the same sort of NPS assessment/validation as other software systems... but those still are not based on a 14971 risk analysis. 14971 (62304) is appropriate for product software, not non-product software.

As was discussed in another thread about inspection methods "maybe not being so good": If the method/tool isn't validated for its intended use, this is an ineffective (or possibly "not known to be effective") risk control in 14971 space; it is not a new 14971 risk.

 

[Enternationalist]

It's possible that what they are trying to say is that they want to see a risk-based approach in your processes.

If your QMS tool was assessed under the same processes you use for product realization, there might not be a clear reason why you don't have the same detail of risk management for that QMS tool under your own SOPs. I've previously addressed a similar lack of clarity by introducing a form of "QMS Risk Management" that was much much lighter but still allowed us to do some level of allocating effort based on risk when it wasn't product related.

Nonetheless, push back by asking them for the specific clauses or requirements they believe you are non-conforming with. It doesn't sound like their objection is well-articulated enough that you could verify any corrective action was effective, anyway.

 

[AliceQA]

Thank you both @Tidge and @Enternationalist, I agree about the risk assessment for SW tools used in development and across the QMS. Our current process for this aligns with the FDA's recent draft guidance.

@Enternationalist when do you initiate the use of the QMS risk management form? As part of our change control process we have an impact assessment which assesses the risk of the change on the QMS and device, and then if the change relates to a process or tool, we have the process and computer system validation process.
I am reluctant to introduce another form just to overcome an NC if the corrective action won't benefit us in the long run, especially if the current process does what the legislation and standards require.

 

[Tidge]

@Enternationalist when do you initiate the use of the QMS risk management form?

My company doesn't have a "QMS Risk Management Form", but for projects in the development space: part of every phase gate review (moving between phases of a development project) we do a formal assessment of any governing procedures (NOT software tools) which have revised during the project. It is a bit of an annoyance, but only rarely have the governing procedures changed in a way large enough to impact work. We adopted this (partially) because those responsible for altering QMS procedures almost never have any insight into how that are specifically impacting projects, so the burden got shifted to the projects (unfortunately... because the projects were moving too slow compared to the evolution of the QMS).