IEC 62304 defines safety classes so that medical device manufacturers can tailor the effort required for software documentation to the degree of harm that could be caused by a software error.
This expert article helps to determine the safety classes and, if necessary, reduce them in order to minimize the effort required while still ensuring documentation complies with IEC 62304.
- IEC 62304 defines three software safety classes (A, B, C) based on the potential risk to patients, with class C having the highest requirements.
- Each software component must be classified – the highest class of a component determines the class of the entire software system.
- Risk control measures external to the software can reduce safety classes, which reduces the documentation effort.
- The FDA documentation levels do not directly correspond to the safety classes of IEC 62304, but have a similar impact on the scope of documentation.
- The new IEC 62304:2026 (draft) plans to reduce the number of safety classes from three to two.
1. Significance of safety classes according to IEC 62304
IEC 62304 is the harmonized standard for the development of medical device software. It requires manufacturers to classify this software or its software components into three safety classes, A, B, and C, depending on the risk or severity of possible harm. Class C is assigned to the highest risks, class A to the lowest.
These safety classes determine the documentation requirements and thus also the development and testing requirements for this software.
If the manufacturer does not carry out this safety classification, the software and all software components fall into the highest safety class C.
2. Safety classes: Definitions
The simplified definition of the safety classes is:
- Class A: No injury possible
- Class B: No serious injury possible
- Class C: Death or serious injury possible (e.g., ventilation control)
A closer look at the 2015 edition of IEC 62304 reveals a more nuanced picture:
- Safety class A: The software system cannot contribute to a hazardous situation, or the risk is acceptable, at least once appropriate risk control measures have been taken. However, these risk control measures must be outside the software system.
- Safety class B: The software system can lead to a hazardous situation even after risk control measures have been taken, but the possible resulting harm is not severe.
- Safety class C: The software system can lead to a hazardous situation even after risk control measures have been taken, whereby the possible resulting harm is severe or can even lead to death.
This can be summarized as follows:
| Class A | Class B | Class C | |
| Resulting risks | Acceptable | Unacceptable | Unacceptable |
| Potential harm after risk control measures | No harm | No serious harm | Serious harm or death |
The definition of safety classes in IEC 62304 is problematic, as products with unacceptable risks are generally not allowed to be placed on the market. It is therefore hoped that this definition will be revised in the second edition of IEC 62304.
3. Impact of the safety class on the software life cycle
The software safety class determines specific requirements for each step in the software development process.
| 5.1 | 5.2 | 5.3 | 5.4 | 5.5 | 5.6 | 5.7 | 5.8 | 7 | 8 | 9 | |
| A | x | x | x | x | x | x | x | ||||
| B | x | x | x | (x) | x | x | x | x | x | x | |
| C | x | x | x | x | x | x | x | x | x | x | x |
For software in safety class A, manufacturers only need to document the software requirements (5.2) and software release (5.8). For class B, the software architecture (5.3) and software verification (5.5 to 5.7) must also be documented, and for safety class C, the detailed design (5.4) must also be documented.
Since Amendment I in 2015, system tests have also been mandatory for safety class A.
The Johner Institute considers many discussions regarding Class B or C to be of little use. This is because foregoing detailed design or unit testing would not be in line with professional software development. And as soon as you look at the FDA, this discussion becomes completely absurd. This is because, regardless of the level of concern, all documents must be created, but not submitted.
It is even questionable whether software documentation without a software architecture meets the requirements of the MDR, which requires the following documentation, among other things:
- Components
- Where applicable, visual representations (e.g., diagrams, photographs, and drawings) in which the most important parts/components are clearly identified
- Description of the software design
4. Reduce safety class
External risk control measures can significantly reduce development costs. “External” does not necessarily mean outside the product, but outside the software.
The measures are usually implemented in hardware. Examples:
- The mechanical geometry prevents software from causing an actuator to jam a finger.
- Even in the event of a fault, software cannot cause a motor to rotate faster than the motor limits allow.
- A second independent software system (on its own hardware) checks the results of the first software system and intervenes in the event of a fault.
- A user checks the values before the medical device or humans take further action.
Manufacturers must check all risk-minimizing measures for implementation and effectiveness. This also applies to measures for which humans are responsible. In such cases, usability tests are usually necessary for verification.
A software component that monitors another software component within the same software system is, in principle, suitable as a risk-minimizing measure, but not for reducing the safety class.
5. Safety classes vs. documentation levels
With its documentation levels (formerly levels of concern), the FDA pursues similar goals to those of IEC 62304 with its safety classes.
What the FDA and IEC 62304 approaches have in common is that both require more documentation for higher risks. However, it is not possible to directly assign documentation levels to safety classes.
The documentation levels refer to the documentation to be submitted, not to the documentation to be created. The FDA guidance document on software validation (meaning the entire software development process) does not distinguish between documentation levels.
In addition, the FDA allows documentation levels to be determined per “function” (which is an aspect of the intended purpose), whereas IEC 62304 requires a definition of safety classes per software system or software component.
Please refer to the technical article on FDA Levels of Concern and Documentation Levels.
6. Safety classes and segregation
Manufacturers can reduce the amount of documentation required by cleverly dividing up the software. To do this, they must justify why individual software components have a different software safety class. Such justification must be based on sufficient segregation of the components.
Justifications should be derived from the software or hardware architecture and be based on weak (or no) coupling between the respective components.
A software component A that does not call any methods on a software component B is more weakly coupled than a software component that calls these methods on B, inherits from B, or catches exceptions from B.
A particularly powerful argument would be that the two software components run on different hardware. However, it could then also be argued that these are two software systems that can generally be classified as independent.
Conclusion: Software components (software items) can have different safety classes if their independence is proven – however, the highest class of a component determines the class of the overall system.
7. Practical implementation
A structured approach saves time and avoids audit findings.
The following steps are recommended for this approach:
- Derive from risk management (top-down!) which hazards emanate from the software system
- If necessary, derive risk-minimizing measures outside the software system from risk management
- Then determine the software safety class of the software system
- Design the software architecture so that the software components can be identified and their interfaces specified
- Depending on this, determine the safety classes for the software components
- Create documentation based on these safety classes
- Check the implementation of steps 1 to 6 during the design review
8. Summary & conclusion
The risk-based approach of IEC 62304 appears attractive at first glance because it allows the documentation effort to be adapted to the risk. However, this involves several risks:
- Manufacturers no longer meet the regulatory requirements of other markets.
- In the worst case, they may not even meet the requirements of MDR and IVDR.
- They increase audit risks because developers find it difficult to work according to different specifications within a software system.
- They increase the likelihood that software errors will remain undetected.
- In addition, discussions about the safety class sometimes take more time than could be saved by choosing a lower class.
If manufacturers are willing to accept these risks, they should go through the seven steps outlined above. Otherwise, they can skip steps three and five.
The Johner Institute therefore recommends developing the software professionally, which automatically leads to compliance with the requirements for safety class C.
IEC 62304 should not be misunderstood as a best practice standard or even state of the art. It defines the lower limit of non-professionalism.
Would you like to learn more? Then attend the IEC 62304 compact seminar.
Would you like to make your software development more efficient and at the same time achieve compliance (not only) with IEC 62304? Then get in touch with our software experts.
Change history
- 2025-10-15: Article completely rewritten
- 2017-12-14: First version of the article published
