“Our software cannot hurt anyone. It is bound to be safety class A.” We hear this sentence regularly in initial conversations. Sometimes it is true. Often our honest assessment is a different one.
Some background: Alongside the risk class under the MDR, there is a second classification for software medical devices that makes an enormous difference: the software safety class under IEC 62304.
The software safety class under IEC 62304 is probably the single most consequential decision in the development of your software medical device. It determines how much architecture, design, verification and documentation you have to demonstrate. Between safety class A and safety class C lies a multiple of the effort, without anything changing in the core functionality of your product itself.
Classify too high and you burn budget and time that may be needed elsewhere. Classify too low and you risk a blocked medical device approval and the legal consequences of a non-conforming product.
This article takes you through the official decision tree of IEC 62304 step by step and makes the decision easier with practical advice and pointers.
We use two continuous examples from two different worlds: an insulin pump with microcontroller firmware and an obesity app for self-management support. We work through both examples step by step, until a traceably justified safety class stands at the end.
If you are looking for an overview of the standard as a whole and not only of the classification, you will find one in our article IEC 62304: Software life cycle processes for medical devices.
Our interactive tool for determining the safety class
In just 5 minutes, our interactive online tool lets you determine the safety class for your product and follow the decision step by step
→ Link to the tool
Table of Contents
- 1. Is IEC 62304 relevant for you?
- 2. How the safety class affects your development process
- 3. Easily confused: safety class ≠ risk class
- 4. The three safety classes A, B and C
- 5. The IEC 62304 decision tree step by step
- 6. Splitting up software: different safety classes for different parts
- 7. Edition 2 of IEC 62304
- 8. Conclusion
1. Is IEC 62304 relevant for you?
IEC 62304 applies to any software that is itself a medical device, and to any software that is part of a medical device. That covers two very different groups of manufacturers who rarely talk to each other in practice, even though they are subject to the same standard.
The embedded case: firmware on a microcontroller that reads out sensors, drives actuators or takes on safety functions. Here the software is a component in a physical device that does not work without it.
The standalone case: Software as a Medical Device (SaMD), meaning digital health applications (DiGA), mobile health apps, web applications, desktop software and clinical decision support systems. Here the software is the product.
The standard does not apply to pure wellness or fitness software without a medical intended purpose. If you are unsure at this point, the first step is deciding on qualification as a medical device. We have written a separate guide: Is your software a medical device? on exactly that.
2. How the safety class affects your development process
IEC 62304 scales its requirements through the safety class. It is not a label on the technical documentation but a cost driver that runs through the entire project.
Specifically, the safety class decides whether you need a documented software architecture, whether you have to produce a detailed software design down to unit level, whether unit verification with acceptance criteria has to be demonstrated, and how deep integration testing has to go. It also governs the scope of software risk management and the requirements for third-party software you use, in the language of the standard: SOUP (Software of Unknown Provenance).
The following graphic shows the process landscape of the standard. The chain 5.1 to 5.8 is the actual development process, with the supporting processes above and below it.
The process landscape of IEC 62304 at a glance
In practice, the safety class has a very strong influence on your project budget and your timeline. That is why it pays off to derive the classification cleanly.
3. Easily confused: safety class ≠ risk class
The most common confusion in this field by far: MDR risk classes I, IIa, IIb and III on the one side, and IEC 62304 safety classes A, B and C on the other. These are two completely separate systems with different purposes.
| MDR risk class | IEC 62304 safety class | |
|---|---|---|
| Values | I, IIa, IIb, III | A, B, C |
| Basis | MDR Annex VIII, for software above all Rule 11 | IEC 62304 section 4.3 |
| Result of | intended purpose and the MDR classification rules | your risk management according to ISO 14971 |
| Governs | conformity assessment procedure under the MDR, involvement of a notified body | software development process and depth of documentation |
| Applies to | the entire product | each software system of the product |
There is no fixed conversion table between the two. A product in MDR risk class III can contain software of safety class A, B or C. Conversely, a product in MDR risk class I may well contain class B software if that is what risk management produces.
What does hold true: both assignments should be justifiable consistently with each other. A contradiction between intended purpose, risk management file and safety class is a classic audit finding. If your risk management file describes possible serious harm while your entire software is run as class A, you will need a very good explanation for that.
You will find more on determining the risk class under the MDR in our article on the classification of software medical devices under the MDR.
4. The three safety classes A, B and C
Let us start with the short version. All three classes revolve around the same question: how bad can it get if the software fails?
| Class | Rule of thumb |
|---|---|
| A | No harm can occur. |
| B | Harm can occur, but not serious harm. |
| C | Serious harm can occur or someone can die. |
This is deliberately a simplified description, and three further points have to be taken into account:
- Measures outside the software count. What is assessed is what remains after all protective measures outside the software system have taken effect. A hardware cut-off counts, a check inside the same software does not.
- What matters is the remaining risk. Your software stays safety class A as long as the hazard does not lead to an unacceptable risk. You set the yardstick for that yourself in your risk management plan.
- The probability of failure does not count. Test coverage, code quality and field experience are not arguments here. The standard sets the probability of a software failure at 100 percent. So if a software error could kill someone, for the purposes of safety classification the standard deliberately does not care how unlikely that error might be (a rare race condition in the code that only occurs every three years still counts).
Incidentally, “serious” is a defined term. It means an injury or illness that
- is life threatening,
- results in permanent impairment of a body function or permanent damage to a body structure,
- or necessitates medical or surgical intervention to prevent exactly such permanent damage.
Permanent here means irreversible. Minor impairments expressly do not count.
4.1 Safety classes A, B and C: differences and consequences
Roughly summarised, the basic pattern is this: class A requires the smallest scope. Class B additionally requires, among other things, software architecture, unit verification and integration testing. Class C adds the detailed software design down to unit level and tightens the criteria for unit verification. The details go beyond the scope of this article. That is why we have attached an Excel document as a download for you. The document breaks down the requirements of IEC 62304 in detail. It shows which requirements apply specifically to which safety class.
Download: Excel table of the IEC 62304 requirements, broken down by software safety class
IEC 62304 does not place the same requirements on every piece of medical software. Which requirements apply depends on the software’s safety class A, B or C. This table lists all requirements of the standard and marks the safety classes to which each requirement applies. That gives you a better view of the actual workload.
Leave your e-mail address here and we will send you the Excel file:
4.2 What you need before you can classify
The official answer is: the classification is a result of your risk management according to ISO 14971 and not a separate exercise. For that you need:
- a formulated intended purpose, because without it there is no way to determine which hazardous situations are relevant in the first place.
- the identified hazards and the hazardous situations that arise from them.
- the possible harms with their severity.
- the defined risk control measures and the information on where exactly they are implemented, inside or outside the software.
The risk management process according to ISO 14971 as the basis for classification
If you are still at the beginning with the intended purpose: we have written a separate article on phrasing the intended purpose for software medical devices.
A practical note: for many products the safety class can be estimated fairly reliably from rough planning alone, long before the risk management file is finished. It is usually enough to draw up a list of the possible harms and ask whether a failure of the software can lead there directly or indirectly. You should of course substantiate this afterwards with the finished risk management file. Even so, it can be very helpful to have a rough feel at the start of a product development for which safety class the software systems are likely to fall into.
5. The IEC 62304 decision tree step by step
Our interactive tool for determining the safety class
In just 5 minutes, our interactive online tool lets you determine the safety class for your product and follow the decision step by step
→ Link to the tool
For the classification, the standard provides its own decision tree, shown in Figure 3 of section 4.3. The sequence is binding, and it is pleasingly short: three decision questions, one evaluation step in between, three possible outcomes.
Decision tree for the software safety class under IEC 62304
We will now work through this tree step by step and apply it to two concrete products in parallel.
Example 1, embedded: insulin pump. A wearable insulin pump for patients with type 1 diabetes mellitus, without coupling to a continuous glucose sensor. The firmware on the microcontroller controls the drive, calculates the amount of insulin to be delivered from user inputs and a basal rate profile, and monitors the pumping process. On top of that there is an independent hardware-side limit on the maximum delivery volume per unit of time. Under the MDR, such a product is typically risk class IIb via Rule 12.
Example 2, standalone: obesity app for self-management support. A digital health application for people with obesity. The app provides a structured exercise programme with guided workouts, a nutrition diary, recipe suggestions and behavioural modules. The intended purpose is expressly to support self-management and not to deliver multimodal obesity therapy. The app does not make a diagnosis, it does not calculate a drug dose, and it does not intervene in an ongoing therapy. Through the catch-all tier of Rule 11 of the MDR, it ends up in risk class I (an assumption, see the note).
Note: the assessment as MDR risk class I is debatable, as we explain in a separate article on class I medical devices. In this article, however, we are only concerned with the safety class under IEC 62304 for now. We will spare you the “risk class I vs. IIa” discussion here.
Starting point: every piece of software is safety class C to begin with
The tree starts at the top left with “Class C (by default)”. That is not a graphical flourish but is expressly stated in section 4.3 of the standard: as long as no safety class has been assigned to a software system, the requirements of class C apply.
Two basic assumptions apply throughout.
First: the probability of a software failure is set at 100%. Arguments such as “the code is well tested”, “the module has been in the field for five years” or “this error is extremely unlikely” are not admissible at this point.
Second: only risk control measures outside the software system may be taken into account to reduce the safety class.
Note: the assumption “probability equals 100%” applies to the failure of the software, not to the entire chain of events. Whether that failure actually turns into harm of a particular severity is something you may very well assess within your risk management according to ISO 14971.
Step 1: Can a hazardous situation arise from a failure of the software?
The first question is not aimed at the harm but at the situation preceding it. It asks whether a failure of the software can lead to someone being exposed to a hazard at all. If the answer is no, the software is safety class A and the tree ends here.
It is important that indirect paths count too. Incorrectly displayed information is a hazardous situation if a treatment decision is made on the basis of it. Software does not have to drive actuators to be dangerous.
- The insulin pump example: a failure of the dose calculation or the drive control leads to an over- or underdose of insulin. That is unambiguously a hazardous situation. Answer: yes.
- The obesity DiGA example: here opinions differ. Whether you end up in safety class A or B is a matter of interpretation. At first glance an exercise programme cannot harm anyone. Think it through and scenarios can be constructed: an exercise that is unsuitable for a patient with a pre-existing cardiac condition, or a nutrition plan with too low a calorie intake over a longer period. For the purposes of this article we will play it safe. Answer: yes.
Step 2: Evaluate external risk control measures
Now you examine which measures outside the software system intercept the hazardous situation. In a note to section 4.3, the standard names four categories: hardware, an independent software system, health care procedures and other means.
Typical admissible measures are:
- Hardware limits: an electrical or mechanical limit on the maximum delivery of energy or of an active substance that works independently of the firmware (software).
- Mechanical design: a geometry that physically rules out a dangerous movement, or a stop that limits a travel distance.
- An independent software system: a separate monitoring controller with its own firmware that shuts the main system down. This is the strongest lever for embedded manufacturers and is often overlooked, because many assume that software can never count as an external measure.
- Organisational measures in the clinical workflow: the treating physician checks every therapy recommendation from the system against the findings before acting on it. A medication adjustment is released under the four-eyes principle. A current laboratory value is mandatory before every dose adjustment.
Not admissible, by contrast, is:
- Any measure inside the same software system has no effect on the classification. A software component that monitors another component is perfectly sensible as a risk control measure, but it does not lower the safety class.
Examples:
- The insulin pump example: the independent hardware limit on the maximum delivery volume works independently of the firmware. It counts as an external measure.
- The obesity DiGA example: no clinician in between, no hardware, no mandatory clinical workflow. There is no external measure that can be credited.
Step 3: Does an unacceptable risk remain?
Once the external measures have been taken into account, you check whether the remaining risk is still unacceptable. If the answer is no (the residual risk is acceptable), the software is safety class A, even though a hazardous situation was possible in the first step.
This is the second route to class A, and in practice it is regularly confused with the first. The difference matters: in the first case the software cannot contribute to a hazard at all. In the second case it can, but the residual risk is acceptable. Both lead to class A but require entirely different justifications.
The yardstick for “unacceptable” is your own acceptance criteria as laid down in your risk management plan. Not your gut feeling, and not a mere comparison with competitor products either.
- The insulin pump example: even with the hardware limit, a relevant misdosing within the limited range remains possible. With insulin, even a moderate overdose is clinically significant. The residual risk is unacceptable, so we move on to step 4.
- The obesity DiGA example: this is where it gets interesting. The exercise programme is aimed at a population without acute contraindications, the workouts stay within the range of everyday physical activity, and the nutrition plan remains in a corridor that professional dietary counselling could have produced without the app as well. With cleanly set acceptance criteria and a clearly formulated intended purpose with defined exclusion criteria, the remaining risk can be justified as acceptable. Result: class A. (here too opinions differ and there is room for interpretation)
Careful: this step is the most popular lever for self-deception. This is where most of the class A justifications arise that do not hold up in an audit. If you notice that your line of argument at this point is getting longer than the rest of the classification, that is a warning sign. The boundary between A and B remains contested, though, and that should be said openly. For our obesity DiGA, class A is justifiable, but it is not the only defensible position. Another manufacturer with a different risk management file and different acceptance criteria would arrive at class B for the same product, and that would not be fundamentally wrong either.
Step 4: What severity of injury is possible?
Anyone who has got this far ends up in class B or C. Now the severity of the possible harm decides on its own. A non-serious injury means class B. Death or a serious injury mean class C.
What counts here is the worst case of intended use and of reasonably foreseeable use. Not the typical case, not the average, but also not every theoretically constructible scenario.
- The insulin pump example: an insulin overdose can trigger severe hypoglycaemia. If that is not treated in time and sufficiently, seizure, unconsciousness, coma and death are possible consequences. That is indisputably a serious injury. Result: class C.
- The obesity DiGA example: this example already left the tree at step 3 and ended up in class A.
The insulin pump shows nicely where the limits of optimising lie. The hardware limit is a sensible and effective measure, but it does not fully prevent the critical harm. That is why it does not lower the class from C to B.
6. Splitting up software: different safety classes for different parts
The standard does not require your entire software to run in a single class. It distinguishes three levels: the software system as the top level, the software items, and the software units as the smallest level that is not decomposed further. A product can also contain several software systems.
In principle, a software item inherits the class of the system above it. You may, however, classify an item lower if you can justify that it is separated from the more highly classified parts. This separation is called segregation. The standard phrases it neutrally as to direction in the annex, but what matters in practice is protection upwards: the lower classified item must not be able to influence the higher classified one, neither through data flow nor through control flow nor through shared resources such as memory, CPU time or registers. For class C, section 5.3.5 of the standard additionally requires you to identify the segregation necessary for risk control and to state how its effectiveness is ensured.
In practical terms this means: you can run through the decision tree separately for every separated software system and for every segregated item. In a medical device with a touch display, the control firmware may run under class C while certain parts of the user interface are developed under class A on a separate processor. The effort for the non-critical part then drops considerably.
Whether that pays off is by no means a foregone conclusion, though. Two arguments often speak against it. First, different classes mean different development processes within the same team, and that is hard to coordinate in practice. Anyone working on a class C item and a class A item in the same sprint needs two different chains of evidence, two review depths and two definitions of “done”. Second, the split itself generates documentation effort: you have to describe system boundaries, justify segregation and demonstrate its effectiveness. Those are precisely the places where an auditor will start.
Our recommendation: split things up if a large, clearly delimitable and non-critical portion exists, typically the user interface, reporting, synchronisation or analytics, and if that boundary is already in the architecture anyway. Leave it alone if you would first have to construct the boundary. In many projects it is simpler and ultimately cheaper to run everything under one class than to write three justifications that can be attacked.
Splitting up using the example of a dialysis machine: safety core, treatment workflow and non-medical module
7. Edition 2 of IEC 62304
Work on IEC 62304 is still ongoing. A second edition is in preparation, and it will change the system of safety classes considerably. What applies, and will continue to apply for now, is IEC 62304:2006 with Amendment 1 of 2015. That will not change for the foreseeable future.
Timeline: the second edition has been stuck in the standardisation process for more than ten years, and the road there has been anything but straight. The second draft is currently out for comment, after which two voting stages remain. The IEC forecasts October 2028, with 2029 being more realistic. What is decisive, however, is the unplannable step after that: citation in the Official Journal of the EU, because only that creates the presumption of conformity. For context: the MDR has applied since May 2021, and the current edition of IEC 62304 is still not listed to this day. Realistically, we are talking about the early 2030s.
Changes in the new Edition 2: (everything that follows is draft status and may still change.)
- The three safety classes are replaced by two software process rigor levels. Level I corresponds to today’s class A, level II combines B and C.
- Software that implements a risk control measure always falls into level II. Measures outside the software remain creditable but require evidence of effectiveness.
- Software architectural design is to apply to both levels.
- The scope broadens from medical device software to health software in general.
What Edition 2 does not bring, contrary to many articles: cybersecurity is not pulled into the standard. The project’s design specification expressly states that security is regulated outside IEC 62304. The main reference is to IEC 81001-5-1. AI, too, is only addressed via an informative annex in the current draft, that is, without binding requirements. For the requirements on AI, read our articles on MDR requirements for AI and on the AI Act.
What you should do today: you do not need to do anything differently. Carry on working with the current version of IEC 62304. It will be a while before the new version becomes the new standard in practice.
8. Conclusion
Determining the software safety class always follows the same path: can a failure of the software lead to a hazardous situation, which measures outside the software intercept it, does an unacceptable risk remain afterwards, and how severe would the possible harm be? Four checks, whose results you draw from your risk management.
The boundary between class B and class C is settled somewhat more quickly, because the severity of the harm is more obvious. Far more contested is the boundary between class A and class B, and very different views exist on it.
The second edition will change the system and turn three classes into two rigor levels. It will be years, though, before that becomes binding for you. Until then, the decision tree you have worked through in this article applies.
Are you planning a software medical device?
Are you planning to build medical software, a DiGA or an embedded software project? Get in touch with us. We develop regulated medical software (health apps, DiGA, web platforms and more) and embedded software on a contract basis.
