Software in Medical Devices

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.

Software verification is easy to define: to demonstrate that software works as it was specified (and without bugs!). But there's not a unique way to do it.
Let's see what methods we have in hands to verify software.

Endeavour Agile ALM is an Open-Source solution for Agile project and resource management.

Many people make the confusion between verification and validation. There is no exception for software! I'd even say that the confusion is even worse for standalone software.

Let's see first the definition of verification and validation. I borrowed these definitions from the FDA website:

• Verification is confirming that design output meets the design input requirements,
• Validation is ensuring that the device conforms to defined user needs and intended uses.

OK, this remains theoretical. How to do that with software medical devices?
In this article I focus on verification and will focus on validation in the next article: What is software validation.

Template!
Here is a new template: the all-in-one template for software development process.
It is made for simple software development project where everything can be put in only one document. Especially, there is room for only one verification phase in the template. this is a deliberate situation. If you plan to have more than a single phase of verification, you should use other templates (link on template repository page below at the end of this post).
It contains simple and reduced parts of:

1. Project management plan,
2. Software Requirements Specifications,
3. System Architecture Document,
4. Software Tests Plan, Description and Report.

It doesn't contain the risk management data. They shall remain in the dedicated templates: Risk management plan and Risk analysis report.

More templates on my templates repository page.

Please, feel 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.

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.

In my previous post, I explained how I tweaked the waterfall model to obtain something close to agile methods. But still not agile, actually...

Reading the ISO 13485 standard doesn't helped me knowing how to manage the lifecycle of software medical devices. The QMS of a software company has to be adapted to be in conformity with ISO 13485.