Class A, B and C. When to do detailed design of software medical devices?
By Mitch on Friday, 18 January 2013, 15:45 - Standards - Permalink
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.
Comments
Hi !
Thank you for content ! I highly appreciate it :)
I have a question concerning the 62304 classification (A,B and C) and the Software Detailed Design(SDS) of clause 5.4 of IEC 62304, so this would be for EUROPE.
For example, If I have 5 Software items that are class A and 1 Software item that is a class B, clause 5.4.1 specifies that the SDS is only necessary for class B components.
Therefore, in my SDS document we could have only the detailed specification of the Class B component, so therefore in terms of traceability we would have :
- Class A component : Requirement (SRS doc) -> test case (V&V)
- Class B component : Requirement (SRS doc) -> Specification (SDS doc) -> test case (V&V).
Is that correct?
Finally, in the US, the classification of the software is determined by the level of concern (which is similar to the 62304 but not exactly the same, which is the case for our device.)
The level of concern seems to give the software classification of the WHOLE software, per this guidance. However, is it possible to isolate each software component and evaluate their own class, like the IEC 62304? This would avoid us to document specifications for low class (MINOR - class A) software Items and we would have :
- Class "MINOR" component : Requirement (SRS doc) -> test case (V&V)
- Class "MODERATE" component : Requirement (SRS doc) -> Specification (SDS doc) -> test case (V&V).
Plus, the IEC 62304 is a Recognised consensus standard so this can be justified ?
Any feedback would be so helpful !!!
Thank you very much :)