Software in Medical Devices, by MD101 Consulting

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.

Hello,

I run this blog on a free platform, it is going to be full and I'll be soon unable to use it any more. I spent most of my time to port the blog on a new PAAS this week. I continue with the same blog engine (dotclear), to maintain the architecture and the URLs. It's very important to keep my google rank!
I should be able to release it in september, when all bugs are fixed.

One important thing happened this week: the ASEAN countries released a draft of ASEAN Medical Device Directive (AMDD), see here . This is a bit like the CE medical devices directive, with one set of regulations for many countries.
It gives me the opportunity to introduce the concept: Develop once, Certify anywhere
It means that, with the convergence of regulations, one set of documents is enough to create a technical file submitted in many countries. For example, data submitted to the EU authorities would be also submitted to the ASEAN member countries.
I'll post more details on this concept later on.
Bye.

Post edited August 29th 2012:
Here is the new blog platform!
No big changes for you, only a new layout.
I let it run for one week in beta test to see if everything's ok.
The previous blog is still active, for backup: EDIT previous blog platform link removed, blog closed.

This blog is registered on technorati with code: W4S4GJXCQPTP

Hi everybody,

I was out of the office, I didn'it have time to write anything relevant about our favorite subjects.
Here is an interresting article of The Economist (link will be dead after a while) about open-source software.

Seen on the newsletters I receive for vigilance, the recall of a defibrillator due to software failure: here on MHRA website and here on ANSM Website (in french).

For those who spent their vacation on Mars and haven't heard about Proteus ingestible biomedical sensor yet, have a look at this article. This is a double performance: technical with an ingestible sensor, and regulatory with clearance through the new "de novo" FDA process.

And to end with a bit of futurology, this new article of EMDT about the future of medtech.

Bye.

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.

Happtique, an appstore for mobile medical devices has drafted an App Certification Program.
This not a program or a process but a list of functional and non functional requirements that mobile health apps should respect to be certified - according to Happtique. It' a bit like the requirements of Apple to be authorized to place an app in the Apple Store. Happtique publishes your app on its store if you are compliant with its certification program.
There is a lot of work behind this document, and a lot of knowledge. However I don't think this is enough to make a certification program. This document focuses on the results, whereas all software development standards focus on the processes. FDA focuses also on the processes when its auditors verify compliance to 21.CFR.
In the scale of precedence of documents, I would put it here:

1. Legal (choose your country): 21.CFR, 92/42 EEC (essential requirements), CMDCAS, ANVISA, KFDA...
2. Medical devices general standards ISO 13485 and ISO 14971
3. Software development standards: IEC 62304, IEC 60601-1, and the like
4. Guidances: GPSV, IEC/TR 80002-1, ISO/TS 14969
5. Generic functional and non functional requirements: Happtique App Certification Program.

It's obvious that Happtique wants to make some noise with its certification program (and it has reached his goal, you're reading this post). But I have to recognize that this document contains a big source of information for software requirements. The content of this certification program is a perfect source of ideas to write a software requirements specification (SRS).

The world of mHealth is moving fast. In the same kind of article, I have found Tech Barbarians at the Medtech Gates, this article is a good summary of antagonist forces at stake. On the one hand, the regulators and their, so called, ante-Flood rules. On the other hand, the software industry with its new world of mHealth. Guess who's going to have the last word? If, like me, you don't have the answer, continue to apply the standards and regulations...
Bye.

After a long series of posts about agile methods, let's continue with something less serious!
If you saw Prometheus, the sci-fi movie about a team of astronauts who search for human origins, you were probably amazed by the Weyland Corp Medical Pod 720i. Like me.

This post is the continuation of the post of last week.
We've seen in that post that fixing bugs during software maintenance is like a small chunk of design, excepted that software specifications do not change. Therefore risk management process when fixing bugs is very close to risk management process during design, without the initial assessment of risks at the beginning of the software development cycle.

In my previous post, I explained how to adapt agile methods to IEC 62304. I finish this series of 3 posts with some advices about the organization of an iteration and the software development team.

IEC 62304 is the standard to apply for software in medical devices. It is not bound to any software development method or model. Though not explicit, using the waterfall development model is the most straighforward way to apply this standard.
The waterfall model has become old fashioned to the eyes of most of software developers, with the emergence of agile methods. Agile methods are so popular now that everydody wonders how to apply IEC 62304 with agile methods.

An AAMI/CDV-1 TIR(SW1) - Guidance on the use of agile practices in the development of medical device software exists about this subject. But it is still a draft and only members of AAMI have access to it.

So, how to use agile methods and still be compliant with IEC 62304?
Here are my thoughts about these questionings!