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.
 
Elsmar Forum Sponsor

Tidge

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

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

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

QA RA Small Med Dev Company
Trusted Information Resource
#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)?
 
Thread starter Similar threads Forum Replies Date
L Unacceptable risk for basic safety prior to or after mitigation? IEC 60601 - Medical Electrical Equipment Safety Standards Series 2
U Defining Essential Performance to Achieve Freedom from Unacceptable Risk IEC 60601 - Medical Electrical Equipment Safety Standards Series 15
G 2 Unacceptable GR&Rs - What instrument to use? General Measurement Device and Calibration Topics 15
C Measurement BIAS Study - No Measurement Variation Unacceptable? Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 3
M Unacceptable Corrective Actions in a Problem Solving Summary Form - Examples? Nonconformance and Corrective Action 3
D Stable process but the average baseline is unacceptable Statistical Analysis Tools, Techniques and SPC 8
M Supplier completed CAR (Corrective Action Request) is unacceptable Nonconformance and Corrective Action 16
B ISO 17025:2017 risk management Risk Management Principles and Generic Guidelines 0
Q FMEA and Risk assessment in MS ACCESS FMEA and Control Plans 2
I Realization processes input into overall risk ISO 14971 - Medical Device Risk Management 2
M Need Help With Information Security Asset Risk Register IEC 27001 - Information Security Management Systems (ISMS) 2
thisby_ Post Market/Production Risk Assessment ISO 14971 - Medical Device Risk Management 0
S Risk Management Review ISO 14971 - Medical Device Risk Management 4
D Low risk IVD study in the UK, do I need MHRA approval? UK Medical Device Regulations 1
S Risk Management and other Files ISO 14971 - Medical Device Risk Management 8
silentmonkey Overall Benefit/Risk Analysis - Risk Management VS Clinical Evaluation ISO 14971 - Medical Device Risk Management 3
N ISO 27001 for Jumb Burger - Risk Assessment sheet IEC 27001 - Information Security Management Systems (ISMS) 11
C Risk Assessment Tools ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
qualprod Examples to mitigate risk from Covid ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
G Risk of stopping your customer's line IATF 16949 - Automotive Quality Systems Standard 4
C Risk Matrix vs FMEAs ISO 14971 - Medical Device Risk Management 5
S IVD risk class II devices for Brazil and MDSAP Other Medical Device Regulations World-Wide 0
M ISO 14971:2019: Criteria for overall residual risk ISO 14971 - Medical Device Risk Management 6
M ISO14971:2019 - Verification of implementation and effectiveness of risk control ISO 14971 - Medical Device Risk Management 3
Aymaneh Medical Device Cybersecurity Risk Management IEC 27001 - Information Security Management Systems (ISMS) 2
S Traceability of requirements to design and risk Design and Development of Products and Processes 3
R Risk control measures as per ISO 14971 ISO 14971 - Medical Device Risk Management 6
D Deciding whether or not pre-market clinical investigation is required for low risk device EU Medical Device Regulations 5
R The term "Benefit Risk Ratio" in EU MDR, do I need to present benefit risk analysis as a RATIO Risk Management Principles and Generic Guidelines 4
_robinsingh Security Risk Assessment Tool IEC 27001 - Information Security Management Systems (ISMS) 0
A 21 CFR 820 - Risk Management - Looking for some guidance US Food and Drug Administration (FDA) 3
bryan willemot Contract Review and risk managment AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 2
D Risk Analysis using Monte Carlo Simulation instead of Scoring and Heat Map Risk Management Principles and Generic Guidelines 2
Sravan Manchikanti Software Risk Management & probability of occurrence as per IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 8
E Normal Condition Hazards in Risk Analysis ISO 14971 - Medical Device Risk Management 3
silentmonkey Rationalising the level of effort and depth of software validation based on risk ISO 13485:2016 - Medical Device Quality Management Systems 10
R Risk assessment on IT containers and the information they contain IEC 27001 - Information Security Management Systems (ISMS) 4
B Threat/Vulnerability Catalogue for risk assessment IEC 27001 - Information Security Management Systems (ISMS) 4
R Opportunity For Improvement vs Opportunity (Positive Risk) ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 18
R FOD Risk Assessment - What tools would you recommend for assessing FOD risk? AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 1
R Identify Medical Device characterstics as Annex C of ISO 14971 Risk Management ISO 14971 - Medical Device Risk Management 5
A ISO 14971 PFMEA Manufacturing Risk ISO 14971 - Medical Device Risk Management 2
Q Example of the Risk Template Document Control Systems, Procedures, Forms and Templates 1
K Overall residual risk according to ISO 14971:2019 ISO 14971 - Medical Device Risk Management 5
A Risk Number for each software requirement IEC 62304 - Medical Device Software Life Cycle Processes 7
A IEC 60601 11.2.2.1 Risk of Fire in an Oxygen Rich Environment, Source of Ignition IEC 60601 - Medical Electrical Equipment Safety Standards Series 0
D Importing a general wellness low risk product Other US Medical Device Regulations 3
C Quantifying risk in choosing the number of parts, operators and replicates in a GR&R Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 4
R AQL, Consumer Risk and MA Statistical Analysis Tools, Techniques and SPC 2
M Risk managment report of Surgical Mask Example ISO 14971 - Medical Device Risk Management 14

Similar threads

Top Bottom