Software in Medical Devices, by MD101 Consulting

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.

Congratulations! You have signed a contract with a medical devices manufacturer. They don't have a very good knowledge of software. They rely on you to develop something brand new on a smartphone. The application they want to develop will bring new functionalities to doctors and let them do their jobs faster. Your customer chose you because you are the specialist of software on every OS’es on smartphones. You ensured him that your company can be in conformity with IEC 62304 standard. To that purpose, you modified and added the necessary procedures and forms to your quality system. You have one year to develop the application, which fits their desires … and the medical devices standards!

The homologation of a medical device is a complex task and can become a nightmare with devices with a high level of risk. It involves many standards and regulations, different from one country to another: FDA in the USA, CE Mark in Europe, CMDCAS in Canada, KFDA in South Korea, and so on …

Fortunately, most of these regulations have common requirements and rely on ISO standards, the most important standards being ISO 13485 and ISO 14971. If you meet the requirements of these standards, you increase your chances of passing the homologations for the devices with low risk. For devices with high risk, these standards are (almost) mandatory.