Identification of hazards and Risk file

Koskis

Starting to get Involved
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:

yodon

Leader
Super Moderator
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

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

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

Trusted Information Resource
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.
 

Koskis

Starting to get Involved
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

Quite Involved in Discussions
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.
 

Koskis

Starting to get Involved
Followup question with a mindset of keeping use error based hazards, mitigations and risk / benefit ratio in their own user error - risk file:

IEC62366 discusses the difficulty of defining the probability of occurrence for new errors and Annex B with table B.2 has only the severity of harm identified.

In ISO14971, Clause 4.4 states that for hazardous situations for which the probability of the occurrence of harm cannot be estimated, the possible consequences shall be listed for use in risk evaluation and risk control. The results of these activities shall be recorded in the risk management file. Any system used for qualitative or quantitative categorization of probability of occurrence of harm or severity of harm shall
be recorded in the risk management file.

Question: Based on your interpretation of these two standards: in the "final" risk analysis for user error based hazards - is it mandatory to document probability of occurrence in addition to severity?
 

ThatSinc

Quite Involved in Discussions
My take on it has always been "if you can't predict whether it'll happen, assume it will happen and control as necessary. then re-assess with controls in place"
I always document this with the highest score, and my procedures for risk capture this method.
My thoughts on the purpose of it, which is moot by the fact that most regulations now require you to control identified risk regardless of its dimensions, is to stop you going "I don't know how often this'll happen, might not happen often" so give it a low score, and then do nothing about it.
 
Top Bottom