IEC 62304 definiert Sicherheitsklassen, um Herstellern medizinischer Geräte zu ermöglichen, ihre Softwaredokumentationsbemühungen an das Ausmaß des Schadens anzupassen, der durch einen Softwarefehler verursacht werden kann.
Dieser Fachartikel hilft dabei, die Sicherheitsklassen zu ermitteln und ggf. zu reduzieren, so den Aufwand zu minimieren und dennoch gemäß IEC 62304 zu dokumentieren.
- 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 Softwarekomponente muss klassifiziert werden – die höchste Klasse einer Komponente bestimmt die Klasse des gesamten Softwaresystems.
- Durch softwareexterne Risikokontrollmaßnahmen können Sicherheitsklassen reduziert werden, was den Dokumentationsaufwand reduziert.
- 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 (Entwurf) sieht eine Reduzierung auf zwei statt drei Sicherheitsklassen vor.
1. Bedeutung der Sicherheitsklassen nach IEC 62304
IEC 62304 ist der harmonisierte Standard für die Entwicklung von Software für medizinische Geräte. Sie verlangt von den Herstellern, diese Software bzw. deren Softwarekomponenten je nach Risiko bzw. Schwere eines möglichen Schadens in die drei Sicherheitsklassen A, B und C einzustufen. Klasse C steht für die höchsten Risiken, Klasse A für die niedrigsten.
Diese Sicherheitsklassen bestimmen den Dokumentationsaufwand und damit auch den Entwicklungs- und Testaufwand für diese Software.
Sofern der Hersteller diese Sicherheitseinstufung nicht angibt, fallen die Software und alle Softwarekomponenten in die höchste Sicherheitsklasse C.
2. Sicherheitsklassen: Definitionen
Die vereinfachte Definition von Sicherheitsklassen lautet:
- Klasse A: Keine mögliche Verletzung
- Klasse B: Keine ernsthafte Verletzung möglich
- Klasse C: Tod oder schwere Verletzung möglich (z. B. Lüftungssteuerung)
Ein genauerer Blick auf die Ausgabe 2015 der IEC 62304 zeigt ein differenzierteres Bild:
- Sicherheitsklasse A: Das Softwaresystem kann nicht zu einer gefährlichen Situation beitragen oder das Risiko ist akzeptabel, spätestens wenn geeignete Risikokontrollmaßnahmen ergriffen wurden. Diese Risikokontrollmaßnahmen müssen jedoch außerhalb des Softwaresystems liegen.
- Sicherheitsklasse B: Das Softwaresystem kann auch nach Risikokontrollmaßnahmen zu einer gefährlichen Situation führen, der mögliche daraus resultierende Schaden ist jedoch nicht schwerwiegend.
- Sicherheitsklasse C: Auch nach Risikokontrollmaßnahmen kann das Softwaresystem zu einer gefährlichen Situation führen, die möglicherweise zu schwerwiegenden oder sogar tödlichen Schäden führt.
Dies lässt sich wie folgt zusammenfassen:
| Klasse A | Klasse B | Klasse C | |
| Daraus resultierende Risiken | Akzeptabel | Inakzeptabel | Inakzeptabel |
| Möglicher Schaden nach Risikokontrollmaßnahmen | Kein Schaden | Keine ernsthaften Schäden | Schwerer Schaden oder Tod |
Die Definition von Sicherheitsklassen in der IEC 62304 ist problematisch, da Produkte mit unzumutbaren Risiken grundsätzlich nicht auf den Markt gebracht werden dürfen. Es besteht daher die Hoffnung, dass diese Definition in der zweiten Ausgabe der IEC 62304 überarbeitet wird.
3. Einfluss der Sicherheitsklasse auf den Software-Lebenszyklus
Die Sicherheitsklasse bestimmt spezifische Anforderungen für jeden Schritt im Softwareentwicklungsprozess.
| 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 lediglich die Softwareanforderungen (5.2) und das Software-Release (5.8) dokumentieren, für Klasse B kommen die Softwarearchitektur (5.3) und die Softwareverifizierung (5.5 bis 5.7) hinzu, für Sicherheitsklasse C auch das detaillierte Design (5.4).
Seit Novelle I im Jahr 2015 sind Systemprüfungen auch für die Sicherheitsklasse A vorgeschrieben.
Das Johner-Institut hält viele Diskussionen zu den Klassen B oder C für wenig zielführend. Der Verzicht auf detailliertes Design oder Unit-Tests wäre nicht mit professioneller Softwareentwicklung vereinbar. Und sobald man auf die FDA blickt, wird diese Diskussion völlig absurd. Unabhängig vom Grad der Besorgnis müssen alle Unterlagen dort erstellt, nur nicht eingereicht werden.
Es ist sogar fraglich, ob eine Softwaredokumentation ohne Softwarearchitektur den Anforderungen der MDR entspricht, die unter anderem folgende Dokumentation fordert:
- Teile/Komponenten
- Bei Bedarf visuelle Darstellungen (z. B. Diagramme, fotografische Abbildungen und Zeichnungen), in denen die wichtigsten Teile/Komponenten klar gekennzeichnet sind
- Beschreibung des Softwaredesigns
4. Sicherheitsklasse reduzieren
Externe Risikokontrollmaßnahmen können den Entwicklungsaufwand deutlich reduzieren. „Extern“ bedeutet nicht unbedingt außerhalb des Produkts, sondern außerhalb der Software.
Die Maßnahmen werden in der Regel in Hardware umgesetzt. Beispiele:
- Die mechanische Geometrie verhindert, dass Software dazu führt, dass ein Aktuator einen Finger blockiert.
- Selbst im Fehlerfall kann eine Software nicht dazu führen, dass ein Motor schneller dreht, als es die Motorgrenzen zulassen.
- Ein zweites unabhängiges Softwaresystem (auf eigener Hardware) prüft die Ergebnisse des ersten Softwaresystems und greift im Fehlerfall ein.
- Ein Benutzer überprüft die Werte, bevor das medizinische Gerät oder andere Personen weitere Schritte unternehmen.
Hersteller müssen alle risikominimierenden Maßnahmen auf Umsetzung und Wirksamkeit prüfen. Dies gilt auch für Maßnahmen, für die Menschen verantwortlich sind. Zum Nachweis sind in der Regel Usability-Tests notwendig.
Eine Softwarekomponente, die eine andere Softwarekomponente innerhalb desselben Softwaresystems überwacht, ist grundsätzlich als risikominimierende Maßnahme geeignet, nicht jedoch zur Reduzierung der Sicherheitsklasse.
5. Sicherheitsklassen vs. Dokumentationsebenen
Die FDA verfolgt mit den Documentation Levels (ehemals Levels of Concern) ähnliche Ziele wie die IEC 62304 mit den Sicherheitsklassen.
Den Ansätzen der FDA und der IEC 62304 ist gemeinsam, dass beide mehr Dokumentation erfordern, wenn die Risiken höher sind. Eine direkte Zuordnung von Dokumentationsstufen und Sicherheitsklassen ist jedoch nicht möglich.
Die Dokumentationsstufen beziehen sich auf die einzureichende Dokumentation, nicht auf die zu erstellende Dokumentation. Das Guidance-Dokument der FDA zur Softwarevalidierung (gemeint ist die vollständige Softwareentwicklung) unterscheidet nicht zwischen den Dokumentationsstufen.
Darüber hinaus erlaubt die FDA die Festlegung der Dokumentationsstufen pro „Funktion“ (dies ist ein Aspekt des Verwendungszwecks), während die IEC 62304 eine Definition der Sicherheitsklassen pro Softwaresystem oder Softwarekomponente erfordert.
6. Sicherheitsklassen und Segregation
Durch eine geschickte Aufteilung der Software können Hersteller den Dokumentationsaufwand reduzieren. Dazu müssen sie begründen, warum einzelne Softwarekomponenten eine unterschiedliche Software-Sicherheitsklasse haben. Eine solche Begründung muss auf einer ausreichenden Trennung der Komponenten beruhen.
Begründungen sollten aus der Software- oder Hardware-Architektur abgeleitet werden und auf einer schwachen (oder fehlenden) Kopplung der jeweiligen Komponenten basieren.
Eine Softwarekomponente A, die keine Methoden für eine Softwarekomponente B aufruft, ist schwächer gekoppelt als eine Softwarekomponente, die diese Methoden für B aufruft, von B erbt oder Ausnahmen von B abfängt.
Besonders schlagkräftig wäre das Argument, dass die beiden Softwarekomponenten auf unterschiedlicher Hardware laufen. Allerdings ließe sich dann auch argumentieren, dass es zwei Softwaresysteme gibt, die grundsätzlich unabhängig voneinander klassifiziert werden können.
Abschluss: Softwarekomponenten (Softwareelemente) können bei nachgewiesener Unabhängigkeit unterschiedliche Sicherheitsklassen haben – allerdings bestimmt die höchste Klasse einer Komponente die Klasse des gesamten Systems.
7. Praktische Umsetzung
Ein strukturiertes Vorgehen spart Zeit und vermeidet Prüfungsfeststellungen.
Für dieses Verfahren werden folgende Schritte empfohlen:
- Leiten Sie aus dem Risikomanagement (top-down!) ab, welche Bedrohungen vom Softwaresystem ausgehen
- Leiten Sie ggf. risikominimierende Maßnahmen außerhalb des Softwaresystems aus dem Risikomanagement ab
- Bestimmen Sie dann die Softwaresicherheitsklasse des Softwaresystems
- Entwerfen Sie eine Softwarearchitektur, um Softwarekomponenten zu identifizieren und ihre Schnittstellen zu spezifizieren
- Bestimmen Sie abhängig davon die Sicherheitsklassen für die Softwarekomponenten
- Erstellen Sie die Dokumentation abhängig von diesen Sicherheitsklassen
- Überprüfen Sie während der Designprüfung die Umsetzung der Schritte 1 bis 6
8. Zusammenfassung und Schlussfolgerung
Der risikobasierte Ansatz der IEC 62304 erscheint auf den ersten Blick attraktiv, da er eine Anpassung des Dokumentationsaufwands an das Risiko ermöglicht. Damit sind jedoch mehrere Risiken verbunden:
- Hersteller erfüllen die regulatorischen Anforderungen anderer Märkte nicht mehr.
- Im schlimmsten Fall erfüllen sie nicht einmal die Anforderungen der MDR und IVDR.
- Sie erhöhen das Audit-Risiko, da es für Entwickler schwierig ist, innerhalb eines Softwaresystems nach unterschiedlichen Spezifikationen zu arbeiten.
- Sie erhöhen die Wahrscheinlichkeit, dass Softwarefehler unentdeckt bleiben.
- Darüber hinaus kosten Diskussionen über die Sicherheitsklasse manchmal mehr Zeit, als eine niedrigere Klasse sparen könnte.
Wenn Hersteller diese Risiken in Kauf nehmen wollen, sollten sie die oben beschriebenen sieben Schritte durchlaufen. Andernfalls können Sie die Schritte drei und fünf überspringen.
Das Johner Institut empfiehlt daher eine professionelle Entwicklung der Software, die automatisch zur Einhaltung der Anforderungen der Sicherheitsklasse C führt.
IEC 62304 sollte nicht als Best-Practice-Standard oder gar als Stand der Technik missverstanden werden. Es definiert die untere Grenze der Unprofessionalität.
Möchten Sie mehr erfahren? Dann besuchen Sie das Kompaktseminar IEC 62304.
Sie möchten Ihre Softwareentwicklung effizienter gestalten und gleichzeitig (nicht nur) Konformität mit der IEC 62304 erreichen? Dann kontaktieren Sie unsere Software-Experten.
Geschichte ändern
- 10.10.2025: Artikel komplett neu geschrieben
- 14.12.2017: Erste Version des Artikels veröffentlicht
Ähnliche Beiträge
Automotive
Game Center
Game News
Review Film
Berita Terkini
Berita Terkini
Berita Terkini
review anime
