ISO 14971 and Stand-Alone Diagnostic Software

milandy

Registered
Hi all -- I am really struggling with a risk analysis.

We make a stand-alone software device which is used to view echocardiograms. If, for some reason, the software fails and part of the echocardiogram is missing, a physician could potentially plan treatment with missing information. Or if, for some reason, the software fails, corrupting the images, the clinician could plan treatment with incorrect information. Both of these circumstances could, should the physician choose to treat the patient using our device as the sole means of diagnosis, lead to death.

Now, the odds of this happening are improbable. Vanishingly small.

Do I need to account for these in a 14971/62304 risk analysis?

EU and FDA say we are Class IIa and Class II respectively -- but how can this be if death is a possibility? Any cardiological intervention would lead to some sort of injury, most of the requiring medical treatment.

Can someone please clarify?
 
Last edited:

QAengineer13

Quite Involved in Discussions
Hi all -- I am really struggling with a risk analysis.

We make a stand-alone software device which is used to view echocardiograms. If, for some reason, the software fails and part of the echocardiogram is missing, a physician could potentially plan treatment with missing information. Or if, for some reason, the software fails, corrupting the images, the clinician could plan treatment with incorrect information. Both of these circumstances could, should the physician choose to treat the patient using our device as the sole means of diagnosis, lead to death.

Now, the odds of this happening are improbable. Vanishingly small.

Do I need to account for these in a 14971/62304 risk analysis?

EU and FDA say we are Class IIa and Class II respectively -- but how can this be if death is a possibility? Any cardiological intervention would lead to some sort of injury, most of the requiring medical treatment.

Can someone please clarify?
"Do I need to account for these in a 14971/62304 risk analysis?" YES, you definitely require to document the foreseeable sequence along with the potential harm/hazard along with mitigation, if any and have rating for RPN from a ISO 14971 perpective and from a IEC 62304 perspective identify what software safety class is this stand-alone software and follow the requirements for the 62304 Software safety class. Also if its complex software you need to consider having a separate software component safety class incorporated in your risk assessment document.

In addition to this you should also consider the FDA Level of Concern documentation to identify what software LOC this software would be and document the rationle.

"EU and FDA say we are Class IIa and Class II respectively " ...the Agencies in general only provide recommendation to the manufacturer and only the manufacturer can provide necessary information about their product safety and effectiveness, intended use, indication for use, reliability related to safety and effectiveness in submission documentation to appropriate agency for their clearance/ approval . So I don't understand the part you mentioning that the EU and FDA say we are Class IIa and Class II respectively "?
 

ValGal

Starting to get Involved
I agree with QAengineer13.

You must account for these hazard/harms.
Also, if you are selling you device in the EU, you must follow the 14971:2012. This means that you will need to mitigate risk As Far As Possible (AFAP) vs. the 14971:2007's As Far As Reasonably Practicable (AFARP).
Also, 2012's version expects more risk/benefit analysis activities (but there are ways to limit that burden).

Finally, my company submits 510(k)s for firms and we have been seeing tons of AIs (additional information) requests for cybersecurity risk and mitigation/controls (ANSI/AAMI/ISO/IEC TIR 80001-2 series and AAMI TIR 57).

Just something to keep in mind.
 

QAengineer13

Quite Involved in Discussions
I agree with QAengineer13.

You must account for these hazard/harms.
Also, if you are selling you device in the EU, you must follow the 14971:2012. This means that you will need to mitigate risk As Far As Possible (AFAP) vs. the 14971:2007's As Far As Reasonably Practicable (AFARP).
Also, 2012's version expects more risk/benefit analysis activities (but there are ways to limit that burden).

Finally, my company submits 510(k)s for firms and we have been seeing tons of AIs (additional information) requests for cybersecurity risk and mitigation/controls (ANSI/AAMI/ISO/IEC TIR 80001-2 series and AAMI TIR 57).

Just something to keep in mind.
Thanks ValGal, it was good point around the Cybersecurity, In addition to that I would personally consider integrating Usability related risks ( IEC/ ISO 62366) along with the risk management. The Flowchart in the IEC 62366-1:2015 is very useful in understanding the integration of Risk management ISO 14971 (decision making process) to Usability Engineering IEC 62366-1 (design and development process)
 

milandy

Registered
Thank you very much for the information. I inferred as much from reading the guidance you cited. Just to note, we have provided for not only the cybersecurity but also HIPAA hazards in our hazard analysis -- administrative safeguards are overlooked and I'm pretty sure the will be coming up in future reviews.

Back to my earlier question -- then how are Patient Physiological Monitors, even many including "Moderate" level of concern? If the foreseeable, though very improbable outcome of a malfunction of the device is death? The Level of Concern states the failure in the device can only be a Minor Injury.

A patient is in a walk-in clinic, hooked up to a patient monitor without an alarm. Say they're recovering from dehydration, so they're under observation, but not in the ICU. Monitor software malfunctions continuing to display a normal waveform, respiration or what have you. In the meantime, the patient is having some sort of event, but the doctors fail to treat patient for symptoms due to the missing information. The patient dies due to delay in treatment.

Or how can any PACS system be Moderate level of concern?

This isn't a great example but a patient goes to the doctor complaining of persistent headaches, unresponsive to other treatment. To be safe, the doctor orders an MRI. The PACS then swaps the patient's MRI for one from another patient that shows a small mass near the patient's spine. Doctor order a procedure to remove or shrink the mass. Is this a minor injury?

I'm sure someone with better knowledge of the field can easily imagine dozens of examples where the PACS showing the wrong images would lead to an adverse event. They are all possible (P1 = 1 for software after all) -- it's just that the odds of them happening are vanishingly small.

So my question is if something has never happened before, is it still a risk?
 
Top Bottom