Software Safety Classes (IEC 62304) versus Levels of Concern (FDA)
Both, European and US regulations, distinguish three different categories of medical device software, the software safety classes accordingly to IEC 62304 respectively the FDA levels of concern. Frequently manufacturers confuse both.
Software safety classes
IEC 62304:2006 + Amendment 2015 define the software safety classes as follows:
Definition: Software Safety Class
„The SOFTWARE SYSTEM is software safety class A if:
- the SOFTWARE SYSTEM cannot contribute to a HAZARDOUS SITUATION; or
- the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which does not result in unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM.
The SOFTWARE SYSTEM is software safety class B if:
- the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which results in unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM and the resulting possible HARM is non-SERIOUS INJURY.
The SOFTWARE SYSTEM is software safety class C if:
- the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which results in unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM and the resulting possible HARM is death or SERIOUS INJURY“
IEC 62304:2006 + A1:2015
Definition of safety classes and levels of concern
The following diagram summarizes this classification:
Level of Concern
The FDA defines the Levels of Concern as follows:
Definition: Level of Concern
- Minor: We believe the level of concern is Minor if failures or latent design flaws are unlikely to cause any injury to the patient or operator.
- Moderate: We believe the level of concern is Moderate if a failure or latent design flaw could directly result in minor injury to the patient or operator. […].
- Major: We believe the level of concern is Major if a failure or latent flaw could directly result in death or serious injury to the patient or operator. […]
FDA guidance document: Content of the premarket submission for the software contained in medical devices
To determine the classification, FDA defines a set of lists. If a question is answered the software falls in the respective class. Examples of questions in list 1 are:
- Is the Software Device intended to be used in combination with a drug or biologic?
- Is the Software Device an accessory to a medical device that has a Major Level of Concern?
- Prior to mitigation of hazards, could a failure of the Software Device result in death or serious injury, either to a patient or to a user of the device? E.g. Does the Software Device control a life-supporting or life-sustaining function?
Please note that both definitions primarily are dependent on the severity of potential harms and not on risks. I.e. the probability of this harm is not what determines the software safety class respectively the level of concern.
Goals of classification
The IEC 62304 introduces the software safety classes to determine the extent of documentation to comply.
Table 1: The documentation depends on the safety class IEC 62304. E.g. for class A software no software architecture (chapter 5.3) is required. The numbers correspond to the chapters of the standard.
The FDA uses the levels of concern to determine the amount of documentation to be submitted. I.e. the level of concern does not influence the documentation to be compiled.
|Level of concern||x||x||x|
|Device hazard analysis||x||x||x|
|Software requirements specification||(x)||x||x|
|Architecture design chart||x||x|
|Software design specification||x||x|
|Description of the software environment||x||x|
|Verification and Validation documentation||(x)||x||x|
|Revision level history||x||x||x|
If you market your products in the US, the software safety class is irrelevant. You have to document according to class C anyhow. Do not confuse compilation and submission of documents!
Reduction of software safety class respectively level of concern
Reduction of software safety class
IEC 62304 permits a reduction of the software safety class by means that are external to the software only. Examples are:
- Physical hardware e.g. a stopper
- Other components containing hardware (electronics) and even software e.g. a watchdog
- User e.g. responding to a warning (not in IfU) or pressing an emergency stop
Reduction of the level of concern
The FDA expects measures to mitigate risks. However, the levels of concern are determined prior to these measures. I.e. a reduction of the level of concern does not impact the documentation to be submitted.