IEC 62304 software safety classes A, B and C, explained with examples

The first post in this series covered what Software as a Medical Device is. Here we look at the question most founders ask next: how careful does our development process need to be?

IEC 62304 answers that with three software safety classes: A, B and C. The class tells you which activities in the standard apply to you. It is one of the first decisions you make, and it is less mysterious than it sounds.

Here is how it works.

One question sits at the centre

IEC 62304:2006 with Amendment 1:2015 asks you to classify each software system by the worst harm it could contribute to (clause 4.3 a). In plain language:

• Class A: the software cannot contribute to a hazardous situation, or it can, but the risk is acceptable once you take into account risk controls outside the software.
• Class B: the software can contribute to a hazardous situation that leaves an unacceptable risk after those outside controls, and the worst possible harm is a non-serious injury.
• Class C: as for B, but the worst possible harm is death or serious injury.

"Serious injury" has a precise meaning in the standard (clause 3.23). It is an injury or illness that is life threatening, causes permanent impairment or damage to the body, or needs medical or surgical intervention to prevent that permanent impairment or damage.

Notice what the class does not ask: how likely your software is to fail. The standard's own guidance (Annex B, section B.4.3) explains that there is no agreed way to estimate how often software fails, so it suggests assuming the worst case, that the failure happens, and looking at what follows. That makes the decision simpler, not harder. You do not need statistics. You need an honest picture of the consequences.

Three examples to make it concrete

These are illustrations, not rulings. Your own answer depends on your intended purpose and your risk analysis.

A sleep trends dashboard for clinicians. Patients wear a consumer tracker, and the software shows a clinician weekly sleep patterns to discuss at the next appointment. If a chart displays wrong data, the clinician sees it alongside the patient's own account, and no treatment decision rests on the chart alone. A team could reasonably conclude that the risk is acceptable once those outside controls are taken into account, giving class A.

A guided physiotherapy app. The software adjusts a home exercise programme as a patient reports pain levels. If it progresses the programme too quickly, the patient might strain a muscle. That is an injury, but not a serious one under the definition above. That points towards class B.

An insulin dose calculator. The software recommends a dose from glucose readings and carbohydrate intake. A wrong dose could cause severe hypoglycaemia. That is serious harm, which points towards class C.

Outside safety nets can change the answer

You might wonder whether a human check counts. It can.

The standard lets you take into account risk control measures that sit outside the software system (clause 4.3 a, Note 1). These can be hardware, an independent software system, healthcare procedures, or other means. If one of them genuinely reduces the risk to an acceptable level, the class can be lower.

For example, if a pharmacist independently checks each dose before it reaches the patient, and that check is a documented, verified part of how the product is used, it may change the analysis for a dosing tool.

Two things make this work well:

1. The control has to be real. It belongs in your risk management file as a risk control measure, and you need evidence that it works. A sentence saying "clinicians will check" is not enough on its own.
2. You can redesign to get there. Clause 4.3 a) also allows you to add outside risk controls, including changes to your system architecture, and then reclassify.

You can classify parts of the system separately

Your product does not have to carry one class across all of it. When you break a software system into software items, each item inherits the class of the system by default. You can assign a different class to an item if you document a rationale that explains how it is segregated, meaning how a failure in one part cannot affect the other (clause 4.3 d).

This is useful in practice. The calculation engine of a dosing tool might be class C, while the screen that exports a monthly report could be class A, provided you can show the two are properly separated.

Two other rules from clause 4.3 are worth knowing:

• Until you assign a class, class C applies (clause 4.3 g). It is a good reason to decide early.
• Record the decision in your risk management file (clause 4.3 c), with your reasoning.

What changes as the class goes up

The class does not change what kind of team you are. It changes how much of your design you document and verify. Table A.1 in the standard summarises it. In broad terms:

Whatever the class, you need a development plan, software requirements, unit implementation, system testing against your requirements, a controlled release, configuration management, problem resolution, a maintenance plan and risk management under ISO 14971. We covered the details in our guide to what class A actually requires.

Class B adds a documented software architecture (clause 5.3), subdivision of the architecture into software units (clause 5.4.1), unit verification (clauses 5.5.2, 5.5.3 and 5.5.5), integration and integration testing (clause 5.6), and software risk analysis for each software item (clauses 7.1 to 7.3).

Class C adds detailed design of each software unit and its interfaces, and verification of that design (clauses 5.4.2 to 5.4.4), additional unit acceptance criteria (clause 5.5.4), and a few further planning and architecture tasks.

If your team already writes tests, uses version control and reviews code, much of class B will feel familiar. The new part is writing down the architecture and showing how risk reaches each piece of it.

Software safety class is not your device class

This is the most common mix-up, so it is worth saying clearly.

• Device class in the EU comes from MDR Annex VIII, mostly Rule 11 for software. It describes the whole product and your route to market: Class I, IIa, IIb or III.
• Device class in the US comes from the FDA's classification regulations. It also describes the whole product and your route to market: Class I, II or III.
• Software safety class comes from IEC 62304, clause 4.3. It describes the rigour of your software process: A, B or C.

If you are still working out your device class, our post on what class your medical device software is explains the logic. They tend to move in the same direction, because both depend on potential harm. But they are separate decisions under separate rules, and one does not set the other.

The FDA adds a third idea for premarket submissions. Its guidance on the content of premarket submissions for device software functions asks for a Basic or Enhanced documentation level, decided by its own risk-based test. That decides what you send the FDA. It sits alongside your IEC 62304 class rather than replacing it.

Choosing with confidence

Three habits make this decision easier:

1. Start from harm, not from effort. Ask what could happen to a person if the software failed, before thinking about how much work each class means.
2. Write the reasoning down. A short, clear rationale is worth more than a long one. It is the first thing a reviewer reads, as our SaMD audit checklist shows.
3. Revisit it when the product changes. A new feature can change the worst-case harm. Your class should follow.

Our classifier can help you think through both your device class and your likely software safety class. For a borderline case, a short conversation with a regulatory specialist is a good investment, and it goes much faster when your reasoning is already written down.

How we help

In QualiHQ your software safety class is recorded with your product, alongside its requirements, tests, risk register and releases. Requirements are traced to the tests that verify them, and a release cannot be approved while a linked requirement lacks a passing verification, so the evidence your class calls for builds up as you work.

Next in this series: risk. What ISO 14971 means by hazards, harm and acceptable risk, and why it is the most human part of the whole system.

Book a demo and we will help you think through your classification, step by step.