Software Safety Classification

[Tidge]

... but I have found many clients trying to push this kind of use case as "A" (your diagnosis is only a small part of the picture) which I don't think is consistent with "why does this software even exist then".

I've had this exact conversation, and it never lands well. I try to steer the conversation more towards "why would the patient even want this software and how much damage could it do to them?" to try to keep things closer to a benefit-risk perspective rather than a sales-marketing perspective.

 

[michael Cejnar]

I am struggling with FDA Premarket-Software Submission-Guidance 2023's requirement to classify Documentation Basic vs Enhanced by Software risk. where "risk(s) should be assessed prior to implementation of risk control measures". (also I know probabilities are set for 1.0 for this categorization only - no problem)
We have hardware with inherently safe design (ISD) risk control measures, where - for example, output current amplitude and duration is limited in hardware against software failure. The limitation is stated as a Mitigation.
I don't see why we would or could remove this risk control for categorizing software documentation LOC. And if so, where does it end - haw far above the hardware's ability do you analyze?

All the FDA's helpful examples of risk control measures in that guidance involve software mitigations - which I agree should be assumed to fail and not be considered.

Will this rationale fly? "We therefore interpret the guidance to mean that when determining Software Documentation Level of Concern (LOC) for FDA 510(k) submission involving software, implemented intrinsically safe hardware designs are inherent to the medical device and are not removable risk control measures for the purpose of determining software documentation LOC"

 

[DanMann]

I'd appreciate others opinions, but it does look like this is a risk determination based solely on severity, not on any measurement of probability, which would mean discounting the hardware risk mitigations.
My questions about your device would be how high is the input amplitude (and what effect would that have on a person) and what condition is it intended to treat (and what effect if it does nothing or if this makes sense, does the opposite of what would be helpful)?

 

[Tidge]

haw far above the hardware's ability do you analyze?

All the FDA's helpful examples of risk control measures in that guidance involve software mitigations - which I agree should be assumed to fail and not be considered.

Will this rationale fly? "We therefore interpret the guidance to mean that when determining Software Documentation Level of Concern (LOC) for FDA 510(k) submission involving software, implemented intrinsically safe hardware designs are inherent to the medical device and are not removable risk control measures for the purpose of determining software documentation LOC"

I wouldn't use that wording, because it is explicitly asking the regulatory reviewer to think about your interpretation of the guidance as opposed to reviewing your design and coming to an interpretation of your development efforts.

As far as "how far to go?"... If I was reviewing the system, I'd want to see evidence that:

1) The software system is not responsible for necessary risk reduction
2) The software system cannot introduce unacceptable risks

 

[DanMann]

I am struggling with FDA Premarket-Software Submission-Guidance 2023's requirement to classify Documentation Basic vs Enhanced by Software risk. where "risk(s) should be assessed prior to implementation of risk control measures". (also I know probabilities are set for 1.0 for this categorization only - no problem)
We have hardware with inherently safe design (ISD) risk control measures, where - for example, output current amplitude and duration is limited in hardware against software failure. The limitation is stated as a Mitigation.
I don't see why we would or could remove this risk control for categorizing software documentation LOC. And if so, where does it end - haw far above the hardware's ability do you analyze?

All the FDA's helpful examples of risk control measures in that guidance involve software mitigations - which I agree should be assumed to fail and not be considered.

Will this rationale fly? "We therefore interpret the guidance to mean that when determining Software Documentation Level of Concern (LOC) for FDA 510(k) submission involving software, implemented intrinsically safe hardware designs are inherent to the medical device and are not removable risk control measures for the purpose of determining software documentation LOC"

Another thought that's less compliance and more strategic - how much extra effort would it be to generate the extra documentation? Vs how much of a problem is rejection by the FDA if they don't accept your rationale? Might a pre-sub be worthwhile to see if they agree? (And will you share the outcome with us all if you do?)

 

[michael Cejnar]

I'd appreciate others opinions, but it does look like this is a risk determination based solely on severity, not on any measurement of probability, which would mean discounting the hardware risk mitigations.
My questions about your device would be how high is the input amplitude (and what effect would that have on a person) and what condition is it intended to treat (and what effect if it does nothing or if this makes sense, does the opposite of what would be helpful?

Thanks DanMann
Yes, the Software Documentation level determination (Basic vs Enhanced) is done assuming 100% probability of all Sw failures modes (but the Sw FMEA uses actual estimated risks).
But the FDA guidance does not state explicitly that you should assume hardware mitigations should be assumed to be 100% ineffective for this documentation estimation - and it would not make any sense, in my view.
Even if you do estimate prior to bolted-on hardware mitigations added for Sw failures, I don't see why or how you can estimate prior to intrinsically safe hardware design.
The device is a diagnostic cardiac stimulator Class IIb - where for above example, Sw failure could try to program higher than intended current, but hardware configuration limits it.

 

[DanMann]

Thanks DanMann
Yes, the Software Documentation level determination (Basic vs Enhanced) is done assuming 100% probability of all Sw failures modes (but the Sw FMEA uses actual estimated risks).
But the FDA guidance does not state explicitly that you should assume hardware mitigations should be assumed to be 100% ineffective for this documentation estimation - and it would not make any sense, in my view.
Even if you do estimate prior to bolted-on hardware mitigations for Sw failures, I don't see why or how you can estimate prior to intrinsically safe hardware design.
The device is a diagnostic cardiac stimulator Class IIb - where for above example, Sw failure could try to program higher than intended current, but hardware configuration limits it.

It doesn't explicitly say to assume hardware measures are ineffective, but it does say "prior to risk control measures", which without further guidance, I would default to reading as "prior to ANY risk control measures".
I'm reading this as saying that if your hazard log has a hazard due to software failure with a harm severity level that comes under the definition of death or serious injury, then regardless of the probability, your product needs enhanced documentation and I can't see anything that conflicts with this other than this not being the method for safety classification under 62304.
I'm terms of why this approach - not sure. I get the logic on 62304 because it says that you can't rely on software controls when you're approaching how closely you need to monitor development of that same software; perhaps in this case the FDA are looking to reduce the complexity in determining the safety classification - I know arguments about software safety level are common and that the 62304 approach often leads to a need to consider probability of harm after hardware controls but before software controls, which means an extra "interim" risk evaluation added to the risk management process.

 

[michael Cejnar]

I wouldn't use that wording, because it is explicitly asking the regulatory reviewer to think about your interpretation of the guidance as opposed to reviewing your design and coming to an interpretation of your development efforts.

As far as "how far to go?"... If I was reviewing the system, I'd want to see evidence that:

1) The software system is not responsible for necessary risk reduction
2) The software system cannot introduce unacceptable risks

Yes, I should probably not tell FDA what they meant to say
But your review seems to align with my interpretation "The software system is not responsible for necessary risk reduction". - i.e. I feel FDA guidance should state "prior to implementation of 'software' risk controls, but with implemented independent hardware risk controls.'

It doesn't explicitly say to assume hardware measures are ineffective, but it does say "prior to risk control measures", which without further guidance, I would default to reading as "prior to ANY risk control measures".
I'm reading this as saying that if your hazard log has a hazard due to software failure with a harm severity level that comes under the definition of death or serious injury, then regardless of the probability, your product needs enhanced documentation and I can't see anything that conflicts with this other than this not being the method for safety classification under 62304.
I'm terms of why this approach - not sure. I get the logic on 62304 because it says that you can't rely on software controls when you're approaching how closely you need to monitor development of that same software; perhaps in this case the FDA are looking to reduce the complexity in determining the safety classification - I know arguments about software safety level are common and that the 62304 approach often leads to a need to consider probability of harm after hardware controls but before software controls, which means an extra "interim" risk evaluation added to the risk management process.

"without further guidance" - well they did give further guidance with lots of examples, which were all software mitigations (but that's not definitive, of course)
As for reducing complexity, what is simpler than discounting a Sw risk that is made impossible my inherently safe hardware design.
But maybe, I am overthinking it.
If we use hardware that limits the output current in the first place (Inherently Safe Design), then there is no Software failure mode risk of excessive current any more than there is a risk of emitting unicorns. It is irrelevant what was in my mind when I designed the ISD hardware in the first place to limit the current because I would not want to trust the Software to limit it.

It boils down to: is Inherently Safe Hardware Design a Risk Control measure to be removed during analysis or an inherent property of device which does not come into Sw risk analysis - any more than a risk of emitting , say, X-rays.

 

[DanMann]

It boils down to: is Inherently Safe Hardware Design a Risk Control measure to be removed during analysis or an inherent property of device which does not come into Sw risk analysis - any more than a risk of emitting , say, X-rays.

My reading of the guidance, the answer to this is that the inherently safe hardware design is a risk control to be removed.

 

[michael Cejnar]

Not the answer I wanted but appreciated.