Safety classes according to IEC 62304 

IEC 62304 has introduced the concept of safety classification to allow medical device manufacturers to adapt the effort required for software documentation to the degree of possible harm that a software defect would cause. This article will help you determine the safety classes and document compliant with IEC 62304.

Update: No more presumption of conformity with safety class A?

1. Definition of the safety classes

IEC 62304:2007 distinguishes between three safety classes:

• First Class A: No injury or damage to health is possible
• Then Class B: Non-SERIOUS INJURY is possible
• Finally, Class C: Death or SERIOUS INJURY is possible

The standard defines a serious injury as an “injury or illness that is directly or indirectly life-threatening, resulting in permanent impairment of a body function or permanent damage to a body structure, or necessitates medical or surgical intervention to prevent permanent impairment of a body function or permanent damage to a body structure.“

Although this definition is clear, some of the most frequently asked questions in our free micro-consulting are about safety classes.

2. Changes due to Amendment I

2.1. Why the safety classes had to be redefined

“Finally,” you could say, there is a revised definition of safety classes. IEC 62304:2007 only considered the severity of possible harm. As a result, it was always possible to construct an arbitrarily unlikely case that would lead to serious harm. As a result, almost all manufacturers classified their software in safety class C, and the intention of the standard to concentrate documentation efforts on really relevant areas of the software was thwarted.

2.2. New definition of safety classes

The revised or supplemented version of IEC 62304 now defines the safety classes as follows:

• Safety class A: A software system falls into class A if it cannot contribute to a hazardous situation or (and this is new) if the software system can contribute to a hazardous situation which  does not result in  unacceptable risk after  consideration risk control measures external to the software system.
• Safety class B: A software system falls into class B if it can  contribute to a  hazardous situation which results in an unacceptable risk after consideration of  risk control measures (again to be implemented outside the software system), and the resulting possible harm is non-serious injury.
• Safety class C: This class is defined as class B, except that the possible resulting harm is a serious injury or can even lead to death.

The measures mentioned must be measures outside the software system. You can read more about this below.

2.3. Changes from IEC 62304:2015 (Amendment 1) to IEC 62304 “second edition”

The decision tree of the second edition of IEC 62304 no longer contains the almost absurd sentence as in IEC 62304:2015:

“Does failure of the software result in unacceptable risk?”

According to this, there could only have been safety class A software. Now it says, “Considering the external RCM: Can the hazardous situation lead to unacceptable risk?”.

That’s not all that great: the probability is in the risk and the word “can.” This regularly requires further explanation.

2.4. 100% probability still applies

The standard still says that the probability of a software error must be assumed to be 100%. This is misleading because every manufacturer contradicts that their software is 100% faulty. But that is not what the standard says.

Instead, the standard says: If a software error is possible, then the probability of its occurrence should not be discussed, but it should be assumed that it will occur. The safety classes should be selected exclusively based on the above decisions:

1. Can the software error cause a hazardous situation to occur at all?
2. If so, can the software error lead to unacceptable risks?
3. If so, what is the resulting severity?

As you can see, none of these questions have anything to do with the probability of the software error occurring. The assumption is that it will happen if it can happen.

Conclusion: The assumption of a 100% probability of software errors is needed when determining the safety class. Nobody claims that software errors occur 100% of the time.

2.5. Definition of “software system”

Amendment I does not change the definition of the term software system. The wording such as “The MANUFACTURER shall assign to each SOFTWARE SYSTEM a software safety class” suggests that the software system no longer represents the totality of all software in the medical device software but is instead to be understood per PESS or processor/memory area.

3. Purpose of the safety classes

Safety classes have the objective of controlling the documentation effort.

	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 safety class A software, manufacturers only have to document the software requirements (5.2) and the software release (5.8); for class B, the software architecture (5.3) and software verification (5.5 to 5.7) must be added, and for safety class C, the detailed design (5.4) must also be documented.

Change: Since Amendment I, system tests have also been mandatory for safety class A.

However, the Johner Institute considers many discussions about class B or C not very effective. What are the differences? That you don’t do detailed design and unit tests? These are things that students learn in their third semester. This discussion becomes completely absurd as soon as you look at the FDA. Regardless of the documentation level, all documents have to be prepared, not submitted.

4. Reduction in safety classes

4.1. Reduction according to IEC 62304:2007

IEC 62304 fixes: “If the RISK of death or SERIOUS INJURY resulting from a software error is subsequently reduced to an acceptable level (as defined in ISO 14971) by a hardware RISK CONTROL measure, either by reducing the consequences of the error or by reducing the probability of death or SERIOUS INJURY resulting from that error, the software safety class may be reduced from C to B.“

Hardware means either mechanics or at least a second system with an independent processor and memory area.

Individual components within a software system can also have a reduced, i.e. lower, safety class than the higher-level software system itself. However, manufacturers must justify this, which is usually only possible with the help of a documented and suitable software architecture.

4.2. Example

Does an emergency stop switch justify reducing the safety class of software by one class? The question is also interesting because it shows the whole dilemma of IEC 62304: On the one hand, the standard ignores probability when it comes to safety classes; on the other hand, when it comes to hardware measures, it talks about risks – which by definition involve probabilities:

This means that the question can only be answered from a risk management perspective: If the emergency stop switch reduces the risk to an acceptable level – and only then(!) – is the reduction in safety class justifiable. Since, in most cases, like this one, the risk reduction is only achieved by reducing the probability, you would have to justify by how many orders of magnitude the probability decreases and then check your risk acceptance matrix to see whether you then end up in an acceptable range. Therefore, the definition of your risk acceptance matrix, or the probability axis, must also be quantitative. Otherwise, you will lack a justification for why you have reduced the safety class of your software from C to B or from B to A.

You would have to assume a 100% probability of error for the software. If you could reduce the probability by two orders of magnitude by taking the measure (this alone will be difficult to argue), you would have a 1% probability of the system failing. The probability of harm will be even lower. But is the probability of damage achieved after the measure acceptable?

Of course, the assumption of 100% is absurd, which is why – in anticipation of the next version of 62304 – I am already arguing for failure probabilities of less than 100%.

4.3. Reduction in accordance with Amendment I

Amendment I clarifies that risk-minimizing measures can only reduce the software system’s safety class if implemented outside the software system, for example, in the system architecture.

This means reducing the safety class for standalone software is hardly conceivable. However, an external measure could also be a measure in clinical routine. Amendment I no longer refers to hardware measures.

5. Interaction of safety classes

5.1. Safety classes and classification according to MDD

A common question is, “Is there a connection between the safety class according to IEC 62304 and the classification according to MDD?”

There is no very strict correlation between the classification according to MDD and the safety class according to IEC 62304. It is not possible. An example:

If you have a highly critical device, let’s say class IIb, but the software has nothing to do with this criticality, this software may well be class A. Conversely, however, Class C software should not be classified as Class I. After all, Class C means that death or severe injury can explicitly occur.

As a rule of thumb, it can be assumed that active therapy devices are classified as Class IIa if nothing serious can happen; otherwise, they are Class IIb. Of course, this is only a rule of thumb; in individual cases, the classification rules must be clarified and discussed with the notified bodies in case of doubt (which is often the case).

Therefore, the short answer to the question is that a high classification, e.g. IIb, cannot be used to infer a high software safety class. The reverse is more likely, but not with mathematical conclusiveness.

5.2. Safety classes and documentation level

The safety classes are defined almost identically to the Level of Concern. However, there are two significant differences:

1. The Level of Concern influences the scope of the documentation to be submitted, not the documentation to be created.
2. In contrast to the other Levels of Concern and the safety classes, the Minor Level of Concern includes the aspect of probability.[CS1] 

5.3. Safety classes and functions

Manufacturers are inventive. Obviously enthusiastic about IEC 62304, one of them came up with the idea of linking the functions (UI elements) of a medical device directly to safety classes. This would allow him to directly identify all safety-critical software parts, verify them accordingly, and trace everything. A good idea?

Unfortunately, not: In the case of functions, i.e., elements of a user interface, a distinction is made between elements for input, selection, and display. These are, for example, switches, buttons, drop-down menus, graphics, texts, or input fields.

It may still be possible to assign a risk without knowing the architecture. For example, even without knowledge of a device’s inner workings, it is possible to estimate how high and how likely harm will be caused if data is displayed for the wrong patient or the controller of an infusion pump incorrectly receives the flow of an infusion solution.

What cannot be estimated without knowledge of the architecture, however, is the software’s contribution to this. Architecture means software and hardware architecture. It is possible that the software is not involved at all or that an error in it would be detected and controlled by a hardware control measure. Then, we would have high-risk but class-A software.

In other words, the functions, i.e., all types of elements of a user interface, regardless of whether they are realized in hardware or software, may allow a correlation with the risk but not with a software security class.

6. Examples: Safety classes for certain devices

6.1. Classification of monitoring software

IEC 62304 allows these classes to be reduced by hardware risk control measures. These control measures may themselves contain software. But what class does this “monitoring” software have?

The standard stipulates this:

The MANUFACTURER shall assign a software safety class to each SOFTWARE SYSTEM that contributes to implementing a RISK CONTROL measure. It is based on the potential impact of the hazard that is controlled by the RISK CONTROL measure.

This, in turn, means that the software with which the risk control measure is implemented has the same safety class as the software that is monitored/controlled with it.

6.2. PACS

PACS software can only be assigned to a safety class in accordance with IEC 62304 if the intended purpose is described in detail. If, for example, the software is intended/may be used to measure the anatomical structure in preparation for an operation or radiation planning, then (without wishing to anticipate a dedicated risk analysis) a severe injury is conceivable in the event of a software defect. The software system would, therefore, be class C. However, this does not mean that all system components would be class C. These must be described in the architecture (IEC 62304 Chapter 5.3).

A valued employee of a medical technology manufacturer drew our attention to a blog post in which the author comes to the following conclusion:

“The more you have to rely on software to treat the patient, to monitor its vital constants or to give a diagnosis, the higher the class.”

What do you think? I think the assessment that the higher the class, the greater the dependence on the device, is problematic. The degree of dependence impacts the probability of something happening but not the severity. However, according to EN 62304, only the maximum severity is relevant for the safety classification.

A comment on the blog post in the context of PACS goes on to say:

That kind of software is class B because it is not used alone in the diagnosis. It is always inserted in a chain of decisions for example, assessment by pairs, biopsy … The software in its environment can not be the cause of a severe injury. There are always other measures of protection to prevent a problem if it is buggey or crashes.

The Johner Institute also does not agree with the assessment that the software of a PACS viewer is class B. Of course, a right-left swap can lead to incorrect or delayed treatment (surgery, radiation). This has happened often enough. The fact that PACS are class IIb should also be an indication. The fact that there are “measures of protection to prevent” only reduces the probability and therefore does not justify a classification other than C.

7. Typical misunderstandings and errors with safety classes

Software safety classification in accordance with IEC 62304 is a recurring topic at our seminars, in-house workshops, and consultations. Participants and companies are motivated by the desire to lower the safety class as much as possible.

7.1. Assumption that the safety classes correspond to the level of concern

In fact, the definitions of safety classes and Levels of Concern seem to coincide. However, in contrast to the safety classes, the Levels of Concern aim to control the scope of the(!) documentation to be submitted, not(!) the documentation to be produced.

7.2. Assumption that the safety class can be derived from MDD class

One of the arguments I usually hear is as follows: The device is only Class I, i.e., the software cannot be Class C. This is not true in this form. There are Class I devices that, in the worst-case scenario, can lead to serious injury. The “worst-case scenario” is a statement of probability and, thus, of risk. However, the safety classification does not take probabilities into account. It is, therefore, a safety classification and not a risk classification.

7.3. Assumption that you can avoid a lot of documentation with class B

The next assumption is that you must do/document significantly less for class B. This is also only true to a minimal extent. Compared to class C, you only save the more detailed design – which does not have to be done down to method or even method signature level – and the dynamic component tests. But with all due respect, what kind of development department with even a hint of professionalism would do without unit tests?

7.4. Classification by the development department

Another mistake I have observed is that the software development team determines the safety class. Software does not have a safety class per se. In the sense of an FTA, this results from analyzing the consequences of an externally “visible” device error and analyzing how a PESS (programmable electrical subsystem) can contribute to such a device error. Therefore, the risk manager and system architect determine the safety class but not the software development department.

The output depends very much on the context of use. On the users, the type of use, etc. Without knowing this context, you cannot determine a safety class under any circumstances.

7.5. Assumption that components have a certain safety class

As I have just written, it is not your task as a development engineer to carry out the safety classification of the software (classes A, B, and C, according to IEC 62304). I am writing this because software engineers regularly ask me how they should proceed. In particular, they are asked to determine the safety class of components.

To put it bluntly, a safety class can never be assigned to a software item per se, not to a dll or any other component.

The safety class is derived from the surrounding software system. And the class of the software system is derived from the risk analysis.

Let me know (e.g., via web form) if I can help you with the security classification. I will be happy to do so quickly, confidentially, and usually free of charge.

f) Segregation not comprehensible in architecture

We also notice a rather “casual” justification as to why individual components of a software system have a lower security class than the software system as a whole. Without a documented architecture corresponding to reality, this cannot be argued.

g) Assumption that software is 100% faulty

There are often discussions about how you may be allowed to work with probabilities as part of the risk analysis, but you always have to assume 100% within the software (in accordance with IEC 62304). A good question!

By definition, a risk is the combination of severity and probability of damage. IEC 62304 does not, in fact, recognize probabilities, but only safety classes A (no injury possible) to C (serious injury or death possible). Of course, the probability of a software error is not 100%. IEC 62304 does not intend to discuss the risks. Rather, it aims to support manufacturers in concentrating the effort for documenting and testing software on the safety-critical areas of the software. This effort should only depend on the safety class, i.e., the possible consequences of an error within the software, and not on the probability. IEC 62304 says no more.

As part of a risk analysis (e.g., based on FMEA or FTA), it is perfectly possible to assume probabilities other than 100%—even within the software! These are two different philosophies that are not mutually exclusive.

h) Assumption that safety class has something to do with in/direct harm

We also discussed this at my meeting with the notified bodies. We debated whether the degree of directness to which software can contribute to harm impacts the safety class.

For example, while the software of a defibrillator is highly direct, the software for calculating drug interactions is less direct. One auditor said he would ensure that medical device manufacturers don’t declare doctors to be “token men in the middle” who, in reality, wouldn’t have a proper overview of what the device does.

I agree that there are different degrees of directness. However, I would question whether these have an impact on the safety class. The degree of directness affects the probability that a software error will lead to harm. However, this probability should not be considered in the safety classification, only the severity.

8. How you can cheat

IEC 62304 clearly defines the different safety classes for software. It also fixes the problem of safety classes being reduced by one class from C to B or from B to A through hardware measures. Nevertheless, notified bodies tell us how manufacturers seek and find “room for maneuver.”

Imagine the following scenario:

Scenario 1: Measure before security classification

A manufacturer places a medical device on the market in which a software defect cannot lead to any harm for patients or users due to a special design in the form of hardware. The software then has safety class A by definition.

Scenario 2: Measure according to security classification

A manufacturer places an identical medical device on the market. This time, however, he finds that a software defect can lead to serious harm. The software is, therefore, class C. To minimize the risk, he chooses the same measure in the form of hardware that excludes harm to patients and users. The manufacturer may, therefore, reduce the safety class of the software to B.

Is the order decisive for classification according to IEC 62304?

So is the order in which the software safety classes are defined according to IEC 62304 decisive and, therefore, only the choice of argumentation? The representatives of the notified bodies who were my guests agreed on the following line:

If a measure is so obvious that any electrical or mechanical engineering graduate would choose it that way, you can argue according to scenario 1. Otherwise, it is a measure you also want to see explicitly listed in the risk analysis.

9. Typical traps when working according to safety class A

IEC 62304 means well for us medical software developers: we can leave non-critical components – those in safety class A – virtually undocumented. No architecture, no code reviews, no documented tests. That’s wonderful, isn’t it? But be careful! I consider the generous omission of any documentation for safety class A components to be problematic for several reasons.

Trap 1: Compliance with the essential requirements

MDD / IVD

The Medical Devices Directive and, thus, the Medical Devices Regulation clearly require manufacturers to comply with software lifecycle processes. There are notified bodies that think (including me, by the way) that software development that does not include the collection and documentation of software requirements, the modeling of an architecture, code reviews, or tests does not meet this requirement (compliance with software life cycle processes), regardless of whether the software falls into safety class A.

Suppose a software item in safety class A is later reused in a different context and, therefore, falls into a higher safety class. In that case, you will have to catch up on the complete documentation for this component. This is more time-consuming than it would have been initially.

MDR / IVDR

The Medical Device Regulation MDR and the In-Vitro Diagnostics Regulation IVDR go one step further. Both require the following:

1. IT security according to the state of the art
2. Software verification
3. Software validation (also in the intended use environment, also in the intended technical environment (e.g. hardware, operating system, network)
4. Requirements for the technical environment, in particular for networks, hardware, operating systems
5. Instructions for use that specify these requirements
6. Description of the software and data processing, especially the algorithms (special requirement of the IVDR)
7. Description of the design phases
8. Description of the devices and components

Trap 2: Security classification and risk analysis

If you classify software, specifically a software system, in terms of security, this must be preceded by a risk analysis. Although it is not necessary to consider the probabilities in detail, it is definitely necessary to consider the severity of possible harm. Only if the output of this analysis shows that no harm can be caused by the software at all does this justify safety class A by definition.

But is there really no conceivable case in which something could happen? With stand-alone software in safety class A, you should ask yourself whether you are sure it is a medical device at all…

You must start risk management before the safety classification, but it doesn’t end there. For example, as part of a product follow-up in the field, you need to monitor that your assessments that justify safety class A, for instance, were correct. Companies often fail to do this.

Trap 3: Safety class A versus Minor Level of Concern

The FDA does not recognize safety class A and, especially, it does not recognize completely undocumented and untested code. This would not just be a “minor non-conformity” in the event of an audit. The minor level of concern, which roughly corresponds to the safety class, regulates the scope of the documentation to be submitted, not the documentation to be prepared! If you want to sell your device in the USA, you have no safety class A. Read more about the Level of Concern here.

Trap 4: Software quality

Documenting an architecture, testing, and reviewing code are all activities that should not only serve to fulfill regulatory requirements. Instead, they are proven best practices. Anyone who thinks they can do without them because of a safety class A only develops trivial programs or has no idea about professional software development. The consequences of this approach are apparent:

• The architecture will be flawed, changes to the software will be disproportionately costly, and the consequences are hardly foreseeable and often lead to errors.
• The software will be flawed, leading to frustration on the part of users or risks for patients, especially in the case of medical devices – which should not be the case with safety class A, however.
• Development will take longer because try-error coding will never be as efficient as carefully eliciting (and documenting) the requirements and modeling the architecture.

Trap 5: Compliance with IEC 62304?

Some companies divide the software into different safety classes – in line with IEC 62304. But do your developer colleagues even know which safety class the component they are currently working on has? Some companies struggle to ensure that the developers understand their specifications, for example, in the software development SOP. And now they are supposed to be able to do this, depending on the safety class?

10. Conclusion

If you are developing software you want to sell, develop all code according to safety class C. Sometimes, arguing about the right safety class takes longer than creating the documents. Most people don’t understand how little effort IEC 62304 and FDA-compliant documentation can mean and how much time it can ultimately save.