Many medical devices run software, and a fault in that software can hurt someone. IEC 62304 is the standard for the software life cycle. Its scope covers development and maintenance, when the software is itself a medical device or is an embedded or integral part of one. It does not cover validation and final release of the complete device, even when that device is all software. The first question it asks of a team is simple: how bad can it get?
Three classes, set by harm
The standard sorts software into class A, class B and class C. The notified bodies' FAQ on the 2006 edition gives the working rule. If a chain of events through the software can lead to serious injury, the software is class C. If it cannot, but it can lead to injury, it is class B. If no injury can result, it is class A. The same FAQ says to start by assuming class C and to work down from there, once the intended use is clear.
Three points from that FAQ are easy to miss:
- The class does not depend on probability. The FAQ says the contribution of the software to a hazard is assumed to be certain. Reducing the probability can still be a good mitigation, but it does not change the class.
- Some controls lower the class and some do not. A hardware risk control can lower it by one level. User information, such as training or a warning in the manual, cannot.
- The class is not the device class. The FAQ states that neither the standard nor the regulation maps a software safety class to a device class under the EU directive of that time. The device class comes from the intended use.
The FAQ was written in 2013, on the 2006 edition. A consolidated edition with Amendment 1 of 2015 has been on sale from the IEC since June 2015, and the amendment may have changed details of the points above. Check each one against the current text.
What a class asks of the lifecycle
The class sets how much process you owe. The FAQ gives a few anchor points. Class A is the minimal set of activities and tasks. Architecture is required for class B and C. Detailed design is required for class C. For class B and C, each potential cause of a hazardous situation needs a defined and documented risk control measure. The FAQ also says that detailed design for a class B item may stay in the heads of the developers and testers, while a class C item needs it written down so the unit testing can be documented in more detail.
| Class | The worst harm | What the FAQ gives as examples |
|---|---|---|
| A | No injury is possible | The minimal set of lifecycle activities and tasks. |
| B | Injury that is not serious | Architecture, and a risk control for each potential cause (one control may cover several causes). |
| C | Death or serious injury | The class B activities, plus detailed design and other class C tasks. |
The standard works together with risk management. The FAQ says the standard prescribes a risk management process that complies with ISO 14971 for all safety classes, and adds software-specific requirements on top. So the class is an output of the risk analysis. It is not a label to pick at the start of a project and forget.
Splitting the software
You may classify the whole software system once. The FAQ says assigning a class is compulsory, but it allows a team to limit this to an initial classification of the whole system. Splitting the software into items matters because a child item inherits the class of its parent by default. It can take a lower class only if you document a reason why it cannot contribute to hazards of the same severity.
A lower class for one part is only believable if that part cannot disturb the rest. The FAQ calls this segregation: keeping software items from influencing each other in unintended ways, through control flow, data flow or shared resources. It can be functional, logical or physical, for example separate processors. You show that it works by showing there are no significant side effects.
Software you did not write
The standard has a name for software you did not develop for the device: SOUP, software of unknown provenance. The FAQ notes that all off-the-shelf software counts as SOUP. The FDA uses the related term off-the-shelf software for a generally available component whose life cycle the manufacturer cannot fully control, such as an operating system or a display library.
The FAQ says the standard has no special requirements for SOUP suppliers beyond the general supplier management rules. SOUP still needs the same activities as software you write yourself, except detailed design and coding. In practice, the FAQ says, this means stating how the SOUP should work in your device and running representative tests against that statement. Identify each SOUP item and state its intended use.
How the FDA looks at it
The US FDA sorts software differently. Its 2023 guidance on premarket submissions for device software functions sets a documentation level, Basic or Enhanced. The level reflects the risk of the software in the context of the intended use. Enhanced applies where a failure or flaw could present a hazardous situation with a probable risk of death or serious injury. The guidance says to assess these risks before any risk control measures are applied. Basic applies where Enhanced does not. The FDA also recommends Enhanced for some categories, such as Class III devices.
The FDA also names IEC 62304 as one way to provide part of the documentation. A sponsor may give a declaration of conformity to specific clauses of the FDA-recognised version. The guidance says a declaration to the complete standard is not needed, because of known differences in how software functions are categorised. So an IEC class and an FDA level are not the same thing, and one does not give you the other.
Common mistakes
- Choosing the class by what feels safe. Take it from the hazard analysis, and write down the chain of events behind it.
- Counting training or a warning as a risk control that lowers the class. The FAQ says it does not.
- Treating the class as fixed. When the risk analysis changes, the class may change with it.
- Leaving SOUP undocumented. A library you did not write is still part of your device.
- Assuming one class fits every market. The FDA documentation level and the IEC class are decided on different rules.
Where to start
Write the intended use first. List the ways the software can contribute to a hazardous situation, and find the worst harm for each. That gives you the class, and the class tells you how much architecture, design and test record to plan for before the first line of code is written.
Sources: IEC, webstore page for IEC 62304:2006+AMD1:2015 CSV (edition 1.1, published 26 June 2015: scope and edition details); Team-NB, Frequently Asked Questions related to the Implementation of EN 62304:2006 with respect to MDD 93/42/EEC, version 1.0, 5 April 2013 (an industry association of notified bodies, written on the 2006 edition, before Amendment 1); US FDA guidance, Content of Premarket Submissions for Device Software Functions (June 2023), sections on documentation levels, off-the-shelf software and software development practices. The standard itself is sold by the IEC and is not reproduced here. This article is a general guide, not a regulatory determination for any device.