Software in Medical Devices, by MD101 Consulting

Manufacturers of medical devices often ask themselves the obvious question:
Is it mandatory to be compliant both with IEC 60601-1 and IEC 62304?

Similarly, manufacturers of in vitro diagnosis devices ask themselves:
Are my devices in the scope of IEC 62304?

Obviously, medical devices (MD) with electric or electronic components are in the scope of IEC 60601-1. And in-vitro diagnosis devices (IVD) with electric or electronic components are in the scope of IEC 61010-1.

Do MD and IVD that embed software, fall in the scope of IEC 62304?
This is not so obvious.

Most of medical devices manufacturers have legacy software that was not designed according to IEC 62304. The devices that embed legacy software were once verified and validated. These devices and their software work well and no major adverse event were raised by software issues.
But one day, the manufacturer decides that it's time to bring that legacy software into line with IEC 62304, to align the technical file of that software (or the contribution of software to technical file content) with up-to-date standard or regulatory requirements.

In two previous articles, I talked about the differences of bugs, software failures, and risks.
I left the discussion unfinished about the probability of occurence of a software failure or a defect.
I think that assessing the probability of occurence of a software failure is a hot subject. I've already seen many contradictory comments on this subject. It's also a hot subject for software manufacturers that are not well used to risk assessment.

A bug can lead to a software failure.
Having bugs is a risk.
Having a software failure is a risk.
A software failure is not necessarily a bug!

Do you follow me?
If not, let me give you some more explanations.

We've seen in my last post that it's possible to have agile development methods combined with a risk management process. To be compliant with ISO 14971 standard, a risk management plan that describes this process along iterations, has to be written. And a risk assessment report has to be created in iteration 0 and updated in every iteration, by following the risk management process like the one found in figure 1 or figure B.1 of ISO 14971 standard.

This post comes after a series of three posts where I exposed my thoughts about development of software medical devices with agile methods.
These posts were focussed on software development. Risk management deserves its own series of posts. Here is the first of three.

IEC 62304 defines three safety classes for software:

• Class A: No injury or damage to health is possible
• Class B: Non-SERIOUS INJURY is possible
• Class C: Death or SERIOUS INJURY is possible

Here comes the eternal question: Which class my software belongs to?

Templates section wouldn't be a templates section without something about risk analysis. Error repaired!

Here is the Risk Analysis Report Template. It contains sections compliant with IEC 62304, IEC 62366 and ISO 14971. It is best used in conjunction with the SRS template.

Please, fell free to give me feedback on my e-mail contact@cm-dm.com

I share this template with the conditions of CC-BY-NC-ND license.

A lot of standards and regulations exist about medical devices: how to design, to produce, to sell, to monitor their use … Everything about each step in the life of devices, from the initial idea 10 years before selling anything, to the archiving of records 10 years after the last item has been sold. A lot of specific standards or guidances on how applying medical devices standards exist about software. That’s the consequence of software being very specific (I should say peculiar), compared to other components in medical devices. Conception is the most critical part in the lifecycle of software. Software is never 100% finished, user always want enhancements and modifications.

From my own experience in the field, I gathered 5 basic recommendations you should follow.