Friday, 27 July 2012
By Mitch on Friday, 27 July 2012, 18:36 - Templates
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:
- Project management plan,
- Software Requirements Specifications,
- System Architecture Document,
- 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.
This work is licensed under a
Creative Commons Attribution-NonCommercial-NoDerivs 3.0 France License.
Friday, 20 July 2012
By Mitch on Friday, 20 July 2012, 18:05 - Templates
Perhaps some of you who download my templates wonder how I managed to write them or where they come from.
This is a long story. Once upon a time in 1940’s, Bell Labs scientists John Bardeen, Walter Brattain and William Schockley invented the transistor.
Well, huh, not so long!
Continue reading...
Friday, 13 July 2012
By Mitch on Friday, 13 July 2012, 15:04 - Misc
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:
- Legal (choose your country): 21.CFR, 92/42 EEC (essential requirements),
CMDCAS, ANVISA, KFDA...
- Medical devices general standards ISO 13485 and ISO 14971
- Software development standards: IEC 62304, IEC 60601-1, and the like
- Guidances: GPSV, IEC/TR 80002-1, ISO/TS 14969
- 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.
Friday, 6 July 2012
By Mitch on Friday, 6 July 2012, 13:17 - Processes
Are agile methods compatible with the constraints of development set by IEC
62304 standard of class C software?
After a
series of three posts about agile methods and risks analysis. I focus in
this post on IEC 62304 class C critical software.
Continue reading...
Saturday, 30 June 2012
By Mitch on Saturday, 30 June 2012, 10:13 - Misc
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.
Continue reading...
Saturday, 23 June 2012
By Mitch on Saturday, 23 June 2012, 16:40 - Processes
We've seen in my last post that it's possible to have agile development methods combined with a risk management process. To be compliant with ISO 14971 standard, a risk management plan that describes this process along iterations, has to be written. And a risk assessment report has to be created in iteration 0 and updated in every iteration, by following the risk management process like the one found in figure 1 or figure B.1 of ISO 14971 standard.
Continue reading...
Sunday, 17 June 2012
By Mitch on Sunday, 17 June 2012, 18:29 - Processes
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.
Continue reading...
Saturday, 9 June 2012
By Mitch on Saturday, 9 June 2012, 16:45 - Processes
This post comes after a series of three posts where I exposed my thoughts about development of software medical devices with agile methods.
These posts were focussed on software development. Risk management deserves its own series of posts. Here is the first of three.
Continue reading...
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...
