„Unsere Software kann niemandem wehtun. Die läuft bestimmt unter Sicherheitsklasse A.“ Diesen Satz hören wir in Erstgesprächen regelmäßig. Manchmal stimmt er. Oft ist unsere ehrliche Einschätzung eine andere.
Zum Hintergrund: Neben der Risikoklasse nach MDR gibt es eine weitere Klassifizierung für Software-Medizinprodukte, die einen enormen Unterschied macht: die Sicherheitsklasse nach IEC 62304.
Die Software-Sicherheitsklasse nach IEC 62304 ist die wohl folgenreichste Einzelentscheidung für die Entwicklung Ihres Software-Medizinprodukts. Sie legt fest, wie viel Architektur, Design, Verifizierung und Dokumentation Sie nachweisen müssen. Zwischen Sicherheitsklasse A und Sicherheitsklasse C liegt ein Vielfaches an Aufwand, ohne dass sich an der Kernfunktionalität Ihres Produkts selbst etwas ändert.
Wer zu hoch klassifiziert, verbrennt Budget und Zeit, die ggf. an anderen Stellen benötigt werden. Wer zu niedrig klassifiziert, riskiert eine blockierte Medizinprodukt-Zulassung und die rechtlichen Konsequenzen von einem nicht-konformen Produkt.
Dieser Artikel führt Sie Schritt für Schritt durch den offiziellen Entscheidungsbaum der IEC 62304 und vereinfacht Ihnen die Entscheidung durch hilfreiche Ratschläge und Hinweise.
Wir nutzen dafür zwei durchgehende Beispiele aus zwei Welten: eine Insulinpumpe mit Mikrocontroller-Firmware und eine Adipositas-App zur Selbstmanagement-Unterstützung. Beide Beispiele durchlaufen wir Schritt für Schritt, bis am Ende eine nachvollziehbar begründete Sicherheitsklasse steht.
Falls Sie einen Überblick über die gesamte Norm suchen und nicht nur über die Klassifizierung, finden Sie den in unserem Artikel IEC 62304: Software-Lebenszyklus-Prozesse von Medizinprodukten.
Unser interaktives Tool zur Bestimmung der Sicherheitsklasse
In nur 5 Minuten können Sie mit unserem interaktiven Online-Tool die Sicherheitsklasse für Ihr Produkt bestimmen und die Entscheidung Schritt für Schritt nachvollziehen
→ Link zum Tool
Inhaltsverzeichnis
- 1. Ist die IEC 62304 für Sie relevant?
- 2. Auswirkungen der Sicherheitsklasse auf Ihren Entwicklungsprozess
- 3. Verwechslungsgefahr: Sicherheitsklasse ≠ Risikoklasse
- 4. Die drei Sicherheitsklassen A, B und C
- 5. Der Entscheidungsbaum der IEC 62304 Schritt für Schritt
- 6. Software aufteilen: unterschiedliche Sicherheitsklassen für unterschiedliche Teile
- 7. Die Edition 2 der IEC 62304
- 8. Fazit
1. Ist die IEC 62304 für Sie relevant?
Die IEC 62304 gilt für jede Software, die selbst ein Medizinprodukt ist, und für jede Software, die Teil eines Medizinprodukts ist. Das trifft zwei sehr unterschiedliche Herstellergruppen, die in der Praxis selten miteinander sprechen, obwohl sie derselben Norm unterliegen.
Der Embedded-Fall: Firmware auf einem Mikrocontroller, die Sensorik ausliest, Aktorik ansteuert oder Sicherheitsfunktionen übernimmt. Die Software ist hier eine Komponente in einem physischen Gerät, das ohne sie nicht funktioniert.
Der Standalone-Fall: Software as a Medical Device (SaMD), also digitale Gesundheitsanwendungen (DiGA), mobile Health Apps, Web-Anwendungen, Desktop-Software und Clinical Decision Support Systems. Hier ist die Software das Produkt.
Nicht anwendbar ist die Norm auf reine Wellness- oder Fitness-Software ohne medizinische Zweckbestimmung. Wenn Sie an dieser Stelle unsicher sind, ist die Entscheidung der Qualifizierung als Medizinprodukt der erste Schritt. Dazu haben wir einen eigenen Leitfaden: Ist Ihre Software ein Medizinprodukt? verfasst.
2. Auswirkungen der Sicherheitsklasse auf Ihren Entwicklungsprozess
Die IEC 62304 skaliert ihre Anforderungen über die Sicherheitsklasse. Sie ist kein Etikett auf der technischen Dokumentation, sondern ein Aufwandstreiber, der sich durch das gesamte Projekt zieht.
Konkret entscheidet die Sicherheitsklasse darüber, ob Sie eine dokumentierte Software-Architektur brauchen, ob Sie ein detailliertes Software-Design bis auf Unit-Ebene erstellen müssen, ob Unit-Verifizierung mit Akzeptanzkriterien nachzuweisen ist und wie tief die Integrationsprüfung gehen muss. Sie steuert außerdem den Umfang des Software-Risikomanagements und die Anforderungen an eingesetzte Fremdsoftware, in der Sprache der Norm: SOUP (Software of Unknown Provenance).
Die folgende Grafik zeigt die Prozesslandschaft der Norm. Die Kette 5.1 bis 5.8 ist der eigentliche Entwicklungsprozess, darüber und darunter liegen die begleitenden Prozesse.
Die Prozesslandschaft der IEC 62304 im Überblick
In der Praxis beeinflusst die Sicherheitsklasse Ihr Projektbudget und Ihre Timeline sehr stark. Deshalb lohnt es sich, die Klassifizierung sauber herzuleiten.
3. Verwechslungsgefahr: Sicherheitsklasse ≠ Risikoklasse
Die häufigste Verwechslung in diesem Themenfeld überhaupt: MDR-Risikoklasse I, IIa, IIb und III auf der einen Seite und IEC-62304-Sicherheitsklasse A, B und C auf der anderen Seite. Dies sind zwei vollständig getrennte Systeme mit unterschiedlichem Zweck.
| MDR-Risikoklasse | IEC-62304-Sicherheitsklasse | |
|---|---|---|
| Werte | I, IIa, IIb, III | A, B, C |
| Grundlage | MDR Anhang VIII, für Software vor allem Regel 11 | IEC 62304 Abschnitt 4.3 |
| Ergebnis von | Zweckbestimmung und Klassifizierungsregeln der MDR | Ihrem Risikomanagement nach ISO 14971 |
| Steuert | Konformitätsbewertungsverfahren nach MDR, Einbindung einer Benannten Stelle | Software-Entwicklungsprozess und Dokumentationstiefe |
| Gilt für | das gesamte Produkt | jedes Software-System des Produkts |
Es gibt keine feste Umrechnungstabelle zwischen beiden. Ein Produkt der MDR-Risikoklasse III kann Software der Sicherheitsklasse A, B oder C enthalten. Umgekehrt kann ein Produkt der MDR-Risikoklasse I durchaus Software der Klasse B enthalten, wenn das Risikomanagement dies ergibt.
Was aber gilt: Beide Zuordnungen sollten zueinander konsistent begründbar sein. Ein Widerspruch zwischen Zweckbestimmung, Risikoakte und Sicherheitsklasse ist ein klassischer Auditbefund. Wenn Ihre Risikomanagementakte einen möglichen schweren Schaden beschreibt, Ihre gesamte Software aber als Klasse A geführt wird, brauchen Sie dafür eine sehr gute Erklärung.
Mehr zur Bestimmung der Risikoklasse nach MDR finden Sie in unserem Artikel zur Klassifizierung von Software-Medizinprodukten nach MDR.
4. Die drei Sicherheitsklassen A, B und C
Fangen wir mit der Kurzfassung an. Bei allen drei Klassen geht es um dieselbe Frage: Wie schlimm kann es ausgehen, wenn die Software versagt?
| Klasse | Merksatz |
|---|---|
| A | Es kann kein Schaden entstehen. |
| B | Es kann ein Schaden entstehen, aber kein schwerwiegender. |
| C | Es kann ein schwerwiegender Schaden entstehen oder jemand sterben. |
Dies ist bewusst eine vereinfachte Beschreibung und zusätzlich müssen folgende drei Dinge beachtet werden:
- Maßnahmen außerhalb der Software werden mitgerechnet. Bewertet wird, was übrig bleibt, nachdem alle Schutzmaßnahmen außerhalb des Software-Systems gewirkt haben. Eine Hardware-Abschaltung zählt, eine Prüfung innerhalb derselben Software nicht.
- Maßgeblich ist das verbleibende Risiko. Ihre Software bleibt Sicherheitsklasse A, solange aus der Gefährdung kein unvertretbares Risiko entsteht. Den Maßstab dafür legen Sie in Ihrem Risikomanagementplan selbst fest.
- Die Fehlerwahrscheinlichkeit zählt nicht. Testabdeckung, Codequalität und Felderfahrung sind hier keine Argumente. Die Norm setzt die Wahrscheinlichkeit eines Software-Versagens auf 100 Prozent. Wenn also durch einen Software-Fehler ein Mensch sterben könnte, ist es der Norm für die Sicherheitsklassifizierung bewusst egal, wie unwahrscheinlich dieser Fehler sein könnte (eine seltene Race Condition im Code, die nur alle 3 Jahre auftritt, zählt trotzdem).
„schwerwiegend“ ist übrigens ein definierter Begriff. Gemeint ist eine Verletzung oder Erkrankung, die
- lebensbedrohlich ist,
- die zu einer dauerhaften Beeinträchtigung einer Körperfunktion oder einer dauerhaften Schädigung einer Körperstruktur führt,
- oder die einen medizinischen oder chirurgischen Eingriff erfordert, um genau eine solche dauerhafte Schädigung zu verhindern.
Dauerhaft meint dabei irreversibel. Geringfügige Beeinträchtigungen zählen ausdrücklich nicht dazu.
4.1 Sicherheitsklasse A, B und C: Unterschiede und Auswirkungen
Das Grundmuster ist grob zusammengefasst: Klasse A verlangt den geringsten Umfang. Klasse B fordert zusätzlich u.a. Software-Architektur, Unit-Verifizierung und Integrationstests. Klasse C ergänzt das detaillierte Software-Design bis auf Einheitenebene und verschärft die Kriterien für die Unit-Verifizierung. Die Details sprengen den Umfang dieses Artikels. Daher haben wir hierfür ein Excel-Dokument als Download für Sie beigefügt. Das Dokument schlüsselt die Anforderungen der IEC 62304 detailliert auf. Dabei zeigt es, welche Anforderungen speziell bei welcher Sicherheitsklasse gelten.
Download: Excel-Tabelle zu den Anforderungen der IEC 62304, aufgeschlüsselt nach Software-Sicherheitsklassen
Die IEC 62304 stellt nicht an jede medizinische Software dieselben Anforderungen. Welche Anforderungen gelten, hängt von der Sicherheitsklasse A, B oder C der Software ab. Diese Tabelle listet alle Anforderungen der Norm auf und kennzeichnet die Sicherheitsklassen, für die die jeweilige Anforderung gilt. So können Sie den tatsächlichen Arbeitsumfang besser überblicken.
Hinterlassen Sie hier Ihre E-Mail-Adresse und wir schicken Ihnen die Excel-Datei zu:
4.2 Was Sie brauchen, bevor Sie klassifizieren können
Die offizielle Antwort lautet: Die Klassifizierung ist ein Ergebnis Ihres Risikomanagements nach ISO 14971 und kein separater Vorgang. Sie brauchen dafür:
- eine formulierte Zweckbestimmung, denn ohne sie lässt sich nicht bestimmen, welche Gefährdungssituationen überhaupt relevant sind.
- die identifizierten Gefährdungen und die daraus entstehenden Gefährdungssituationen.
- die möglichen Schäden mit ihrer Schwere.
- die definierten Risikobeherrschungsmaßnahmen und die Information, wo genau diese implementiert sind, innerhalb oder außerhalb der Software.
Der Risikomanagement-Prozess nach ISO 14971 als Grundlage der Klassifizierung
Falls Sie bei der Zweckbestimmung noch am Anfang stehen: Wir haben dazu einen eigenen Artikel zur Formulierung der Zweckbestimmung für Software-Medizinprodukte geschrieben.
Praxisnaher Hinweis: Bei vielen Produkten lässt sich die Sicherheitsklasse schon mit einer groben Planung recht zuverlässig abschätzen, lange bevor die Risikoakte fertig ist. Es reicht meist, sich eine Liste der möglichen Schäden zu machen und die Frage zu stellen, ob ein Versagen der Software auf direktem oder indirektem Weg dorthin führen kann. Natürlich sollten Sie dies danach nochmal durch die fertige Risikomanagementakte belegen. Trotzdem kann es sehr hilfreich sein, zum Anfang einer Produktentwicklung schon mal ein grobes Gefühl zu haben, in welche Sicherheitsklasse die Software-Systeme vermutlich fallen.
5. Der Entscheidungsbaum der IEC 62304 Schritt für Schritt
Unser interaktives Tool zur Bestimmung der Sicherheitsklasse
In nur 5 Minuten können Sie mit unserem interaktiven Online-Tool die Sicherheitsklasse für Ihr Produkt bestimmen und die Entscheidung Schritt für Schritt nachvollziehen
→ Link zum Tool
Die Norm liefert für die Klassifizierung einen eigenen Entscheidungsbaum, abgebildet in Abbildung 3 des Abschnitts 4.3. Der Ablauf ist verbindlich, und er ist erfreulich kurz: drei Entscheidungsfragen, ein Bewertungsschritt dazwischen, drei mögliche Ergebnisse.
Entscheidungsbaum zur Software-Sicherheitsklasse nach IEC 62304
Wir gehen diesen Baum jetzt Schritt für Schritt durch und wenden ihn dabei parallel auf zwei konkrete Produkte an.
Beispiel 1, Embedded: Insulinpumpe. Eine tragbare Insulinpumpe für Patienten mit Diabetes mellitus Typ 1, ohne Kopplung an einen kontinuierlichen Glukosesensor. Die Firmware auf dem Mikrocontroller steuert den Antrieb, berechnet aus Nutzereingaben und einem Basalratenprofil die abzugebende Insulinmenge und überwacht den Pumpvorgang. Zusätzlich gibt es eine unabhängige, hardwareseitige Begrenzung der maximalen Abgabemenge pro Zeiteinheit. Unter der MDR ist ein solches Produkt über Regel 12 typischerweise Risikoklasse IIb.
Beispiel 2, Standalone: Adipositas-App zur Selbstmanagement-Unterstützung. Eine digitale Gesundheitsanwendung für Menschen mit Adipositas. Die App liefert ein strukturiertes Bewegungsprogramm mit angeleiteten Übungen, ein Ernährungstagebuch, Rezeptvorschläge und verhaltensbezogene Module. Die Zweckbestimmung ist ausdrücklich die Unterstützung des Selbstmanagements und nicht die Durchführung einer multimodalen Adipositastherapie. Die App stellt keine Diagnose, sie berechnet keine Medikamentendosis und sie greift nicht in eine laufende Therapie ein. Über die Auffangstufe von Regel 11 der MDR landet sie in der Risikoklasse I (Annahme, siehe Hinweis).
Hinweis: Die Einschätzung der Risikoklasse I nach MDR ist diskutabel, wie wir in einem anderen Artikel zur Klasse I bei Medizinprodukten erläutern. Im hier vorliegenden Artikel geht es uns aber erstmal nur um die Sicherheitsklasse nach IEC 62304. Wir ersparen Ihnen diese „Risikoklasse I vs. IIa“-Diskussion hier mal.
Startpunkt: Jede Software ist zunächst Sicherheitsklasse C
Der Baum beginnt oben links mit „Klasse C (standardmäßig)“. Das ist keine grafische Spielerei, sondern in Abschnitt 4.3 der Norm ausdrücklich festgehalten: Solange einem Software-System keine Sicherheitsklasse zugewiesen ist, gelten die Anforderungen der Klasse C.
Zwei Grundannahmen gelten dabei durchgehend.
Erstens: Die Wahrscheinlichkeit eines Software-Versagens wird mit 100% angesetzt. Argumente wie „der Code ist gut getestet“, „das Modul läuft seit fünf Jahren im Feld“ oder „dieser Fehler ist extrem unwahrscheinlich“ sind an dieser Stelle unzulässig.
Zweitens: Nur Risikobeherrschungsmaßnahmen außerhalb des Software-Systems dürfen zur Verringerung der Sicherheitsklasse berücksichtigt werden.
Hinweis: Die Annahme „Wahrscheinlichkeit gleich 100%“ gilt für das Versagen der Software, nicht für die gesamte Ereigniskette. Ob aus diesem Versagen tatsächlich ein Schaden einer bestimmten Schwere wird, dürfen Sie im Rahmen Ihres Risikomanagements nach ISO 14971 sehr wohl bewerten.
Schritt 1: Kann aus einem Versagen der Software eine Gefährdungssituation entstehen?
Die erste Frage zielt nicht auf den Schaden, sondern auf die Situation davor. Gefragt wird, ob ein Versagen der Software überhaupt dazu führen kann, dass jemand einer Gefährdung ausgesetzt wird. Lautet die Antwort nein, ist die Software Sicherheitsklasse A und der Baum endet hier.
Wichtig ist, dass auch indirekte Wege zählen. Eine falsch angezeigte Information ist eine Gefährdungssituation, wenn auf ihrer Basis eine Behandlungsentscheidung fällt. Software muss keine Aktorik ansteuern, um gefährlich zu sein.
- Beispiel der Insulinpumpe: Ein Versagen der Dosisberechnung oder der Antriebsansteuerung führt zu einer Über- oder Unterdosierung von Insulin. Das ist eindeutig eine Gefährdungssituation. Antwort: ja.
- Beispiel der Adipositas-DiGA: Hier scheiden sich die Geister. Ob Sie in Sicherheitsklasse A oder B landen, ist Auslegungssache. Auf den ersten Blick kann ein Bewegungsprogramm niemandem schaden. Denkt man weiter, sind Szenarien konstruierbar: eine Übung, die für einen Patienten mit kardialer Vorerkrankung ungeeignet ist, oder ein Ernährungsplan mit zu geringer Kalorienzufuhr über einen längeren Zeitraum. Wir gehen im Rahmen des Artikels mal auf Nummer sicher. Antwort: ja.
Schritt 2: Externe Risikobeherrschungsmaßnahmen bewerten
Jetzt prüfen Sie, welche Maßnahmen außerhalb des Software-Systems die Gefährdungssituation abfangen. Die Norm nennt dafür in einer Anmerkung zu Abschnitt 4.3 vier Kategorien: Hardware, ein unabhängiges Software-System, Abläufe in der Gesundheitsversorgung und sonstige Mittel.
Typische zulässige Maßnahmen sind:
- Hardware-Begrenzungen: eine elektrische oder mechanische Begrenzung der maximalen Energie- oder Wirkstoffabgabe, die unabhängig von der Firmware (Software) wirkt.
- Mechanische Konstruktion: eine Geometrie, die eine gefährliche Bewegung physisch unmöglich macht, oder ein Anschlag, der einen Verfahrweg begrenzt.
- Ein unabhängiges Software-System: ein separater Überwachungscontroller mit eigener Firmware, der das Hauptsystem abschaltet. Das ist der stärkste Hebel für Embedded-Hersteller und wird oft übersehen, weil viele annehmen, Software könne grundsätzlich nicht als externe Maßnahme zählen.
- Organisatorische Maßnahmen im klinischen Ablauf: Der behandelnde Arzt prüft jede Therapieempfehlung des Systems gegen den erhobenen Befund, bevor er sie umsetzt. Eine Medikationsanpassung wird im Vier-Augen-Prinzip freigegeben. Vor jeder Dosisanpassung ist ein aktueller Laborwert verpflichtend.
Nicht zulässig ist dagegen:
- Jede Maßnahme innerhalb desselben Software-Systems hat keinen Einfluss auf die Klassifizierung. Eine Software-Komponente, die eine andere Komponente überwacht, ist als Risikobeherrschungsmaßnahme grundsätzlich sinnvoll, sie senkt aber die Sicherheitsklasse nicht.
Beispiele:
- Beispiel der Insulinpumpe: Die unabhängige Hardware-Begrenzung der maximalen Abgabemenge wirkt unabhängig von der Firmware. Sie zählt als externe Maßnahme.
- Beispiel der Adipositas-DiGA: Kein Behandler dazwischen, keine Hardware, kein verpflichtender klinischer Ablauf. Es gibt keine anrechenbare externe Maßnahme.
Schritt 3: Bleibt ein unvertretbares Risiko?
Nach Berücksichtigung der externen Maßnahmen wird geprüft, ob das verbleibende Risiko noch unvertretbar ist. Lautet die Antwort nein (das Restrisiko ist vertretbar), ist die Software Sicherheitsklasse A, obwohl im ersten Schritt eine Gefährdungssituation möglich war.
Das ist der zweite Weg zur Klasse A, und er wird in der Praxis regelmäßig mit dem ersten verwechselt. Der Unterschied ist wichtig: Im ersten Fall kann die Software überhaupt nicht zu einer Gefährdung beitragen. Im zweiten Fall kann sie es, aber das Restrisiko ist vertretbar. Beide führen zu Klasse A, verlangen aber völlig unterschiedliche Begründungen.
Der Maßstab für „unvertretbar“ sind Ihre eigenen im Risikomanagementplan festgelegten Akzeptanzkriterien. Nicht Ihr Bauchgefühl und auch nicht der reine Vergleich mit Wettbewerbsprodukten.
- Beispiel der Insulinpumpe: Auch mit der Hardware-Begrenzung bleibt eine relevante Fehldosierung innerhalb des begrenzten Bereichs möglich. Bei Insulin ist schon eine moderate Überdosierung klinisch bedeutsam. Das Restrisiko ist unvertretbar, es geht weiter zu Schritt 4.
- Beispiel der Adipositas-DiGA: Hier wird es interessant. Das Bewegungsprogramm richtet sich an eine Population ohne akute Kontraindikationen, die Übungen bewegen sich im Bereich alltäglicher körperlicher Aktivität, und der Ernährungsplan bleibt in einem Korridor, der auch ohne App durch eine professionelle Ernährungsberatung entstehen könnte. Bei sauber gesetzten Akzeptanzkriterien und einer klar formulierten Zweckbestimmung mit definierten Ausschlusskriterien lässt sich das verbleibende Risiko als vertretbar begründen. Ergebnis: Klasse A. (auch hier scheiden sich die Geister und es existiert Interpretationsspielraum)
Achtung: Dieser Schritt ist der beliebteste Hebel zur Selbsttäuschung. Hier entstehen die meisten Klasse-A-Begründungen, die im Audit nicht halten. Wenn Sie merken, dass Ihre Argumentation an dieser Stelle länger wird als der Rest der Klassifizierung, ist das ein Warnsignal. Die Grenze zwischen A und B bleibt aber umstritten, und das sollte man offen sagen. Bei unserer Adipositas-DiGA ist Klasse A begründbar, aber sie ist nicht die einzige vertretbare Position. Ein anderer Hersteller mit einer anderen Risikoakte und anderen Akzeptanzkriterien käme beim selben Produkt zu Klasse B, und auch das wäre nicht grundsätzlich falsch.
Schritt 4: Welche Schwere der Verletzung ist möglich?
Wer bis hierher gekommen ist, landet bei Klasse B oder C. Jetzt entscheidet allein die Schwere des möglichen Schadens. Eine nicht schwerwiegende Verletzung bedeutet Klasse B. Tod oder eine schwerwiegende Verletzung bedeuten Klasse C.
Maßgeblich ist dabei der schlimmste Fall der bestimmungsgemäßen und der vernünftigerweise vorhersehbaren Verwendung. Nicht der typische Fall, nicht der Durchschnitt, aber auch nicht jedes theoretisch konstruierbare Szenario.
- Beispiel der Insulinpumpe: Eine Insulinüberdosierung kann eine schwere Hypoglykämie auslösen. Wird diese nicht rechtzeitig und ausreichend behandelt, sind Krampfanfall, Bewusstlosigkeit, Koma und Tod mögliche Folgen. Das ist unstrittig eine schwerwiegende Verletzung. Ergebnis: Klasse C.
- Beispiel der Adipositas-DiGA: Dieses Beispiel hat den Baum bereits in Schritt 3 verlassen und ist bei Klasse A gelandet.
Die Insulinpumpe zeigt gut, wo die Grenze des Optimierens liegt. Die Hardware-Begrenzung ist eine sinnvolle und wirksame Maßnahme, aber sie verhindert den kritischen Schaden nicht vollständig. Sie senkt die Klasse deshalb nicht von C auf B.
6. Software aufteilen: unterschiedliche Sicherheitsklassen für unterschiedliche Teile
Die Norm verlangt nicht, dass Ihre gesamte Software in einer einzigen Klasse läuft. Sie unterscheidet drei Ebenen: das Software-System als oberste Ebene, die Software-Items, und die Software-Units als kleinste nicht weiter zerlegbare Ebene. Ein Produkt kann außerdem mehrere Software-Systeme enthalten.
Grundsätzlich erbt ein Software-Item die Klasse des übergeordneten Systems. Sie dürfen ein Item aber niedriger klassifizieren, wenn Sie begründen können, dass es von den höher klassifizierten Teilen getrennt ist. Diese Trennung heißt Segregation. Die Norm formuliert sie im Anhang zwar richtungsneutral, praktisch entscheidend ist aber der Schutz nach oben: Das niedriger klassifizierte Item darf das höher klassifizierte nicht beeinflussen können, weder über Datenfluss noch über Kontrollfluss noch über geteilte Ressourcen wie Speicher, CPU-Zeit oder Register. Bei Klasse C verlangt die Norm in Abschnitt 5.3.5 zusätzlich, die für die Risikobeherrschung nötige Segregation zu benennen und anzugeben, wie ihre Wirksamkeit sichergestellt wird.
Praktisch heißt das: Sie können den Entscheidungsbaum für jedes abgetrennte Software-System und für jedes segregierte Item separat durchlaufen. Bei einem Medizingerät mit Touch-Display kann die Steuerungsfirmware ggf. unter Klasse C laufen, während bestimmte Teile der Bedienoberfläche auf einem separaten Prozessor unter Klasse A entwickelt werden. Der Aufwand für den unkritischen Teil sinkt dann erheblich.
Ob sich das lohnt, ist allerdings keine ausgemachte Sache. Zwei Argumente sprechen häufig dagegen. Erstens bedeuten unterschiedliche Klassen unterschiedliche Entwicklungsprozesse innerhalb desselben Teams, und das ist in der Praxis schwer zu koordinieren. Wer im selben Sprint an einem Klasse-C-Item und einem Klasse-A-Item arbeitet, braucht zwei verschiedene Nachweisketten, zwei Reviewtiefen und zwei Definitionen von „fertig“. Zweitens erzeugt die Aufteilung selbst Dokumentationsaufwand: Sie müssen Systemgrenzen beschreiben, Segregation begründen und deren Wirksamkeit belegen. Genau das sind dann die Stellen, an denen ein Auditor ansetzt.
Unsere Empfehlung: Teilen Sie auf, wenn ein großer, klar abgrenzbarer und unkritischer Anteil existiert, typischerweise Bedienoberfläche, Reporting, Synchronisation oder Analytik, und wenn diese Grenze ohnehin schon in der Architektur liegt. Lassen Sie es sein, wenn Sie die Grenze erst konstruieren müssten. In vielen Projekten ist es einfacher und am Ende günstiger, alles unter einer Klasse laufen zu lassen, als drei angreifbare Begründungen zu schreiben.
Aufteilung am Beispiel eines Dialysegeräts: Sicherheitskern, Behandlungsablauf und nicht-medizinisches Modul
7. Die Edition 2 der IEC 62304
An der IEC 62304 wird weiterhin gearbeitet. Eine zweite Edition ist in Vorbereitung, und sie wird die Systematik der Sicherheitsklassen deutlich verändern. Gültig ist und bleibt aber erstmal die IEC 62304:2006 mit dem Amendment 1 von 2015. Daran ändert sich in absehbarer Zeit nichts.
Zeitplan: Die zweite Edition steckt seit über zehn Jahren im Normungsprozess, und der Weg dorthin verlief alles andere als geradlinig. Derzeit läuft die Kommentierung des zweiten Entwurfs, danach stehen noch zwei Abstimmungsstufen aus. Die IEC prognostiziert Oktober 2028, realistisch ist eher 2029. Entscheidend ist aber der unplanbare Schritt danach: die Zitierung im Amtsblatt der EU, denn erst sie erzeugt die Konformitätsvermutung. Zur Einordnung: Die MDR gilt seit Mai 2021, und die aktuelle Edition der IEC 62304 ist bis heute nicht gelistet. Realistisch sprechen wir über die frühen 2030er Jahre.
Änderungen der neuen Edition 2: (Alles Folgende ist Entwurfsstand und kann sich noch ändern.)
- Die drei Sicherheitsklassen werden durch zwei Software Process Rigor Level ersetzt. Level I entspricht der heutigen Klasse A, Level II fasst B und C zusammen.
- Software, die eine Risikobeherrschungsmaßnahme umsetzt, fällt immer in Level II. Maßnahmen außerhalb der Software bleiben anrechenbar, brauchen aber einen Wirksamkeitsnachweis.
- Software-Architekturdesign soll für beide Level gelten.
- Der Anwendungsbereich weitet sich von Medizinproduktesoftware auf Health Software allgemein aus.
Was Edition 2 entgegen vielen Beiträgen nicht bringt: Cybersecurity wird nicht in die Norm geholt. Die Designspezifikation des Projekts hält ausdrücklich fest, dass Security außerhalb der IEC 62304 geregelt wird. Es wird vor allem auf die IEC 81001-5-1 verwiesen. Auch KI wird nach aktuellem Entwurfsstand nur über einen informativen Anhang adressiert, also ohne verbindliche Anforderungen. Für die Anforderungen an KI lesen Sie unsere Artikel zu MDR-Anforderungen an KI und zum AI Act.
Was Sie heute tun sollten: Sie brauchen nichts anders machen. Arbeiten Sie mit der aktuellen Fassung der IEC 62304 weiter. Es wird noch eine Weile dauern, bis die neue Version zum neuen Standard in der Praxis wird.
8. Fazit
Die Bestimmung der Software-Sicherheitsklasse folgt immer demselben Weg: Kann ein Versagen der Software zu einer Gefährdungssituation führen, welche Maßnahmen außerhalb der Software fangen das ab, bleibt danach ein unvertretbares Risiko, und wie schwer wäre der mögliche Schaden? Vier Prüfschritte, deren Ergebnisse Sie aus Ihrem Risikomanagement ziehen.
Die Grenze zwischen Klasse B und Klasse C ist etwas schneller geklärt, weil die Schwere des Schadens klarer auf der Hand liegt. Deutlich umstrittener ist die Grenze zwischen Klasse A und Klasse B, und dazu existieren sehr unterschiedliche Auffassungen.
Die zweite Edition wird die Systematik verändern und aus drei Klassen zwei Rigor Level machen. Bis das für Sie verbindlich wird, vergehen aber noch Jahre. Bis dahin gilt der Entscheidungsbaum, den Sie in diesem Artikel durchlaufen haben.
Sie planen ein Software-Medizinprodukt?
Sie planen die Umsetzung einer Medical Software, einer DiGA oder eines Embedded-Software-Projekts? Kontaktieren Sie uns gerne. Wir entwickeln regulierte Medical Software (Health Apps, DiGA, Web-Plattformen etc.) und Embedded Software auf Auftragsbasis.
