Software in Medical Devices, a blog by MD101 Consulting

To content | To menu | To search

Class A, B and C. When to do detailed design of software medical devices?

In my last post, I explained what criteria should be taken to define the level of details of software units in a software design. This activity is not mandatory for all levels of risk of software in medical devices, though, according to IEC 62304.

Class matters

Depending on the class of a software according to IEC 62304, software design can see a dramatic turnaround!
This is located in sections 5.4 and 5.5 of the standard.

Class A Medical Software

In this case it's not necessary to do anything. Only software level requirements and tests are needed.
I don't recommend to skip the software design documentation. Even a light documentation can help team of developers to understand how software works.

Class B Medical Software

In this case, it's necessary to do the software detailed design, down to software units. But it's not necessary to verify the detailed design. Strange, isn't it?
Not that much. IEC 62304 requires to define acceptance tests and to test software units. The design is indirectly verified by testing software units.

Class C Medical Software

In this case the standard requires to:

  • Do the detailed design down to software units,
  • Verify the detailed design (eg formal review with peers),
  • Define acceptance tests of software units, with a list of *very* recommended acceptance criteria,
  • Do the tests of software units.

This is the toughest case, obviously. IMHO, I prefer to keep it like that, for the unwanted day I'm connected to a medical device with software inside!

FDA Guidances

General Principles of Software Validation

The FDA Guidance "General Principles of Software Validation" doesn't add much about software design. It just says:
Due to complexity of the project or to enable persons with varying levels of technical responsibilities to clearly understand design information, the design specification may contain both a high level summary of the design and detailed design information.
FDA uses the word may.
So, it's up to you to define if detailed design is mandatory? Nope.

Content of Premarket Submissions for Software

The other FDA Guidande "Content of Premarket Submissions for Software Contained in Medical Devices" defines 3 levels of concern that can somewhat be mapped to classes in IEC 62304:

  • Minor Concern = more or less Class A
  • Moderate Concern = more or less Class B
  • Major Concern = more or less Class C

I use "more or less" because the definition of levels of concern of FDA doesn't exactly match the definition of classes in IEC 62304.

Table #3 contains a line about mandatory tasks about detailed design. The tasks depends on the level of concern of software.
Guess what? These tasks match those of IEC 62304. Hourray!
The only problem is in the definition of classes and levels of concern. A device may be in class A according to IEC 62304 and Major Concern according to FDA. But this is very unlikely.
Anyway, manufacturers should adjust the content of software, to have IEC 62304 classes and FDA level of concerns align. This is a better situation than having to redo software design to sell in a different country!

Doing, verifying and documenting detailed design can be a burdensome task. We'll seen next time if it can be reduced.

Add a comment

Comments can be formatted using a simple wiki syntax.

This post's comments feed