Software in Medical Devices, by MD101 Consulting

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!

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.