Software in Medical Devices, by MD101 Consulting

To content | To menu | To search

Tag - risk management

Entries feed - Comments feed

Friday 1 March 2013

How to bring legacy software into line with IEC 62304? - part 2

We've seen in the last post how to manage changes in legacy software. Let's see it from another point of view: the type of legacy software.

Continue reading...

Friday 22 February 2013

How to bring legacy software into line with IEC 62304? - part 1

Most of medical devices manufacturers have legacy software that was not designed according to IEC 62304. The devices that embed legacy software were once verified and validated. These devices and their software work well and no major adverse event were raised by software issues.
But one day, the manufacturer decides that it's time to bring that legacy software into line with IEC 62304, to align the technical file of that software (or the contribution of software to technical file content) with up-to-date standard or regulatory requirements.

Continue reading...

Friday 11 January 2013

What is a Software Unit?

IEC 62304 requires to split architecture of class C (mission critical) software into software items and software units. Software units are software items that can't be split into sub-items, according to the standard. Okay. But how to decide that an item can't be split into sub-items, and is a unit?

Continue reading...

Friday 28 September 2012

Probability of occurence of a software failure

In two previous articles, I talked about the differences of bugs, software failures, and risks.
I left the discussion unfinished about the probability of occurence of a software failure or a defect.
I think that assessing the probability of occurence of a software failure is a hot subject. I've already seen many contradictory comments on this subject. It's also a hot subject for software manufacturers that are not well used to risk assessment.

Continue reading...

Friday 14 September 2012

How to differenciate Bugs, Software Risks and Software Failures - Part 2

In my previous post about Bugs, Software Risks and Software Failures, I explained the concepts of bugs, defects or anomalies, and the concept of software failure.
Let's continue now with Risks.

Continue reading...

Friday 7 September 2012

How to differenciate Bugs, Software Risks and Software Failures - Part 1

A bug can lead to a software failure.
Having bugs is a risk.
Having a software failure is a risk.
A software failure is not necessarily a bug!

Do you follow me?
If not, let me give you some more explanations.

Continue reading...

Friday 6 July 2012

Class C software and agile methods

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 23 June 2012

How to combine risk management process with agile software development? - Part 3

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

How to combine risk management process with agile software development? - Part 2

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

How to combine risk management process with agile software development? - Part 1

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...

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.

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 9 March 2012

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...

Monday 28 November 2011

Template: Risks Analysis Report

Templates section wouldn't be a templates section without something about risk analysis. Error repaired!

Here is the Risk Analysis Report Template. It contains sections compliant with IEC 62304, IEC 62366 and ISO 14971. It is best used in conjunction with the SRS template.

Please, fell free to give me feedback on my e-mail

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.

Friday 18 November 2011

Software Medical Devices. How to obtain market homologation?

The homologation of a medical device is a complex task and can become a nightmare with devices with a high level of risk. It involves many standards and regulations, different from one country to another: FDA in the USA, CE Mark in Europe, CMDCAS in Canada, KFDA in South Korea, and so on …

Fortunately, most of these regulations have common requirements and rely on ISO standards, the most important standards being ISO 13485 and ISO 14971. If you meet the requirements of these standards, you increase your chances of passing the homologations for the devices with low risk. For devices with high risk, these standards are (almost) mandatory.

Continue reading...

Friday 4 November 2011

5 recommendations to engineers developing medical device software

A lot of standards and regulations exist about medical devices: how to design, to produce, to sell, to monitor their use … Everything about each step in the life of devices, from the initial idea 10 years before selling anything, to the archiving of records 10 years after the last item has been sold. A lot of specific standards or guidances on how applying medical devices standards exist about software. That’s the consequence of software being very specific (I should say peculiar), compared to other components in medical devices. Conception is the most critical part in the lifecycle of software. Software is never 100% finished, user always want enhancements and modifications.

From my own experience in the field, I gathered 5 basic recommendations you should follow.

Continue reading...

page 2 of 2 -