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!
To content | To menu | To search
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!
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:
Here comes the eternal question: Which class my software belongs to?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
Wednesday, 18 January 2012
By Mitch on Wednesday, 18 January 2012, 10:33 - Regulations
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.
Tuesday, 10 January 2012
By Mitch on Tuesday, 10 January 2012, 18:57 - Templates
In Software-Requirements-Specifications, I put everything you need to deal with technical requirements of your software.
The next template I want to share with you is the one about detailed design. The Software Detailed Design template deals with the design description of packages and component inside software, their interfaces and their workflows. It contains entries compliant with IEC 62304. It should be used to describe the internals of software, from components, down to classes or procedures.
The next one will be about the software architecture. 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.
Thursday, 5 January 2012
By Mitch on Thursday, 5 January 2012, 19:45 - Misc
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.
Wednesday, 4 January 2012
By Mitch on Wednesday, 4 January 2012, 12:09 - Processes
Congratulations! You have signed a contract with a medical devices manufacturer. They don't have a very good knowledge of software. They rely on you to develop something brand new on a smartphone. The application they want to develop will bring new functionalities to doctors and let them do their jobs faster. Your customer chose you because you are the specialist of software on every OS’es on smartphones. You ensured him that your company can be in conformity with IEC 62304 standard. To that purpose, you modified and added the necessary procedures and forms to your quality system. You have one year to develop the application, which fits their desires … and the medical devices standards!
« previous entries - page 12 of 13 - next entries »