Risks arising from control measures vs. ineffective control measures

ThatSinc

Quite Involved in Discussions
Hi All,

I hope everyone is enjoying 2021, as much as possible, so far...

looking to confirm/clarify some understanding on risks arising arising from control measures vs. ineffective control measures - particularly around instructions for use and labelling, and translations of both.

If we take the example of cleaning a reusable product between uses to control the risk of biocontamination and infection;

Hazard: Infectious Agents (Bacteria/Virus)
RFSE: User does not sufficiently clean device prior to reuse
Hazardous Situation: Contaminated Device used on patient
Harm: Infection


If the control measures are that the instructions for use contain a full cleaning protocol, including compatible and validated automated cleaning systems and protocols, I would consider that the user not understanding the instructions would be a failure on the verification of effectiveness of the control measure - and the residual P1 and P2 values would be high, not that unclear instructions for use is a new hazard or hazardous situation.
I consider a lack of translation in this too, rather than a hazard in its own right.

Despite translations being available the Notified Body had previously stated that there is no explicit consideration for translations in the risk management file and so "inadequate translation" was added as a hazard which I disagree with.

I am suggesting that the control measures section includes reference to the translation process and relevant list of instructions documents in all languages.

Would you agree on this approach, or would you consider the need for a new line item in the hazard analysis? If there is a need for a new line in the hazard analysis, how would you approach this, as to me the hazard, rfse, hazardous situation, and harm are all the same.


Thanks in advance,

TS.
 
Sound like you have two sequences of events. In one, the user doesn't clean the the device even though they understand the instructions. In the other one, the user cannot understand the translated instructions, and so they do not clean the device adequately. The P1 value for each of these may be different.
 

yodon

Leader
Super Moderator
I don't necessarily find the feedback irrational. As @indubioush notes, you have a risk of the improper cleaning. The event leading to it could be incorrect / incomplete / improper translation (for the intended audience). Your control could be proper translation. You can get the translation itself validated (for the intended audience) and comprehension would be part of usability validation (using representatives from the intended audience).
 

adir88

Involved In Discussions
If you have an approved translation service provider (certified to ISO 17100 etc.) and your QS requires you to use an approved TSP for all translations (including in-country reviews), I would not recommend adding this as a sequence of events in your risk analysis. You have controls in your quality system that are built to ensure that translations are done by competent people, and you make sure that these requirements are met when your IFU is approved and released for use in manufacturing. This is quite an odd request and I have never seen a requirement for validating translations in this regard. At my company, we do not list quality requirements as risk control measures otherwise you end up listing all kinds of procedures and job instructions.

I completely agree that this has more to do with the verification of effectiveness of the risk control measure. Hopefully you have implemented this risk control measure in your design and have some design validation evidence to demonstrate that the risk control measure is effective and hopefully this is sufficient.
 

ThatSinc

Quite Involved in Discussions
Sound like you have two sequences of events. In one, the user doesn't clean the the device even though they understand the instructions. In the other one, the user cannot understand the translated instructions, and so they do not clean the device adequately. The P1 value for each of these may be different.

The P1 value for the occurrence of the hazardous situation, which is the contaminated device being used on a patient, considers this.
The factors that affect this are all considered when reviewing the control measures required.
The sequences of events that could lead to a hazardous situation are considered, as required by the standard, but not explicitly documented.

I'm not sure whether you're suggesting that a separate line would be required, or would you include the separate sequence of events within the same hazardous situation?
I would not find it value adding to essentially re-list every single hazard/hazardous situation that is controlled by instructions for use with an additional "translations not accurate" and/or "instructions for use not provided" line that exposes the user to the same hazard, then has control mechanisms for ensuring that the translations are correct and that each product is packed with an IFU.
I would actually find that for the purposes of overall risk that this would potentially misrepresent the number of risks a device has.

I don't necessarily find the feedback irrational. As @indubioush notes, you have a risk of the improper cleaning. The event leading to it could be incorrect / incomplete / improper translation (for the intended audience). Your control could be proper translation. You can get the translation itself validated (for the intended audience) and comprehension would be part of usability validation (using representatives from the intended audience).

I don't find the feedback irrational, I agree that there is a risk of improper cleaning and the risk file did not explicitly call out translations originally.
The reference to the risk control measure was to the English version and no comments were made regarding any languages.

It was more the approach to resolving the situation on a new line item being included in the risk management file rather than referencing the controls and verification of controls in the originally documented risk.


If you have an approved translation service provider (certified to ISO 17100 etc.) and your QS requires you to use an approved TSP for all translations (including in-country reviews), I would not recommend adding this as a sequence of events in your risk analysis.

How would you document the potential for lack of understanding or inappropriate translations?

At my company, we do not list quality requirements as risk control measures otherwise you end up listing all kinds of procedures and job instructions.

I would agree with this, the specification (instructions for use in all languages) is the control measure - how you ensure you meet that specification (translation process) falls under process control. However there are a number of process controls that do exist throughout manufacturing that are direct control measures on contamination/sterility etc so don't think that it's necessarily something you shouldn't do.


I completely agree that this has more to do with the verification of effectiveness of the risk control measure. Hopefully you have implemented this risk control measure in your design and have some design validation evidence to demonstrate that the risk control measure is effective and hopefully this is sufficient.

The translation process and verification of translations includes forward/backward translation and a read by an SME in the appropriate language - this was already in place, and was accepted at the time, but the update to the risk file was managed after the fact.
 
I'm not sure whether you're suggesting that a separate line would be required, or would you include the separate sequence of events within the same hazardous situation?
I wasn't really suggesting anything. I only wanted to call your attention to the different sequences of events. I don't know the class of your device or the level of risk that it has. I also do know how much you are relying on your user to understand your instructions for use.

You disagree with your notified body regarding the hazard of inadequate translation; however, it is best to make them happy. The most conservative route would be to add line item with inadequate translation as the hazard, and have the control measure point to the product requirement that translations undergo the process you describe. The verification of effectiveness is the usability validation.

Keep in mind that sometimes you have to retrospectively document risk management activities. You should always take credit for something you are already doing that reduced a risk.
 

ThatSinc

Quite Involved in Discussions
I don't disagree with the NB that there's a risk of inadequate cleaning as a result of poor translation of the user manual.
I disagree with the people that have updated the risk assessment to include inadequate translation is a hazard.
I see it as an initiating event that could lead to a ineffective cleaning, leading to use of a contaminated device and patient exposure to the hazard of infectious agents, leading to infection.

As a part of the control measure of implementing the instructions for use they are, by necessity of the quality system procedural requirements, translated into all applicable languages. The verification of effectiveness in regards to user comprehension is performed as part of the translation process (whether this would be considered acceptable in lieu of true usability validation is an entirely separate topic that is outside of my current scope, thankfully).

This was discussed at the time with the NB and was understood and the feedback was to "update the risk file to include it" and the way that they decided was to add it as a hazard.

Whilst it may seem like semantics, adding inadequate translation as a hazard that could lead to infection opens up a whole can of worms, you would logically need to apply the same approach to all risks where the instructions for use are mitigating a hazard and every harm that is associated with those risks would need a new line including inadequate translation as a hazard.

The whole system is currently being remediated due to more recent findings, and this previous finding has become a topic of discussion.
 
I disagree with the people that have updated the risk assessment to include inadequate translation is a hazard. I see it as an initiating event
I fully support you in this as I do agree with your point. I think this shows that you have a true grasp of the risk management standard and what each of the terms mean. I think as long as you document the translation-related risks as a hazard-related use scenarios in your usability file, you should be okay.
 

ThatSinc

Quite Involved in Discussions
My guidance has been over-ruled.

There is now a line for "inadequate instructions for use provided" with the control measure of "instructions for use provided"
and another line for "user does not understand instructions for use" with the control measure of "instructions for use provided"

Despite my guidance that both of those issues are related to inadequate effectiveness of the instructions for use control measure, identified for other hazards.

Has anybody had to manage situations like this?
It's become quite a sticking point, and I think I may have to just go with it.
 

Tidge

Trusted Information Resource
I can't tell if you have a larger team problem with lack of experience or lack of imagination. Is this still an issue where an NB doesn't trust your translations? If instead it is 'folks can't figure out your equipment', a usability validation should establish how well user classes interact with the device. It is atypical that a medical device has as part of its intended use, an explicit function for altering/updating the cognitive ability and mental models of the intended user classes.

Based on the posts here, I tend to agree that an 'inadequate translation' would be an ineffective risk control... or, if you prefer: evidence contrary to the effectiveness of a risk control. It isn't completely unheard of to occasionally update risk management files with specific lines when a particular design element fails in some spectacular/noticeable way. I have seen this done in an effort to drive more detailed analysis for the specific failure mode. I cannot recall doing this in a general way for 'translations'; however I have had some specific (new) risk controls added to a device related to the need to support characters (in a font set) used by other languages, for display of text messages on a device.
 
Top Bottom