Software safety classification

MarRz

Involved In Discussions
Hello,

I am wondering what effect indirect influences of software error have on assigning correct software safety class in case of screening test.

If we take NIPT (non-invasive prenatal test) test for pregnant women. The false positive result of software happens when an error occurs, and a test falsely shows there is a high risk of trisomy in the foetus. A doctor can suggest amniocentesis to the pregnant woman or not (based on the other information he has). If the woman decides on amniocentesis, it is an invasive procedure that has a 1% possibility of miscarriage.

What would be your thoughts on which safety class this SW fall into? Sure, it can lead to death, but the test itself is screening, and there are external factors which must be met to lead to the worst case (doctor recommends a diagnostic test, a woman decides to go, the procedure is one of 1% that can lead to death). Do this "indirect" consequences influence the class?
 

yodon

Leader
Super Moderator
Might want to give Annex H in 24971 a read - it's dedicated to addressing risk management for IVDs. Section H.2.4 talks about potential harms and poses a number of questions to consider. I think that if you establish your severity rankings by addressing the questions, you'll at least be in a defensible position. Based on what you describe, the likelihood of specific action based on just the output is unlikely so you can probably cap the severity scoring at a lower level.
 

MarRz

Involved In Discussions
Thanks for the suggestion. I read Annex H in 24871. It provided me with a better understanding of the topic. Our risk table, up to now, only estimates probability, not P1 x P2, as suggested in the standard. I will research it more and probably change the risk table to be that way.

I have also been researching through other sources, and sometimes it said indirect influence for injury will lover the risk to B, but other sources said regarding it being indirect or direct, the class will be C.

Still no clear answer, but I guess at least with improving the risk table, we will go in a better direction.
 

Tidge

Trusted Information Resource
It has been more typical of my experience that "diagnostic" software that is not part of an immediate procedure and is distinct from medical equipment used in an actual medical procedure is usually of lower risk than whatever the highest risk of the procedure might be. There are exceptions.(*1)

I can't offer a pleasing or reassuring rationale for why this is the case. My personal belief is that the default beliefs (of just about everyone: medical professionals, patients, regulators, politicians, et al.) are that medical outcomes are incredibly hard to predict because of the individual nature of patients and the circumstances of direct intervention (medical professionals, etc.). There is also no specific, recognized authority that has assigned particularly risk profiles for diagnostic software.

(*1) The one exception I can think of in the USA is for software involved with the management of blood and blood products, because of HIV/AIDS. This type of software should be recognized as the highest risk classification, but this is specifically because of political considerations, not 62304/14971 considerations. The directives for these types of softwares were put in place prior to the versions of 14971/62304 in use today... so while there can be post hoc rationalizations in risk management files to explain these types of software as Class C, I don't think those sorts of rationalizations would be necessarily appropriate for all other types of medical device software.
 
Top Bottom