Search the Elsmar Cove!
**Search ALL of Elsmar.com** with DuckDuckGo including content not in the forum - Search results with No ads.

Unacceptable risk and information for safety

MrTetris

Involved In Discussions
#1
Hello everybody, consulting this forum helped me to clarify a lot of cases, so I hope that it will be the same this time as well.
The company where I am currently working develops medical software products for making surgical planning.
One of the risks listed in the risk charter is defined as following (not exactly to be honest, but the case is very similar):
Hazard: unauthorized persons can access unattended pc showing the surgical plan
Failure mode: the unauthorized person can modify the surgical plan
Harm: patient's diagnosis and treatment are based on a wrong surgical plan
Occurrence: 3; Severity: 4; Detectability: 3; RPN: 36 (unacceptable)
Control measure implemented: information for safety: an indication for use is added to IFU's: "use the sw in a controlled, protected environment. Restrict access to our sw to authorized people only".
My problem is that this control measure is clearly information for safety, so according to IEC 14971 it cannot be used to reduce risk indexes.
But how can we control access to a pc, if not relying on user's conformity to our IFU's?
Do you see any solution to lower the risk indexes, other than justify the unacceptable RPN with the motivation that the risk is balanced with benefits?
Thank you in advance for your answers.
 

Tidge

Involved In Discussions
#2
First (because I can't help myself): Hazards are generally *physical* things which lead to harms (e.g. fire, electricity, kinetic energy, infectious agents). "Access to the plan" is more like a contributing factor to a Hazardous Situation. Now to answer your question for this specific circumstance:

Without redesign (to introduce controls), I don't see an immediate mechanism to reduce this particular risk. Even so, I would encourage your team to identify relevant design choices (in addition to IFS) as risk controls even if those choices don't reduce RPNs. Identifying design choices can inform a risk benefit analysis (RBA) in a meaningful way.

For your software: if it is designed to run on an operating system that requires 2-factor authentication for login this would not necessarily reduce the RPN for this type of line (especially if you cannot guarantee this), but in conjunction with IFS may contribute to an acceptable outcome.

Possible (re)design choices that could (YMMV) reduce this risk include:
  • The software itself could require two-factor authentication for use
  • The software can present an audit trail of changes to the plan
  • The software could require a comment be made upon every change to the plan
  • The software could restrict users from using the software from authorized locations
  • (extending several of the above points) the software could treat the surgical plans as a document with a life-cycle with phase transitions controlled via specified approvals.
 

Tagin

Quite Involved in Discussions
#3
But how can we control access to a pc, if not relying on user's conformity to our IFU's?
A locked enclosure for the PC, or at least a locked drawer for the keyboard & mouse?

Otherwise, the controls should be designed into the software. You could require that modification of plans requires a Yubikey or equivalent to be present to authenticate the user as authorized to modify plans. Otherwise, users would have read-only access.
 

MrTetris

Involved In Discussions
#5
@MrTetris
Are you doing this in pursuit of MDR compliance? MDD? Other?
I need my risk management charter to be compliant with MDD, MDR and FDA.
To be more specific, I asked this question referring to Annex ZA of the IEC 14971, which addresses gaps between the standard and the MDD, specifying that manufacturers shall not attribute any additional risk reduction to the information given to the users. So I am afraid that the only possible solution is the one given by Tidge: redesign of the sw.
Tagin suggestion to lock the pc or the keyboard/mouse would be translated in a IFU update, which will not solve my problem (RPN cannot be lowered using IFS controls).
Thank you all for your answers!
P.S.: for completeness, I believe that the root cause of the issue in this case was an overestimation of the initial indexes, and I will address this in a future meeting in my company.
 

Ronen E

Problem Solver
Staff member
Super Moderator
#6
I need my risk management charter to be compliant with MDD, MDR and FDA.
For completeness too:

I'm not sure why you refer to the standard as "IEC 14971"; clearly the version you relate to is EN ISO 14971:2012.

What Annex ZA actually conveys is that compliance with the normative part (identical to ISO 14971:2007) alone doesn't satisfy the risk management requirements of the MDD. There's an unresolved (fierce) debate on whether the MDD actually bans (or intends to ban) the supply of information for safety as a risk mitigating means.

The MDR doesn't yet have any standards harmonised under it, so ISO 14971 (any version) doesn't (yet) play any official role here, definitely not mandatory. The MDR GSPR 4 (Annex I) prescribes the following order of precedence for addressing unacceptable risks:
(a) eliminate or reduce risks as far as possible through safe design and manufacture;
(b) where appropriate, take adequate protection measures, including alarms if necessary, in relation to risks that cannot be eliminated; and
(c) provide information for safety (warnings/precautions/contra-indications) and, where appropriate, training to users.
So any reliance on information for safety (c) is only acceptable after (a) and (b) have been attempted, I would say at least to a reasonable extent. This doesn't seem to be the situation in the case you presented.

The FDA doesn't usually require an ISO 14971-style risk management.
 

Tobias_HF

Starting to get Involved
#8
Hi,
I`m hopping on the re-design train, hope it didn`t leave already.... ;-)
So I am afraid that the only possible solution is the one given by Tidge: redesign of the sw.
We solved a similar problem (treatment planning) by having users sign off with their password, once they wanted to make a change. This was also stored in the audit trail.
We had different roles who could plan the treatment, and also a kind of busy use environment (nurses, doctors, techs..). But someone in charge had to sign off all changes.
Honestly, from a usability perspective: not cool. workflows were often interrupted by the password dialogue.
From a risk perspective: probably quite good.
 

Ed Panek

VP QA RA Small Med Dev Company FDA and ISO13485:16
Trusted
#9
Help me understand. Is this risk unique to your device? Does this exist for other "devices" already approved by regulators (even those not of your own or other modalities)?
 
Top Bottom