Examples of inherent safety by design

#11
Hello guys, this is my very first post!

We are developing a diagnostic device that senses some electrical signals from the patient via surface electrodes.
Our team is discussing risks related to motion artifacts, loss of contact, and all the problems that come when sensing electrical signals through surface electrodes. From an engineering perspective we put in place software algorithms to detect anomalies on the readings and dismiss noisy or useless signals. Each time that the algorithm detects a problem, a warning message is presented on the screen and the readings are discarded.

The problem is that we are not quite sure about what kind of risk mitigation can we claim under this approach. The arguments within the team are for claiming ‘inherent safety’ are:

Arguments in favour of regarding this measure as ‘inherent safety’:
-Preventing noisy/useless from entering the algorithms that calculate the clinical information that the device is intended to provide is inherent safe, since no clinical information is presented on the screen and physicians would not make clinical decisions based on the information presented by the device.

Arguments disfavouring ‘inherent safety’:
-This measure is implemented through a software algorithm and software should not be used to mitigate risks.
-If no information is presented to the user, then the decision-making process can be affected resulting in a new risk.
How would you classify this approach? Would you say this is ‘inherent safety’ or just a ‘protective measure’?

I have reviewed the standards several times and I acknowledge lack of experience. I am also aware of the fact that auditors should request for evidence of training and experience. That’s part of reason for which I joined this community.

Thank you in advance :)
 
Elsmar Forum Sponsor

yodon

Staff member
Super Moderator
#13
Congratulations on your first post and welcome!

-This measure is implemented through a software algorithm and software should not be used to mitigate risks.
Where did this come from? There are plenty of cases where software can mitigate a risk. For example, on an infusion pump, a user could enter a dose rate that is way beyond safe limits; however, the software only allows a safe limit range. In your case, having the software discard the 'useless' signals would seemingly also be an example. (You also have the protective measure of alerting the user)
 
#14
Hello Marcelo,

Thank you for the incredibly quick response to my question.

During our engineering discussions we have not (yet) found a way to mitigate this risk through ‘inherent safety’ and we are afraid that we won’t be able to do so in the near future. This leaves us with only two alternatives for mitigation, which of course are ‘protective measurements’ and ‘information for safety’.

However, failing to provide ‘inherent safety’ seems contrary to Section 2 of Annex 1 of Directive 93/42/EEC (please let’s forget about the oncoming MDR for a moment). As far as I understand, we must apply the ALL control options ‘cumulatively’ until additional endeavours do not improve safety.

In this regard, I am not quite sure if we can presume compliance by mitigating this risk only through ‘protective measurements’ and ‘information for safety’ and a good risk/benefit rationale.

By the way, it seems to me that this risk is quite common to all diagnostic devices that need to be in ‘good contact’ with the body of the patient. In my experience all of them use similar approaches to deal with this risk. I cannot identify any ‘inherent safe’ mitigation in these devices.
 

Marcelo

Inactive Registered Visitor
#15
Hello Marcelo,

Thank you for the incredibly quick response to my question.

During our engineering discussions we have not (yet) found a way to mitigate this risk through ‘inherent safety’ and we are afraid that we won’t be able to do so in the near future. This leaves us with only two alternatives for mitigation, which of course are ‘protective measurements’ and ‘information for safety’.

However, failing to provide ‘inherent safety’ seems contrary to Section 2 of Annex 1 of Directive 93/42/EEC (please let’s forget about the oncoming MDR for a moment). As far as I understand, we must apply the ALL control options ‘cumulatively’ until additional endeavours do not improve safety.

In this regard, I am not quite sure if we can presume compliance by mitigating this risk only through ‘protective measurements’ and ‘information for safety’ and a good risk/benefit rationale.

By the way, it seems to me that this risk is quite common to all diagnostic devices that need to be in ‘good contact’ with the body of the patient. In my experience all of them use similar approaches to deal with this risk. I cannot identify any ‘inherent safe’ mitigation in these devices.
They are options, you are not expected to apply them all the time because it may not be possible. In particular, the idea of the order of priority is:

- Is it possible to apply an inherit safety by design solution? If not, is it possible to apply a protective measure? If not, is it possible to apply information for safety?

It's basic risk management (from some 50-100 years ago), nothing new here.
 
#16
Congratulations on your first post and welcome!



Where did this come from? There are plenty of cases where software can mitigate a risk. For example, on an infusion pump, a user could enter a dose rate that is way beyond safe limits; however, the software only allows a safe limit range. In your case, having the software discard the 'useless' signals would seemingly also be an example. (You also have the protective measure of alerting the user)
Hello Yodon, thank you for challenging the statement about using software to mitigate risks!

My understanding is that the probability of software risks shall always be assumed to be 1, so if a risk is being mitigated through software, the likelyhood of failure would also be 1, rendering the mitigation inappropriate.

Please let us know your thoughts on this.
 
#17
They are options, you are not expected to apply them all the time because it may not be possible. In particular, the idea of the order of priority is:

- Is it possible to apply an inherit safety by design solution? If not, is it possible to apply a protective measure? If not, is it possible to apply information for safety?

It's basic risk management (from some 50-100 years ago), nothing new here.
I totally agree, it's basic risk management that has been around for ages. However the semantics of the MDD and Annex ZA are a bit confusing and in some cases counterintuitive.

I guess that my main question comes from the following text in Annex ZA:

"Accordingly, the manufacturer must apply all the "control options" and may not stop his endeavours if the first or the second control option has reduced the risk to an "acceptable level" (unless the additional control option(s) do(es) not improve the safety). "

The core of my question comes from the statement "MUST APPLY ALL THE CONTROL OPTIONS".
 

Marcelo

Inactive Registered Visitor
#19
My understanding is that the probability of software risks shall always be assumed to be 1, so if a risk is being mitigated through software, the likelyhood of failure would also be 1, rendering the mitigation inappropriate.
.
The general idea (at least, from the standpoint of IEC 62304), is that the software failure (which is part of the sequence of events leading to the hazardous situation) is 1, not that the risk is 1. They are two different things.
 

yodon

Staff member
Super Moderator
#20
"Accordingly, the manufacturer must apply all the "control options" and may not stop his endeavours if the first or the second control option has reduced the risk to an "acceptable level" (unless the additional control option(s) do(es) not improve the safety). "
The intent here is to ensure you mitigate risks "As Low As Possible" (ALAP). There's no such thing as "As Low As Reasonably Practicable" (ALARP) with this release of the standard.
 
Thread starter Similar threads Forum Replies Date
M Examples of Combination Products - MDR Article 1 (8) and MDR Article 1(9) Medical Device and FDA Regulations and Standards News 3
M Combination products - examples CE Marking (Conformité Européene) / CB Scheme 1
qualprod Examples to mitigate risk from Covid ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
B Two excellent examples of process capability analysis from Quality Magazine Capability, Accuracy and Stability - Processes, Machines, etc. 5
U Examples of Quality Objectives for a Medtech start up ISO 13485:2016 - Medical Device Quality Management Systems 4
B ITAR Visitor Log Examples AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 1
J Process FMEA Template with examples - Cold and Hot Forged components FMEA and Control Plans 4
R DFA & DFM - Examples for Design for assembly and design for manufacturability Lean in Manufacturing and Service Industries 2
E Non-GMP examples in Pharmaceutical industry Pharmaceuticals (21 CFR Part 210, 21 CFR Part 211 and related Regulations) 2
I Quality Policy and Objectives examples Elsmar Cove Forum Suggestions, Complaints, Problems and Bug Reports 5
Y Examples of TRB Reports for MIL-PRF-31032 Qualification AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 0
G Any good examples of CAPA forms that include a risk based approach? ISO 13485:2016 - Medical Device Quality Management Systems 8
I ISO 22000:2018 - Operational Prerequisite Program Examples Food Safety - ISO 22000, HACCP (21 CFR 120) 2
S Examples of software changes that required a 510k US Food and Drug Administration (FDA) 2
W SOP examples wanted - Soil, Concrete and Asphalt testing ISO 17025 related Discussions 3
M Where can I find examples of PPAP? APQP and PPAP 6
O Examples of Critical process parameter (CPP) and Critical quality attribute (CQA) Manufacturing and Related Processes 2
S AS9100D PEAR - Examples for organization's method for determining process results? AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 5
L IATF 16949 8.3.3.2 FCA (Fiat Chrysler) Specific Requirements - Examples of AQR and MPFMEA Service Industry Specific Topics 1
L IATF 16949 Warranty Management System examples IATF 16949 - Automotive Quality Systems Standard 0
A Examples of Pre-Sub, SRD, PMA Shells and Templates Other US Medical Device Regulations 3
S IAF Codes - Examples of what falls under each code General Information Resources 2
O Examples of the external and internal issues and their risks and opportunities IATF 16949 - Automotive Quality Systems Standard 2
M Medical Device Traceability Matrix - Examples EU Medical Device Regulations 8
P Examples of Nonconformance, Corrective Action Requests, and Root Cause Analysis Nonconformance and Corrective Action 2
Ajit Basrur Looking for examples of "User Training" - ISO 13485 section 7.2.1 d) ISO 13485:2016 - Medical Device Quality Management Systems 6
S Manufacturing Work Instruction examples that include process pictures Manufacturing and Related Processes 3
G Uncertainty Budget Examples for Caliper, Micrometer and Dial Gauge Measurement Uncertainty (MU) 3
Albert G. What are general examples of audit findings with ISO 9001:2015? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 15
Q Risks Examples in Top Management ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
R ISO 13485:2016 - Quality Objectives Regulatory Requirement Examples ISO 13485:2016 - Medical Device Quality Management Systems 1
Sidney Vianna Blockchain Technology - Any examples of practical application? The Reading Room 21
Z SAP Validation for Part 11 Compliance - Examples (executed protocols) Qualification and Validation (including 21 CFR Part 11) 3
M How to Document Internal & External Communications - Suggestions/examples pls IATF 16949 - Automotive Quality Systems Standard 3
Y Examples of Risk and Opportunities based on ISO 9001:2015 ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 2
R Examples of Quality Objectives related to ISO 13485:2016 ISO 13485:2016 - Medical Device Quality Management Systems 6
M CAAC-145 Manuals - Looking for examples of MOM's, MMM's Capability Lists, etc. Federal Aviation Administration (FAA) Standards and Requirements 13
D Seeking Corrective Action Process Examples Nonconformance and Corrective Action 3
P ISO 9001:2008 Design and Development Process & Forms examples wanted Design and Development of Products and Processes 3
K AS9100 5.3 Authorities (Looking for examples) AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 3
B Risk Requirements to meet the explicit Risk Based Approach of ISO 13485:2016 Examples ISO 13485:2016 - Medical Device Quality Management Systems 21
F ISO 14001:2015 EMS Procedures and Form Examples wanted ISO 14001:2015 Specific Discussions 10
K EN ISO 15223-1:2012 Clarification or Examples on when to use Safety Symbols Other Medical Device Related Standards 3
A SIPOC (Suppliers Inputs Process Outputs Customers) examples wanted Quality Manager and Management Related Issues 1
A AS 9100 - Risk Management Procedure and Flow Chart examples AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 4
A Aseptic Sampling Procedure Examples (Syringe and Dipper) wanted Manufacturing and Related Processes 1
S Customer Scorecard Analysis Templates and Examples IATF 16949 - Automotive Quality Systems Standard 3
H Root Cause Corrective Action Examples Nonconformance and Corrective Action 4
S Seeking examples of Nonconforming Materials Nonconformance and Corrective Action 5
C Need examples for Controlled Shipping I and II (CSL) IATF 16949 - Automotive Quality Systems Standard 3

Similar threads

Top Bottom