Class A, B and C. Is it possible to reduce the documentation of detailed design of software medical devices?
By Mitch on Monday 21 January 2013, 15:34 - Standards - Permalink
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.
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:
- Risk analysis and definition of classes of items,
- 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!
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.
Thanks for your feedback.
Yes, it's possible to downgrade from class C to class A with two mitigation actions.
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
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.