Identification of hazards and Risk file

#1
IEC62366 clauses 5.2 - 5.4 talk about UI characteristics related to safety, identifying hazards related to the use of device, and find out reasonably foreseeable hazard related use scenarios, and picking the right ones for summative test.

For a start-ups, is there a way to do this in a lean manner without back and forth tracing between usability engineering and risk file, especially where almost the same small team is working with requirements, risk and usability?

Would the following work:

5.2 Identify USER INTERFACE characteristics related to SAFETY and potential USE ERRORS
- List these in usability file. Optionally perform task analysis depending on the complexity of the device.

5.3 Identify known or foreseeable HAZARDS and HAZARDOUS SITUATIONS
- Reference to risk file. During the risk analysis, consider the characteristics from 5.2 and other aspects of use error sources for risk.

5.4 Identify and describe HAZARD-RELATED USE SCENARIOS and 5.5 Select the HAZARD-RELATED USE SCENARIOS for SUMMATIVE EVALUATION
- No other scenario definition than mitigation related use scenarios documented in summative test plan as test scenarios, (picked based on foreseeable harm from risk file).

Or is there another way to interpret and implement the related clauses in smart manner?

Thoughts?
 
Last edited:
Elsmar Forum Sponsor

yodon

Staff member
Super Moderator
#2
Yes, in fact in section 10 of 62366 it says:

The identification of known or foreseeable HAZARDS and HAZARDOUS SITUATIONS is part of the RISK MANAGEMENT PROCESS as described in ISO 14971. The USABILITY ENGINEERING PROCESS contributes to the identification of USE ERRORS as potential causes for HAZARDOUS SITUATIONS.

Further, in 6.6, it says:

The analysis of known use problems and the analysis of foreseeable USE ERRORS can be part of the RISK MANAGEMENT FILE.

So there's a clear implication that the processes intersect. References to 14971 are peppered throughout 62366.

The "Risk File" and "UE File" are typically virtual files anyway so pointing to a single location for UE risks and controls makes sense. You will want to be able to identify what your UE risks and controls are. You can do that with tagging schemes.
 

adir88

Starting to get Involved
#3
One of the things I don't like about sharing usability risk assessment with (design) risk assessment is that the foreseeable events usually in a hazard analysis is different to hazard-related use scenarios which should take into account factors from the use specification. Also, it's tricky to tie task analysis within a design risk assessment. If you want to combine a task anslysis with a PCA analysis, that makes things even more complicated.

I also find that determination of the use error and criteria for summative evaluation within the design risk assessment muddles the design risk assessment.

Since the standard permits usability and risk files being shared, it's up to you (and your teams) to capture the differences if risk and usability files are shared. So long people don't confuse the terminologies and the intent of each activity, it should be ok.
 

indubioush

Quite Involved in Discussions
#4
foreseeable events usually in a hazard analysis is different to hazard-related use scenarios which should take into account factors from the use specification
How are these different? All hazardous situations, regardless of source, need to be documented in the hazard analysis--unless you have two hazard analysis type documents. But why have two when you can have one?

It is possible to have a hazard analysis document that is also a task analysis as required by the usability standard.
 

adir88

Starting to get Involved
#5
How are these different? All hazardous situations, regardless of source, need to be documented in the hazard analysis--unless you have two hazard analysis type documents. But why have two when you can have one?
I am talking about foreseeable events and not hazardous situation that is different hazard-related use scenarios. The hazard-related use scenario is a USE SCENARIO that could lead to a HAZARDOUS SITUATION or HARM. The USE SCENARIO is a specific sequence of TASKS performed by a specific USER in a specific USE ENVIRONMENT and any resulting response of the MEDICAL DEVICE.

One of the examples of hazard-related use scenarios given in IEC 62366-1 is:

PATIENT (USER) has poor vision.
Unit of measure labels are not clear on glucometer.
Poor ambient lighting in PATIENT’S home.
PATIENT selects display of blood glucose in incorrect units and misreads current blood glucose level.
Using a glucose meter that is difficult to read by a PATIENT.
PATIENT administers excessive amount of insulin.

Note that hazard-related use scenario includes multiple things that are derived from the use specification (patient having poor vision and poor ambient lighting in patient's home) which a foreseeable sequence of events usually does not consider. So, going back to what I said earlier "Since the standard permits usability and risk files being shared, it's up to you (and your teams) to capture the differences if risk and usability files are shared. So long people don't confuse the terminologies and the intent of each activity, it should be ok. "
 

Tidge

Involved In Discussions
#6
One of the things I don't like about sharing usability risk assessment with (design) risk assessment is that the foreseeable events usually in a hazard analysis is different to hazard-related use scenarios which should take into account factors from the use specification. Also, it's tricky to tie task analysis within a design risk assessment. If you want to combine a task anslysis with a PCA analysis, that makes things even more complicated.
(emphasis added)

Your mileage may vary, but I don't think it is that tricky. If a task analysis reveals a certain 'value' of P1 which would lead to an unacceptable risk, the design is likely going to have elements incorporated in it which lower value the P1 to the point at which the risk is acceptable. The risk may be reduced with some physical component ("that part doesn't get as hot") or it could be through user interface ("the hot part is physically isolated from the user").

In practice, there are many ways to tie everything together. My preference is to have a complete hazard analysis that identifies all risk controls (e.g. component specifications and UI specifications) for applicable lines of risk analysis.
 
#7
Note that hazard-related use scenario includes multiple things that are derived from the use specification (patient having poor vision and poor ambient lighting in patient's home) which a foreseeable sequence of events usually does not consider. So, going back to what I said earlier "Since the standard permits usability and risk files being shared, it's up to you (and your teams) to capture the differences if risk and usability files are shared. So long people don't confuse the terminologies and the intent of each activity, it should be ok. "
Great thoughts!

I like to keep all the risks (SW, security, use error...) in one document. Open area for me is especially on keeping hazard related use scenarios (including task level) in risk file:

"The MANUFACTURER shall identify and describe the reasonably foreseeable HAZARD-RELATED USE SCENARIOS associated with the identified HAZARDS and HAZARDOUS SITUATIONS. The description of each identified HAZARD-RELATED USE SCENARIO shall include all TASKS and their sequences as well as the SEVERITY of the associated HARM."

To take the IEC example you referred to earlier, do you see the following documentation in risk file format matching the intent of the standard?

Hazard: Patient administers excessive amount of insulin.
Hazardous situation
: Patient selects display of blood glucose in incorrect units and misreads current blood glucose level. (basically describe the scenario and setup here)
Cause: Patient's poor vision, poor labeling, or lighting conditions at home (based on use specification - users, environment, UI characteristics)
Harm: Permanent impairment or life threatening if medical intervention is not obtained, etc

(...Most probably for a device with severity of harm this high, I would want to make separate task analysis in usability file feeding to risk file...but using this just as an example)
 

ThatSinc

Involved In Discussions
#8
Based on the guidance in the standard, I would suggest that your Hazardous Situation is the excess delivery of insulin due to incorrect units of measure.

According to the definitions, a hazard cannot result in harm until such time as a sequence of events or other circumstances (including normal use) lead to a hazardous situation.
The Hazard could be listed as incorrect output (as per the example in Annex C of the standard) or could be listed as Blood Glucose Level as it is the lowering of the blood glucose level that is the cause of the harm.

I would suggest what you have listed as the Hazardous Situation in your example above is the reasonably foreseeable sequence of events that has lead to the hazardous situation, allowing the hazard to cause harm.

The harm should be an actual ailment or physical situation; for insulin overdose; fatigue, hypoglycemic shock, coma, etc.
What you've listed there I'd include as a descriptor of whatever value you're assigning to that severity of harm.

I've started a discussion relating to hazard identification in the risk management section of the forums for this to attempt to get multiple viewpoints and so far all are differing from how the standard provides its examples at some point, so YMMV.


with regards to the interconnected nature of all design aspects and risk, I like to identify usability and software hazards through their own processes and then take those identified hazards and analyse them within the risk management "core" documentation.
The outputs of the analysis and any control mechanisms go back into the software/usability inputs document as requirements.

I take the potential in-use hazards from task related hazard identification as part of the usability process and consider those part of the reasonably foreseeable sequence of events that might occur during use.
 
Thread starter Similar threads Forum Replies Date
K Do you have to use RPN in Medical Device Risk Analysis? Identification of Hazards ISO 14971 - Medical Device Risk Management 6
M Medical Device Identification & Codes - Article 27 Requirements questions EU Medical Device Regulations 1
T Non conformance product identification and traceability 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
Q Monitoring of lead time - Good KPI identification? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 14
Q Controlled sticker for product identification? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 15
Watchcat Identification of Test Sample in Test Reports? Design and Development of Products and Processes 22
B Marking of Medical Electrical equipment and accessories - Cl. 7.2.2 "Identification" and Cl. 7.2.4 "Accessories" IEC 60601 - Medical Electrical Equipment Safety Standards Series 4
M Informational EU – Unique Device Identification (UDI) System – FAQs Medical Device and FDA Regulations and Standards News 0
S ISO 14971 Risk Management - Questions for Hazard identification ISO 14971 - Medical Device Risk Management 2
Z Two Payment Identification Number (PIN) for the same order in DFUF website 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
K Identification and Traceability with an ERP system - Barcode Labels? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
M MDR Annex IX Chapter I, 2.2 (c) - Device identification procedures during manufacture. EU Medical Device Regulations 1
M Informational USFDA final guidance – Unique Device Identification: Convenience Kits Medical Device and FDA Regulations and Standards News 0
Stefan Mundt ISO 9001:2015 - 8.5.2 Identification and Traceability Manufacturing and Related Processes 14
S Looking for procedure on UDI (Unique Device Identification) 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
S UDI (Unique Device Identification) Requirements for Remanufactured devices 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
B Quality Management System documentation identification Document Control Systems, Procedures, Forms and Templates 11
K Document Numbering (Identification) System Document Control Systems, Procedures, Forms and Templates 10
N Requirements for the identification and traceability of demo product for sales force US Food and Drug Administration (FDA) 1
M RFID (Radio Frequency Identification) Registration in Europe and in MENA countries EU Medical Device Regulations 1
Q Identification of Training Needs = People Performance? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 10
H European Pharmacopoeia First Identification Requirements Pharmaceuticals (21 CFR Part 210, 21 CFR Part 211 and related Regulations) 1
J Identification of gage blocks General Measurement Device and Calibration Topics 8
DeeDeeM IATF16949, clause 8.5.2.1 Identification and traceability-supplemental IATF 16949 - Automotive Quality Systems Standard 1
DeeDeeM IATF 16949 - Clause 8.5.2 Identification and Traceability IATF 16949 - Automotive Quality Systems Standard 7
Q ISO 9001 Cl. 8.5.2 and 8.5.4 - Identification in Products ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
M Measurement Equipment - Identification of Calibration Status General Measurement Device and Calibration Topics 25
J Customer Identification and Traceability in Manufacturing Plans Manufacturing and Related Processes 5
M Risk Identification and Risk Assessment for any Process - Is it necessary? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 22
Edward Reesor UDI (Unique Device Identification): HIBCC or GS1? ISO 13485:2016 - Medical Device Quality Management Systems 31
R Identification of Medical Devices in MDD 93/42 Certificate EU Medical Device Regulations 2
L Managing Finance Processes - Identification of Sub Processes ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
M Informational Is Identification of Risks and Opportunities required for QMS Processes? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 87
dubrizo Initial Supplier Identification, Review and Controls ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 1
H UDI (Unique Device Identification) Requirements for IVD Software EU Medical Device Regulations 2
A Receiving Goods Inwards - Identification Records and Data - Quality, Legal and Other Evidence 8
Pmarszal UDI (Unique Device Identification) Transition Period - Packaging Labeling Other US Medical Device Regulations 5
Q RFID (radio frequency identification) registration for Medical Device Other Medical Device Regulations World-Wide 6
B Class II Medical Device UDI (Unique Device Identification) Question(s) Other US Medical Device Regulations 8
A Is Risk Identification and Treatment a Process? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 25
D 820.120 UDI (Unique Device Identification) Labeling Verification Requirements Other US Medical Device Regulations 11
M Identification of Glass Instruments and Measurement Devices General Measurement Device and Calibration Topics 2
A Identification of Customer Property: Customer-Supplied Thumb Drives & Ext Hard Drives ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 1
Z Failure Mode Identification in PFMEA according to AIAG FMEA Rev.4 FMEA and Control Plans 6
M Reagent Status Identification - 7.4.3 Verification of Purchased Product ISO 13485:2016 - Medical Device Quality Management Systems 6
Gman2 Identification of Raw Material being used In-Process ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
M Identification and labeling medical device replacement system components Other Medical Device and Orthopedic Related Topics 12
L Identification of Inputs vs. Outputs in Design and Development (Section 7.3) ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 4
T Implementing a Suspect Counterfeit Identification Program Quality Manager and Management Related Issues 3
S Understanding UDI (Unique Device Identification) Other US Medical Device Regulations 10
Similar threads


















































Top Bottom