Software in Medical Devices, by MD101 Consulting

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