Die IEC 62304 definiert Sicherheitsklassen, damit Medizinproduktehersteller den Aufwand für die Software-Dokumentation an den Grad von Schäden anpassen können, die durch einen Softwarefehler verursacht werden können.
Dieser Expert Article hilft, die Sicherheitsklassen zu bestimmen, gegebenenfalls zu reduzieren, damit den Aufwand zu minimieren und dennoch IEC-62304-konform zu dokumentieren.
- Die IEC 62304 definiert drei Sicherheitsklassen (A, B, C) basierend auf dem potenziellen Risiko für Patienten, wobei Klasse C die höchsten Anforderungen stellt
- Jede Software-Komponente muss klassifiziert werden – die höchste Klasse einer Komponente bestimmt die Klasse des gesamten Software-Systems.
- Durch softwareexterne Risikokontrollmaßnahmen können Sicherheitsklassen reduziert werden, was den Dokumentationsaufwand verringert.
- Die FDA Documentation Levels entsprechen nicht direkt den Sicherheitsklassen der IEC 62304, haben aber ähnliche Auswirkungen auf den Umfang der Dokumentation.
- Die neue IEC 62304:2026 (Draft) plant eine Reduzierung auf zwei statt drei Sicherheitsklassen.
1. Bedeutung der Sicherheitsklassen nach IEC 62304
Die IEC 62304 ist die harmonisierte Norm zur Entwicklung von Medizinprodukte-Software. Sie verlangt von den Herstellern, diese Software bzw. deren Software-Komponenten abhängig vom Risiko bzw. von den Schweregraden von möglichen Schäden in die drei Sicherheitsklassen A, B und C einzuteilen. Die Klasse C ist für die höchsten Risiken zu vergeben, die Klasse A für die niedrigsten.
Diese Sicherheitsklassen bestimmen den Dokumentationsaufwand und damit auch den Entwicklungs- bzw. Testaufwand für diese Software.
Falls der Hersteller diese Sicherheitsklassifizierung nicht vornimmt, fallen die Software und alle Software-Komponenten in die höchste Sicherheitsklasse C.
2. Sicherheitsklassen: Definitionen
Die vereinfachte Definition der Sicherheitsklassen ist:
- Klasse A: Keine mögliche Verletzung
- Klasse B: Keine schwere Verletzung möglich
- Klasse C: Tod oder schwere Verletzung möglich (z. B. Beatmungssteuerung)
Ein präziserer Blick in die Ausgabe 2015 der IEC 62304 zeigt ein differenzierteres Bild:
- Sicherheitsklasse A: Das Software-System kann nicht zu einer Gefährdungssituation beitragen oder das Risiko ist akzeptabel, spätestens wenn man entsprechende Risikokontrollmaßnahmen ergriffen hat. Diese Risikokontrollmaßnahmen müssen aber außerhalb des Software-Systems liegen.
- Sicherheitsklasse B: Das Software-System kann auch nach Risikokontrollmaßnahmen zu einer Gefährdungssituation führen, aber die möglichen resultierenden Schäden sind nicht schwer.
- Sicherheitsklasse C: Das Software-System kann auch nach Risikokontrollmaßnahmen zu einer Gefährdungssituation führen, wobei die möglichen resultierenden Schäden schwer sind oder gar zum Tod führen können.
Das lässt sich wie folgt zusammenfassen:
| Klasse A | Klasse B | Klasse C | |
| Resultierende Risiken | Akzeptabel | Inakzeptabel | Inakzeptabel |
| Mögliche Schäden nach Risikokontrollmaßnahmen | Kein Schaden | Kein schwerer Schaden | Schwerer Schaden oder Tod |
Die Definition der Sicherheitsklassen in der IEC 62304 ist problematisch, da Produkte mit inakzeptablen Risiken generell nicht in den Verkehr gebracht werden dürfen. Daher ist auf eine Überarbeitung dieser Definition in den zweiten Ausgabe der IEC 62304 zu hoffen.
3. Auswirkungen der Sicherheitsklasse auf den Software-Lebenszyklus
Die Sicherheitsklasse bestimmt konkrete Anforderungen an jeden Schritt im Software-Entwicklungsprozess.
| 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 |
Für Software der Sicherheitsklasse A müssen Hersteller nur die Software-Anforderungen (5.2) und die Software-Freigabe (5.8) dokumentieren, bei Klasse B kommen die Software-Architektur (5.3) und die Software-Verifikation (5.5 bis 5.7) hinzu, und bei Sicherheitsklasse C auch das detaillierte Design (5.4).
Seit dem Amendment I im Jahr 2015 sind die Systemtests auch bei Sicherheitsklasse A vorgeschrieben.
Das Johner Institut hält viele Diskussionen hinsichtlich Klasse B oder C für wenig zielführend. Denn auf ein detailliertes Design oder Unit-Tests zu verzichten, entspräche nicht einer professionellen Software-Entwicklung. Und sobald man Richtung FDA schaut, wird diese Diskussion sogar völlig absurd. Denn dort müssen unabhängig vom Level of Concern alle Dokumente erstellt, nur nicht eingereicht werden.
Es ist sogar fraglich, ob eine Software-Dokumentation ohne eine Software-Architektur den Anforderungen der MDR entspricht, die u. a. folgende Dokumentationen fordert:
- Bestandteile/Komponenten
- Ggf. bildliche Darstellungen (z. B. Diagramme, fotografische Bilder und Zeichnungen), in denen die wichtigsten Bestandteile/Komponenten eindeutig gekennzeichnet sind
- Beschreibung des Softwaredesigns
4. Sicherheitsklasse reduzieren
Durch externe Risikokontrollmaßnahmen lässt sich der Entwicklungsaufwand signifikant reduzieren. „Extern“ bedeutet dabei nicht notwendigerweise außerhalb des Produkts, aber außerhalb der Software.
Üblicherweise sind die Maßnahmen in Hardware implementiert. Beispiele:
- Die mechanische Geometrie unterbindet, dass eine Software einen Aktor dazu bringt, einen Finger zu verklemmen.
- Ein Motor kann durch eine Software auch im Fehlerfall nicht dazu gebracht werden, schneller zu drehen, als das die Motorgrenzen erlauben.
- Ein zweites unabhängiges Software-System (auf eigener Hardware) überprüft die Ergebnisse des ersten Software-Systems und greift im Fehlerfall ein.
- Ein Anwender überprüft die Werte, bevor das Medizinprodukt oder Menschen weitere Schritte unternehmen.
Hersteller müssen alle risikominimierenden Maßnahmen auf Implementierung und Wirksamkeit überprüfen. Das gilt auch für Maßnahmen, für die Menschen verantwortlich sind. Dort sind in der Regel Usablity Tests zum Nachweis notwendig.
Eine Software-Komponente, die innerhalb des gleichen Software-Systems eine andere Software-Komponente überwacht, eignet sich zwar prinzipiell als risikominimierende Maßnahme, aber nicht zur Reduktion der Sicherheitsklasse.
5. Sicherheitsklassen vs. Documentation Levels
Die FDA verfolgt mit den Documentation Levels (früher Levels of Concern) ähnliche Ziele wie die IEC 62304 mit den Sicherheitsklassen.
Gemeinsam ist den Ansätzen von FDA und IEC 62304, dass beide bei höheren Risiken mehr Dokumentation einfordern. Eine direkte Zuordnung von Documentation Levels und Sicherheitsklassen ist allerdings nicht möglich.
Die Documentation Levels beziehen sich auf die einzureichende Dokumentation, nicht auf die zu erstellende Dokumentation. Das Guidance-Dokument der FDA zur Software Validation (gemeint ist die komplette Software-Entwicklung) unterscheidet die Documentation Levels nicht.
Zudem erlaubt die FDA, die Documentation Levels pro „function“ (das ist ein Aspekt der Zweckbestimmung) zu bestimmen, wohingegen die IEC 62304 eine Definition der Sicherheitsklassen pro Software-System bzw. Software-Komponente fordert.
Beachten Sie den Fachartikel zu den FDA Levels of Concern und Documentation Levels.
6. Sicherheitsklassen und Segregation
Durch geschickte Aufteilung der Software können Hersteller den Dokumentationsaufwand reduzieren. Dazu müssen sie begründen, weshalb einzelne Software-Komponenten eine andere Software-Sicherheitsklasse haben. Eine solche Begründung muss sich auf eine ausreichende Segregation der Komponenten stützen.
Begründungen sollten sich aus der Software- bzw. Hardware-Architektur ableiten lassen und auf einer schwachen (oder gar keiner) Kopplung der jeweiligen Komponenten beruhen.
Eine Software-Komponente A, die keine Methoden auf einer Software-Komponente B aufruft, ist schwächer gekoppelt als eine Software-Komponente, die diese Methoden auf B aufruft, von B erbt oder „Exceptions“ von B fängt.
Besonders schlagkräftig wäre die Argumentation, dass die beiden Software-Komponenten auf unterschiedlicher Hardware laufen. Allerdings ließe sich dann auch argumentieren, dass es zwei Software-Systeme sind, die generell unabhängig klassifiziert werden können.
Fazit: Software-Komponenten (Software Items) können unterschiedliche Sicherheitsklassen haben, wenn ihre Unabhängigkeit nachgewiesen wird – die höchste Klasse einer Komponente bestimmt jedoch die Klasse des Gesamtsystems.
7. Praktische Umsetzung
Ein strukturiertes Vorgehen spart Zeit und vermeidet Audit-Findings.
Für dieses Vorgehen empfehlen sich die folgenden Schritte:
- Aus dem Risikomanagement ableiten (Top-Down!), welche Gefährdungen vom Software-System ausgehen
- Aus dem Risikomanagement bei Bedarf risikominimierende Maßnahmen außerhalb des Software-Systems ableiten
- Anschließend die Software-Sicherheitsklasse des Software-Systems bestimmen
- Software-Architektur entwerfen, damit die Software-Komponenten identifizieren und deren Schnittstellen spezifizieren
- Davon abhängig die Sicherheitsklassen für die Software-Komponenten bestimmen
- Die Dokumentation abhängig von diesen Sicherheitsklassen erstellen
- Beim Design-Review die Umsetzung der Schritte 1 bis 6 prüfen
8. Zusammenfassung & Fazit
Der risikobasierte Ansatz der IEC 62304 erscheint vordergründig attraktiv, weil er erlaubt, den Dokumentationsaufwand an das Risiko anzupassen. Doch damit sind mehrere Risiken verbunden:
- Die Hersteller erfüllen nicht mehr die regulatorischen Anforderungen anderer Märkte.
- Schlimmstenfalls erfüllen sie nicht einmal die Anforderungen von MDR und IVDR.
- Sie erhöhen die Auditrisiken, weil Entwicklerinnen und Entwickler sich schwertun, nach unterschiedlichen Vorgaben innerhalb eines Software-Systems zu arbeiten.
- Sie erhöhen die Wahrscheinlichkeit, dass Software-Fehler unentdeckt bleiben.
- Zudem kosten die Diskussionen über die Sicherheitsklasse manchmal mehr Zeit, als sie durch eine niedrigere Klasse einsparen könnten.
Möchten die Hersteller diese Risiken in Kauf nehmen, sollten sie die oben skizzierten sieben Schritte durchlaufen. Andernfalls können sie sich die Schritte drei und fünf sparen.
Daher empfiehlt das Johner Institut, die Software professionell zu entwickeln, was automatisch zu einer Konformität mit den Anforderungen an die Sicherheitsklasse C führt.
Die IEC 62304 sollte nicht als Best-Practice-Norm oder gar als Stand der Technik missverstanden werden. Sie definiert die Untergrenze zur Nicht-Professionalität.
Wollen Sie mehr erfahren? Dann besuchen Sie das Kompaktseminar IEC 62304.
Wollen Sie Ihre Software-Entwicklung effizienter gestalten und gleichzeitig Konformität (nicht nur) mit der IEC 62304 erreichen? Dann melden Sie sich bei unseren Software-Expertinnen und -Experten.
Änderungshistorie
- 2025-10-10: Artikel komplett neu verfasst
- 2017-12-14: Erste Version des Artikels veröffentlicht
Hallo Herr Johner
die Diskussion zur Sicherheitsklassifizierung kenne ich auch.
Aus diesem Grund werden wir nur noch Klasse C Software haben und schauen das die notwendigen Aktivitäten
effizient gestaltet sind.
Grüße
Heiko Schmidt
Hallo Herr Prof. Johner,
mich interessiert bei dieser Diskussion vor allem ein Punkt:
Was kann eine externe Maßnahme sein, die im folgenden Zitat unter „other means“ fällt?
„External RISK CONTROL measures can be hardware, an independent SOFTWARE SYSTEM, health care procedures, or other means to minimize that software can contribute to a HAZARDOUS SITUATION.“
Kann das auch der deskriptive Hinweis in der Gebrauchsanweisung sein? Gibt es dazu möglicherweise schon MEDDEV-Dokumente?
Viele Grüße,
Thomas Hertwig
Ihr Fragen nach den Benutzern als Maßnahme würde ich vorsichtig bejahen. Bei der Gebrauchsanweisung werden Sie in Diskussionen mit dem Auditor kommen, der auf den Anhang Z* der ISO 14971 verweisen wird. Der hat zwar mit der IEC 62304 nichts zu tun, aber ich ahne, wie manche Auditoren-Kollegen argumentieren werden.
Mein Tipp: Lassen Sie es.
MEDDEV Dokumente sind mir nicht bekannt. In der Geschwindigkeit, in der die erstellt bzw. aktualisiert werden, befinden Sie sich wahrscheinlich im verdienten Ruhestand ;-).