Documenting Risk Control Option Analysis

[adir88]

How do you document risk control option analysis? Do you provide all risk control options in the order of priority then select which one you selected and why?

What I am interested to see is how do you fit this analysis in a hazard analysis or the FMEA? Would be great see what other tools are being used to incorporate this requirement.

 

[yodon]

I'm not up-to-speed on the :2019 version yet so take this with a grain of salt. I believe the Z annex debates are still ongoing and may have some bearing. This represents our current approach.

We do consider all controls in priority order of safe by design, protective measures, and information. We show these, in order, in our FMEAs. If there are controls that were considered but not incorporated due to either a better solution or when they no longer reduce the risk, we list them in a comments field with the reason they were not incorporated. This shows what was considered and has proven helpful to capture for historical purposes.

 

[ThatSinc]

In hazard analysis tables I include a column for risk control option selected, however if "lower priority" options have been selected I do not explicitly justify why the higher priority options have not been selected - the standard doesn't require this to be done.

The documented selection for which control option type has been selected allows the risk management report to assess whether more risks are controlled through design/protective measures/information for safety which allows a high level summary to be made regarding the inherent safety of the device.

It may seem superficial but it has been taken positively by auditors.

The detailed description for the control measure could be used to explain why any higher priority options have not been chosen, if so desired.

 

[Bill Hansen]

We are using a database for the risk file pieces, so RCOA is a text box. When we run a report, for instance, an FMEA, we include the RCOA text in an Appendix, sorted and indexed by the unique ID of the risk line. Sometimes the RCOA text is long, so we wanted to avoid having a huge table.

As for content... I was taught (during a big QMS re-write event) that each line needed an RCOA, and simply listing the risk controls that would be applied was sufficient. That seems redundant to me, since the risk table will show traces to the controls' implementation and verification, but to "check the box" we do it. However, sometimes the RCOA has value. If the design team gets into a good discussion about how to mitigate the risk, we try to summarize it in the RCOA. Then, the captured text becomes useful; it can support the decisions made and explain to a future design team why things were done a certain way.

 

[yodon]

I was taught (during a big QMS re-write event) that each line needed an RCOA...

That assertion isn't exactly supported by the standard. In that section, it's just a) determine the controls necessary, b) use the priority order, c) apply relevant standards, and d) record the ones selected in the risk file.

I think your approach of capturing the discussion is appropriate and useful.

 

[cbartlett]

To comply with 14971, I've always listed the RCMs in the risk assessment in the priority order described in the standard without a deep analysis. In the Individual Benefit-Risk, that's where I state that the risk has been reduced as low as possible and no further risk control measures are possible without adversely affecting the benefit-risk ratio. If I only have information for safety as the RCM, I leave the residual occurrence the same as the initial (to demonstrate that risk reduction hasn't been attributed to it) and definitely have a more robust benefit-risk analysis discussion why no other risk control measures are possible.

Some clients I've worked with include separate columns for inherently safe design, protective measures, and info for safety, but that is not a requirement of the standard. It's a preference thing, as opposed to a compliance thing. I don't separate them if I have the choice, it leads to pointless discussions of what category the RCM goes it when it doesn't matter.

I think the documentation of decisions made regarding RCMs belong in a Design Review, purely for the benefit of the engineering team responsible for sustaining your device (you don't want them to waste their time on an RCM that you've decided doesn't improve your benefit-risk ratio). I wouldn't show an auditor a list of all the what-ifs when they want to see the risk management file, only the what-is.

 

[ThatSinc]

Agreed on most points, but

If I only have information for safety as the RCM, I leave the residual occurrence the same as the initial (to demonstrate that risk reduction hasn't been attributed to it)

Something worth noting on this point.

Information for safety can, and does, in many cases reduce risk.

Disclosure of residual risk does not.

They are very different beasts.

 

[yodon]

I agree with the concept of limiting what a reviewer (auditor) might see but for historical purposes, keeping the decisions with the risk is the best way to minimize re-hashing decisions. If the options / decisions are in some review minutes somewhere, it's unlikely they'd be reviewed when going back over the analysis - especially when the players change.

 

[cbartlett]

Agreed on most points, but



Something worth noting on this point.

Information for safety can, and does, in many cases reduce risk.

Disclosure of residual risk does not.

They are very different beasts.

The challenge lies in the verification of effectiveness for that information for safety. If you have a robust usability engineering file, I agree that you can demonstrate the information does indeed reduce the risk. When doing RMF remediation or if someone in your summative usability study messes up that one step, I've found it easier to not attribute the risk reduction and discuss further in the Benefit-Risk analysis.