Software in Medical Devices, by MD101 Consulting

We had in a previous article an overview of IEC 82304-1 Health software -- Part 1: General requirements for product safety, its scope and its relationships with other standards like IEC 62304.
This article presents more in details (but not too much, we're not going to rephrase the standard) the requirements of IEC 82304-1.

We continue this series on validation of software used in production and QMS with the Validation Protocol and Reports.

After a temporary absence, I'm back on the waves with a new series of articles to talk about the files required by the 21 CFR 820 regulations:

• DHF: Design History File,
• DMR: Device Master Record,
• DHR: Device History Record.

Let's begin with the DHF.

Validating the compiler used in software development is a recurring issue. To what extent a compiler should be validated, when, how and why?
In the same vein, we can extend the question of validation to all tools used in the software development environment: integrated development environment, configuration management tools, compiler (and linker), automated test tools.

We've seen in the two previous posts several solutions on how to treat legacy software according to IEC 62304.
But there is nothing equivalent to this discussion in IEC 62304. The standard is silent about these situations.

In my last article, I talked about the most classical methods used to verify software: human testing (driven by test cases or not) and unit tests. I was about to talk about static analysis, that I place at a higher level of complexity in the list of verification methods, but I have to say a bit more about unit tests.

The Global Harmonization Task Force released an update of their guidance on Essential Principles of Safety and Performance of Medical Devices. It supersedes the last version released in 2005.

Following the article about software verification, let's see what software validation is.

In Software-Requirements-Specifications, I put everything you need to deal with technical requirements of your software.

In Software-Detailed-Design, I put everything about the design description of packages and component inside software, their interfaces and their workflows.

In System Architecture Description, I put everything about the description of the whole architecture of system and software.

Now that we have enough templates to describe our software, let's see how to test it. How one can release software without thourougly testing it? Nobody, I think. This is the purpose of these 3 software tests templates.

• The Software Test Plan contains all information about the organization of tests and the traceability with SRS requirements.
• The Software Test Description contains the detaled description of each test.
• The Software Test Report contains the results of tests.

Note: Test = Verification, I could have called those documents

• Software Verification Plan,
• Software Verification Description,
• Software Verification Report.

The next one will be about delivery. Stay tuned, my list of templates is growing fast!

I gather all my templates on the templates page. You'll find them all there.

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.