Software in Medical Devices, by MD101 Consulting

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.

In Software Test Plan, Software Test Description and Software Test Report I gathered all information about the organization of tests, the traceability with SRS requirements, the description and results of tests.

The Version Description Document is about the description of a delivery of software and hardware. If contains the mandatory information to identify a software version, its dependencies and how it is generated.

This template is the last of my first series of templates. You have all you need to document a software development project of middle importance for a medical device.

However the Project Management Plan template is made for simple projects. For a project with more complexity, you need to pay more attention to software configuration and software development.

The next two templates will be the software configuration management plan and the software development plan. They will contain more information on these subjects than what you find in the project management plan.
Later on, I will add a risk management plan to the templates. Then, the series of management templates will be complete.

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.

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.

LESSIS, the federation of french editors of medical and social IT systems, proposes the creation of a unique agency to homologate health IT systems. Original article here (in french).

No more than 6 french governmental agencies are in charge of the homologation of health IT systems in France. Following the example of the CE mark, LESSIS proposes to build a common route to certification. Like the Afssaps for medical devices, a unique agency would be in charge of delivering the certificates, auditing the companies and applying sanctions.

Breast implants are technically far from software and one may say they don’t have anything in common. Yes, they do, when software is part of a medical device, they are both subject to the regulation of the 93/42 CE directive.

Is it possible to have a massive injury of people with software, like the one we discovered with the breast implants scandal?

To understand how this happened, let us begin with a brief history of the CE mark.

Dozens of companies recall their medical devices every month. A recall happens when something wrong happened with the device, like a bad labeling or a bad sterilization. It's the responsibility of the manufacturer to warn ALL their customers and the government agencies that a given lot or batch of products has a defect. The batches shall be destroyed or sent back to the manufacturer for further analysis.
That's what happened to Pfizer with its Rheumatology Calculator, a smartphone app used to compute a score to assess the desease of patients according to complex algorithms. There is a bug in the app and it gives wrong results.

Case example

You are a medical device company and you want to replace your old products by “smart” ones. Your competitors are doing it and you customers want them. “Smart” means something like an tiny computer (its amazing how small they are), with an operating system and big software. For electronic stuff, you have your own engineers or you have your subcontractors, which you have been working for 20 years with. They knew how to design embedded software on microchips. But they don’t know how to design software of higher level, with intelligent behaviour and complex algorithms.

The GHTF (Global Harmonization Task Force) issued a draft of a new guidance on medical device classification They recommend to implement four classes for medical devices based on intended use: from class A (lowest risk) to class D (highest risk). And they give a set of rules on how to choose the classification of the devices.

Comparison with regulations

Wait, I've already seen this elsewhere. Classification of devices in Europe (CE mark) and in Canada have systems very similar to what GHTF recommends. This is a good thing to have an ongoing harmonization process. National regulations copy what GHTF recommends and GHTF copies what national regulations require. This is a virtuous circle. Maybe one day the FDA will implement this classification system.

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.

Here is the Project Management Plan Template.

This template doesn't contain anything technical. Has it something to do with software development? Yes, it has. It contains all the answers to questions like: Who, What, Where, When, How, Why and How much? You can do all the technical stuff you want, but without a minimum of organisation, your software will never be certified. This template deals with sections of IEC 62304 about project organisation. Use it to answer to those requirements of the standard.

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.