Examples of inherent safety by design

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

A warning message requires that someone do something, so this cannot be inherit safety design (in which the device itself "solves"the problem. See some generic examples (not directly tied to Iso 14971, but ISO 14971 uses these from literatura anyway) attached.

Congratulations on your first post and welcome!

Nicholas Tish said:

-This measure is implemented through a software algorithm and software should not be used to mitigate risks.

Click to expand...

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 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.

Nicholas Tish said:

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.

Click to expand...

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.

yodon said:

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)

Click to expand...

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.

Marcelo Antunes said:

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.

Click to expand...

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".

Annex ZA from the 2012 version is full of incorrect technical comments, so there's no way to comply with it.

Nicholas Tish said:

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.
.

Click to expand...

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.

Nicholas Tish said:

"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). "

Click to expand...

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.