Saturday, 2 June 2012
By Mitch on Saturday, 2 June 2012, 09:45 - Processes
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.
Continue reading...
Wednesday, 16 May 2012
By Mitch on Wednesday, 16 May 2012, 17:15 - Processes
In my previous post, I explained how I tweaked the waterfall model to obtain something close to agile methods. But still not agile, actually...
Continue reading...
one trackback
Saturday, 12 May 2012
By Mitch on Saturday, 12 May 2012, 20:55 - Processes
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!
Continue reading...
one trackback
Friday, 11 May 2012
By Mitch on Friday, 11 May 2012, 19:23 - Standards
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.
Continue reading...
Friday, 4 May 2012
By Mitch on Friday, 4 May 2012, 20:22 - Templates
Hello,
Back on my blog after a few days off. I wrote in my post about classes of software
that I would release a template on user guide. Here it is!
Continue reading...
Monday, 23 April 2012
By Mitch on Monday, 23 April 2012, 05:02 - Misc
I didn't have time to post anything worth it this week.
To give a side view of my last post about software classes, here is a link to DO-178B on wikipedia. It is the reference about software embarked in aircrafts.
If you take time to read this document, you will see that it goes very further than what we have today in IEC 62304. The constraints about design on high classes are very very hard to respect. That's normal, when you think that software is used in flight commands and other stuff in the cockpit.
It has some side effects, mainly to stretch software development projects, and to ban software from some parts of the plane, for cost-driven reasons.
For example, a microcontroler plus software plus electric motors would be perfect to memorize and retreive the position settings of the pilot's seat. But the cost to develop such software is very high, as the pilot's seat is seen as a critical component. Aircraft manufacturers prefer replacing software and microcontroler by good old analogic electronics to do the same task on some models.
In my humble opinion, the constraints of the two highest classes for software in aircrafts would be to high for medical devices. There is always a pratician, or an emergency medical service, able to "catch" the patient if something goes wrong. Whereas there is nobody to "catch" a falling plane if its flight commands fail. The consequences of risks are far higher in aircrafts, with potentially hundreds of victims in an accident.
That is why classes A, B and C, and their design constraints are enough for medical devices.
Next week, I'll talk about exemptions of ISO13485 for standalone software medical devices.
Bye.
Saturday, 14 April 2012
By Mitch on Saturday, 14 April 2012, 23:35 - Standards
IEC 62304 defines three safety classes for software:
- Class A: No injury or damage to health is possible
- Class B: Non-SERIOUS INJURY is possible
- Class C: Death or SERIOUS INJURY is possible
Here comes the eternal question: Which class my software belongs to?
Continue reading...
Friday, 6 April 2012
By Mitch on Friday, 6 April 2012, 11:08 - Misc
This article is the last of three articles which deal with the concept of
"inflation" of medical devices. The first
one was on inflation of standards, the second
about inflation of regulations. This one, the most interesting to my eyes, is
about multiplication of apps on mobile devices, especially smartphones and
tablets.
More that 6000 apps are classified in the "heath", "heathcare" or "medical"
categories of the Apple or Android appstores. Many of these apps are classified
as medical devices and are in the scope of regulations like FDA and CE Mark.
Note that some apps may be regulated the FDA but not the CE Mark or
vice-versa.
Continue reading...
Friday, 30 March 2012
By Mitch on Friday, 30 March 2012, 10:51 - Regulations
Today I’m going to talk about the inflation to regulations in the world of
software for medical devices. In my previous
post, I had a look at the inflation of standards for medical devices. As
the medical devices industry is heavily controlled by regulations, they deserve
a dedicated post.
Continue reading...
Friday, 23 March 2012
By Mitch on Friday, 23 March 2012, 15:59 - Templates
After the Risk Managment Plan
template, here is the Usability Specification Document.
The Usability
Specification Document is your companion during the phases where you define
the graphical user interface and ergonomics of your software.
Continue reading...
Friday, 9 March 2012
By Mitch on Friday, 9 March 2012, 13:45 - Standards

Don't worry, I'm not going to talk about money and quantitative easing! I let people with better knowledge in economics (that makes a lot of people!) do that.
When I talk about inflation, I mean the inflation of software medical devices in their number and variety, which creates a collateral inflation in the number of regulations, guidances, standards, and the like.
This post is the first of a series of three. In this first post, I focus on the inflation of standards. The next one will be on the inflation of regulations and the last one on the inflation of medical devices.
Continue reading...
By Mitch on Friday, 9 March 2012, 10:32 - Templates
At last, here is the Risk Management Plan Template.
The risk management plan was missing in my list of templates. Error repaired! It is tailor made for software medical devices. So you'll find some stuff specific to software, with references to IEC/TR 80002-1 and IEC 62304.
Continue reading...
Wednesday, 29 February 2012
By Mitch on Wednesday, 29 February 2012, 19:15 - Templates
Here are the Software Development
Plan Template and the Software
Configuration Management Plan Template
These templates are technical ones. But they are closely linked to project
management hence they contain sections about reponsibilities.
Continue reading...
Wednesday, 22 February 2012
By Mitch on Wednesday, 22 February 2012, 09:21 - Regulations
Too many documents in too many places, that’s what I felt the first time I
looked for guidances and other similar stuff about software medical
devices.
Where do I find relevant documents?
Which one do I begin with?
My answer:
I created a page where I gather my own list of guidances. It’s a selection of
guidances and recommendations for CE mark.
Click
here to see the list.
Hope you enjoy it :-)
Friday, 17 February 2012
By Mitch on Friday, 17 February 2012, 11:29 - Templates
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.

This work is licensed under a
Creative Commons
Attribution-NonCommercial-NoDerivs 3.0 France License.
Monday, 6 February 2012
By Mitch on Monday, 6 February 2012, 18:14 - Regulations
New! MEDDEV 2.1/6 Guidelines on classification of standalone software released!
HIS, CIS, PDMS, RIS, PACS, LIMS … Which ones are medical devices, which ones are not?
To answer this question, the European Commission issued a new Guidelines document: MEDDEV 2.1/6, about the qualification and classification of standalone software as Medical Devices or In Vitro Diagnosis Devices.
Download here
After the draft guidance of the FDA about mobile apps, after the guide on regulation of health apps by a UK medical charity, this MEDEV is the third document released in a few months about standalone software.
Continue reading...
Monday, 30 January 2012
By Mitch on Monday, 30 January 2012, 19:25 - Templates
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.
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.

This work is licensed under a
Creative Commons Attribution-NonCommercial-NoDerivs 3.0 France License.
By Mitch on Monday, 30 January 2012, 03:17 - Standards
This article was moved Here.
Saturday, 28 January 2012
By Mitch on Saturday, 28 January 2012, 11:40 - Regulations
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.
Continue reading...
Friday, 20 January 2012
By Mitch on Friday, 20 January 2012, 08:07 - Templates
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.
The template about software architecture was missing. Here is the System Architecture
Description document! It contains entries compliant with IEC 62304 and
section 14 of IEC 60601-1. It should be used to describe the architecture of
hardware and software.
The next one will be about software tests. Stay tuned, my list of templates
is growing fast!
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.

This work is licensed under a
Creative Commons
Attribution-NonCommercial-NoDerivs 3.0 France License.