Software in Medical Devices, by MD101 Consulting

To content | To menu | To search

Friday, 4 May 2012

Template: User Guide

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

Class A, B or C (continued)

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

Is my software in class A, B or C?

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

Inflation of software medical devices - part 3

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

Inflation of software medical devices - part 2

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

Template: Usability Specification Document

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

Inflation of software medical devices - part 1

the-lesson.jpg
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...

Template: Risk Management Plan

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

Templates: software development plan and software configuration management plan

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

The essential list of guidances for software medical devices

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

Template: Version Description Document

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.



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

Monday, 6 February 2012

MEDDEV 2.1/6 Guidelines on classification of standalone software released!

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

New templates: Software Tests Plan, Software Tests Description and Software Tests Report

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.



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

How to deal-with ISO 13485 in a software company?

This article was moved Here.

Saturday, 28 January 2012

A unique agency to homologate Health IT Systems?

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

Template: System Architecture Description

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.



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

Wednesday, 18 January 2012

Breast implants scandal: does the CE Mark malfunction?

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.

Continue reading...

Tuesday, 10 January 2012

Template: Software Design Description

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.



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

Thursday, 5 January 2012

Pfizer recalls Rheumatology Calculator smartphone App

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.

Continue reading...

Wednesday, 4 January 2012

Software development subcontractors: How to manage your Customer

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!

Continue reading...

- page 12 of 13 -