Documenting Risk Control Option Analysis

adir88

Starting to get Involved
#1
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.
 
Elsmar Forum Sponsor

yodon

Staff member
Super Moderator
#2
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

Involved In Discussions
#3
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.
 
#4
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

Staff member
Super Moderator
#5
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.
 
#6
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

Involved In Discussions
#7
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

Staff member
Super Moderator
#8
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.
 
#9
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.
 
Thread starter Similar threads Forum Replies Date
R What is the typical industry standard for documenting Usability Risk? Human Factors and Ergonomics in Engineering 16
S Documenting Design Verification Test Results (ISO 9001) Design and Development of Products and Processes 1
M Defining and Documenting Record Retention CE Marking (Conformité Européene) / CB Scheme 5
J Documenting a Calibration Interval Extension Calibration Frequency (Interval) 7
B Documenting hardware on Form 2 of AS9102 AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 5
bryan willemot Documenting past problem history for fasteners for AS9100 Rev D AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 2
Q Documenting Customer Complaints (Records) Customer Complaints 6
R Documenting Expiration Date Extension for a specific lot ISO 13485:2016 - Medical Device Quality Management Systems 12
J ISO 13485:2016 Section 6.2 - Documenting the process for establishing competence ISO 13485:2016 - Medical Device Quality Management Systems 6
S Does IEC 62304 require documenting unresolved anomalies for all safety classes? IEC 62304 - Medical Device Software Life Cycle Processes 4
C Documenting Cleaning Production Lines in Medical Device Pkg facility ISO 13485:2016 - Medical Device Quality Management Systems 1
C Documenting Cleaning Production Lines in Medical Device Pkg facility 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 0
C Documenting Cleaning Production Lines in Medical Device Pkg facility 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
L Problems while documenting the SOUPs used for the software we are developing IEC 62304 - Medical Device Software Life Cycle Processes 4
R Documenting Self-Training and Effectiveness - ISO 13485:2016 Training - Internal, External, Online and Distance Learning 4
C Documenting Software Safety Classifications IEC 62304 - Medical Device Software Life Cycle Processes 4
B Approaches to Documenting an ISO 22000 FSMA Food Safety - ISO 22000, HACCP (21 CFR 120) 3
G Process for Product Safety - Ideas for Documenting Process for 4.4.1.2 IATF 16949 - Automotive Quality Systems Standard 3
dubrizo Are you documenting Internal Audit findings as NCRs? Internal Auditing 18
M What is the value of documenting in-process rework for easily-detectable issues? Quality Manager and Management Related Issues 4
C Importance of Documenting NCP's and CA/PA's ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 23
D Documenting Meetings through Meeting Minutes or a Form ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
Colin Objectives Form - Format for Documenting Information Security Objectives IEC 27001 - Information Security Management Systems (ISMS) 2
O Documenting Processes requiring Customer Notification Misc. Quality Assurance and Business Systems Related Topics 2
M Documenting Vendor (Supplier) Issues Document Control Systems, Procedures, Forms and Templates 4
V Documenting Exceptions and use of Deviation Request Form APQP and PPAP 2
K AS9100 Clause 7.2.2 - Documenting "Special Requirements" and risks AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 1
K Competence, Training and Awareness - Documenting Training and Confidentiality Aspects ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 12
Q Documenting the Review of Adverse Effects from Rework ISO 13485:2016 - Medical Device Quality Management Systems 4
A Formal Way for Documenting Design Input Requirements 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
A Documenting 5S Guidelines in the Sales Department (Office 5S) Quality Tools, Improvement and Analysis 4
C Training Planning - Using Summary Sheet for Documenting Training Activities Training - Internal, External, Online and Distance Learning 3
J Requirements for Documenting Lifetime of a Medical Device ISO 13485:2016 - Medical Device Quality Management Systems 5
A Best Practice for Documenting Design Reviews 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 13
F Documenting Historical Preventive Action at a Daycare Preventive Action and Continuous Improvement 20
N Documenting Medical Device Complaints 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 6
R Documenting Quality Inspections - Material Released prior to Lot Acceptance Quality Manager and Management Related Issues 10
V Documenting the Root Causes for Internal Audit Non-Conformance Findings Problem Solving, Root Cause Fault and Failure Analysis 5
V Approach towards defining/documenting Requirements COTS vs. New-Product Software Quality Assurance 1
Crusader New Documenting Methods for Manufacturing Process Audits? Process Audits and Layered Process Audits 9
M Documenting an outsourced process - Distribution company with some manufacturing ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 2
P Process Map vs. User Guide - Documenting business procedures Process Maps, Process Mapping and Turtle Diagrams 3
T Documenting Effectiveness of Corrective/Preventive Action Nonconformance and Corrective Action 8
M Customer Format - Documenting Customer Software Requirement Specification and DDD Software Quality Assurance 10
D Documenting Machine Shop In-Process Checks Records and Data - Quality, Legal and Other Evidence 9
Crusader Continuous Improvements - How are you documenting them? Preventive Action and Continuous Improvement 66
R Documenting Processes such as Receiving Inspection, and Auditing to Turtle Diagrams Process Maps, Process Mapping and Turtle Diagrams 20
Gert Sorensen Requirement for specified agendas and meeting minutes when documenting projects? Document Control Systems, Procedures, Forms and Templates 2
A Submit a 510(k) to an existing device vs. Just Documenting a Change ISO 13485:2016 - Medical Device Quality Management Systems 2
D Documenting Revision History - Single ?Revision Record? Document Document Control Systems, Procedures, Forms and Templates 4

Similar threads

Top Bottom