Software in Medical Devices, by MD101 Consulting

To content | To menu | To search

Class A, B and C. Is it possible to reduce the documentation of detailed design of software medical devices?

In the last two posts, we've seen what a software unit is, and when to do software detailed design, according to IEC 62304 and FDA Guidances.

For Class C software, detailed design can be a very burdensome and time consuming task.

Detailed conception and its verification

IEC 62304 standard requires doing the detailed conception of every software unit and to verify this detailed conception.
This means that a lot of time has to be devoted to detailed conception documentation:

  • Component/class/sequence/collaboration/deployment diagrams,
  • Comments that explain the choices of conception highlighted by these diagrams.

This also means that reviews have to be planned to formally verify the conception.
It bet that your managers don't give you enough time and money to do these tasks with the level of scrutiny required by the standard!

Verification of software units

IEC 62304 standard requires also verifying the software units. In concrete terms, doing unit tests to show that software units work the way they were designed. And to formally review these unit tests!
OK, most of software development teams do unit tests today, units tests became the custom. But the problem is that for class C, he tests shall be systematic and should consider the following criteria:

  • data flows,
  • memory allocation,
  • fault tolerance,
  • and a few others of the same type.

So units tests with this level of scrutiny can become a very burdensome task. Once again, I bet that managers don't give you the necessary time to do all of these tests.

I'm a bit provocative, there are medical devices manufacturers that apply the standard to the letter. Ask the infusion pumps manufacturers what they think of FDA research about software failures!

Fortunately, it's not necessary to do Class C documentation for the whole software, provided that its architecture has been designed the right way.

Software Architecture to isolate Class C software items

Imagine a software system with a Class C software item inside larger software items, like in the diagram below.
Software in medical devices - Class C software item forces the whole topmost software item to be in Class C The class C critical item in red propagates its critical characteristics to the whole topmost item and other siblings items. Even a class A item has to be treated as a class C item.
Why? Because it is known that a software failure that happens in an item can propagate to another item and have unexpected consequences. So a class A item, which is more subject to failures, can lead to the failure of a class C item. This make the work on the class C item useless.
To avoid dreadful consequences of software failures of non-critical items on critical items, it's necessary either to do everything in the highest class, or to isolate critical items.
This is what is done in the diagram below:
Software in medical devices - Isolate Class C software items to reduce the scope of application of class C requirements The critical item is isolated in a topmost item, with an interface. It communicates with other topmost items through its interface.
The isolation may also be physical, with the class C items running on a separate hardware.
Doing so, the scope of class C items is reduced, other topmost items can be of lower classes.
Though this work of architecture isolation is possible, it shall always be done a as consequence of a risk analysis:

  1. Risk analysis and definition of classes of items,
  2. Risk mitigation and isolation with architectural measures.

It shall not be done the other way!

As a conclusion, I would say that there are not many ways to escape from the work overload due to class C items. The right solution is to isolate Class C items in a subsystem with well defined (and simple) interfaces. If you can't do this kind of architectural separation, you're stuck with class C tasks!


1. On Tuesday 5 December 2017, 17:16 by Mathieu Febvay

Thank you for this trick !

However, when you isolate your software like you did, is the interface manager mandatory class B ?

Is it possible to switch from class C item to class A with risk mitigation measures (CRC and another hardware/software checks the class C item) ? (EN62304:2006 4.3.a explains that is possible to switch from class C to class B AND from class B to class A)

Again, thank you for all your valuable informations.


2. On Friday 8 December 2017, 16:00 by Mitch

Thanks for your feedback.

Yes, it's possible to downgrade from class C to class A with two mitigation actions.

3. On Friday 26 January 2018, 15:06 by Murielle

Thank you for this post
I have a question
You write that the "The isolation may also be physical". So I assume that the interface may be done by software (for exemple with mutex, queue if using an OS).
But when I read EN62304:2006 4.3.a, there is only hardware risk control measure which can reduce the software safety classification.
So the interface can be only physical with consequence to run software items on separate hardware or I'm wrong in comprehension?
Thanks for your response

4. On Saturday 17 February 2018, 16:56 by Mitch

Hi Murielle,

The hardware risk control is required to downgrade form C to B or B to A without isolation/segregation.  But according to 4.3.d, the segregation can be software/logical or hardware/physical. But you shall bring strong rationale for a logical segregation. Usually, it is better admitted to have logical separation between classes A and B, and physical between C and B.


Add a comment

Comments can be formatted using a simple wiki syntax.

This post's comments feed