Einstieg in IEC 62304: Ein praktischer Leitfaden für Software-Teams

IEC 62304:2006+AMD1:2015 (Medizingeräte-Software -- Software-Lebenszyklusprozesse) ist der international anerkannte Standard für die Entwicklung und Wartung von Software, die in Medizinprodukten verwendet wird oder selbst ein Medizinprodukt darstellt. Ob Sie Firmware für ein implantierbares Gerät, eine diagnostische Bildgebungsanwendung oder eine eigenständige Software als Medizinprodukt (Software as a Medical Device, SaMD) entwickeln -- IEC 62304 bildet das Rahmenwerk, dessen Einhaltung Regulierungsbehörden und Benannte Stellen erwarten. Für Software-Teams mit einem allgemeinen Technologiehintergrund kann der Standard zunächst bürokratisch erscheinen, doch das Verständnis seiner Zielsetzung und Struktur verwandelt ihn von einer Compliance-Last in eine praktische Ingenieurdisziplin.

Im Kern ist IEC 62304 ein Prozessstandard, kein Produktstandard. Er schreibt nicht vor, was Ihre Software tun oder wie sie funktionieren muss. Stattdessen spezifiziert er die Prozesse, die Sie während der Softwareentwicklung, Wartung, des Risikomanagements, des Konfigurationsmanagements und der Problemlösung einhalten müssen. Der Standard ist um einen Software-Entwicklungslebenszyklus strukturiert, der Planung, Anforderungsanalyse, Architekturentwurf, Softwaredetailentwurf, Implementierung, Integration und Integrationstests, Systemtests sowie Freigabe umfasst. Jede Phase hat definierte Aktivitäten und Ergebnisse, doch der Standard ist bewusst lebenszyklus-modell-agnostisch. Sie können IEC 62304 mit einem Wasserfall-, V-Modell-, agilen oder hybriden Ansatz umsetzen, sofern Sie nachweisen können, dass die geforderten Aktivitäten und die Dokumentation abgedeckt sind.

Das wichtigste Einzelkonzept in IEC 62304 ist die Software-Sicherheitsklassifizierung. Der Standard definiert drei Sicherheitsklassen: Klasse A (keine Verletzung oder Gesundheitsschädigung möglich), Klasse B (nicht schwerwiegende Verletzung möglich) und Klasse C (Tod oder schwerwiegende Verletzung möglich). Die Sicherheitsklassifizierung gilt für Softwaresysteme und Softwareeinheiten und bestimmt direkt den Umfang der Dokumentations- und Prozessanforderungen. Software der Klasse A erfordert die geringste Dokumentation, mit Anforderungen an die Softwareentwicklungsplanung, Anforderungsanalyse und Tests, jedoch ohne verpflichtende detaillierte Architektur- oder Unit-Level-Dokumentation. Klasse B fügt Anforderungen an die Dokumentation der Softwarearchitektur und die Verifizierung der Softwarearchitektur hinzu. Klasse C wendet den vollständigen Anforderungskatalog an, einschliesslich detaillierter Entwurfsdokumentation und Unit-Level-Tests. Die korrekte Klassifizierung ist daher entscheidend: Eine Überklassifizierung verschwendet Ressourcen, während eine Unterklassifizierung Sie regulatorischen Risiken aussetzt.

Die Bestimmung der korrekten Sicherheitsklasse erfordert einen risikobasierten Ansatz, der den Beitrag der Software zu Gefährdungssituationen berücksichtigt. Diese Analyse muss in Verbindung mit dem übergeordneten Risikomanagementprozess des Geräts gemäss ISO 14971 durchgeführt werden. Ein wesentliches Prinzip ist, dass Hardware-Risikokontrollen die Software-Sicherheitsklassifizierung reduzieren können. Wenn beispielsweise ein Softwarefehler theoretisch eine schwere Verletzung verursachen könnte, aber ein unabhängiger Hardware-Sicherheitsmechanismus das Auftreten der Gefährdungssituation verhindert, kann die Softwareeinheit als Klasse B statt als Klasse C eingestuft werden. Dieses Zusammenspiel zwischen Softwareklassifizierung und systemweitem Risikomanagement wird häufig unzureichend verstanden, was entweder zu unnötiger Überklassifizierung oder zu unzureichend begründeten Klassifizierungsreduktionen führt.

Die Softwareentwicklungsplanung ist das Fundament, auf dem die IEC-62304-Konformität aufgebaut wird. Der Softwareentwicklungsplan muss die Prozesse, Werkzeuge, Methoden und Standards adressieren, die während des gesamten Lebenszyklus verwendet werden. Er muss die Ergebnisse jeder Phase, die Kriterien für den Übergang zwischen den Phasen sowie die Verfahren für Konfigurationsmanagement und Änderungsmanagement definieren. Für Teams, die agile Methoden einsetzen, sollte der Entwicklungsplan beschreiben, wie die iterative Entwicklung auf die IEC-62304-Aktivitäten abgebildet wird. Es geht dabei nicht um den Verzicht auf Agilität, sondern um die explizite Darstellung dieser Zuordnung. Viele erfolgreiche Medizinproduktesoftware-Teams arbeiten mit zweiwöchigen Sprints und halten dabei die vollständige IEC-62304-Konformität ein, indem sie Dokumentationsaktivitäten in ihre Sprint-Workflows integrieren.

Das Anforderungsmanagement gemäss IEC 62304 verlangt Rückverfolgbarkeit von den Softwareanforderungen über die Architektur und den Detailentwurf bis hin zu den Testfällen. Jede Softwareanforderung sollte auf eine Systemanforderung und letztlich auf die Risikoanalyse zurückverfolgbar sein. Diese bidirektionale Rückverfolgbarkeitsmatrix ist eines der am intensivsten geprüften Artefakte bei Audits durch Benannte Stellen und bei FDA-Software-Reviews. Häufige Fallstricke sind Anforderungen, die zu vage sind, um testbar zu sein, fehlende Rückverfolgbarkeitsverknüpfungen sowie Anforderungen, die sicherheitsrelevante Funktionalitäten nicht angemessen adressieren. Wir empfehlen, Ihre Werkzeuge für das Anforderungsmanagement und die Rückverfolgbarkeitskonventionen frühzeitig einzurichten, da die nachträgliche Herstellung von Rückverfolgbarkeit in einer bestehenden Codebasis erheblich aufwendiger ist als deren Einbau von Anfang an.

Der Standard verlangt Verifizierung auf mehreren Ebenen: Unit-Tests, Integrationstests und Systemtests. Für Software der Klasse C sind Unit-Level-Tests explizit vorgeschrieben, und die Tests müssen nachweisen, dass die Softwareeinheiten ihre detaillierten Entwurfsspezifikationen erfüllen. Für Software der Klasse B sind Integrationstests gegen die Softwarearchitektur erforderlich. Alle Klassen erfordern Systemtests gegen die Softwareanforderungen. Ein häufiger Fehler ist die Gleichsetzung von Testen mit Verifizierung. IEC 62304 stellt klar, dass Softwareverifizierung nicht nur Tests, sondern auch Code-Reviews, statische Analyse und andere dem Risikoniveau angemessene Techniken umfasst. Viele Organisationen stellen fest, dass eine Kombination aus automatisierten Unit-Tests, statischen Analysewerkzeugen, Peer-Code-Reviews und formalen Systemtests eine robuste Abdeckung bietet und gleichzeitig praktikabel in der Wartung bleibt.

Konfigurationsmanagement und Problemlösung sind unterstützende Prozesse, die den gesamten Lebenszyklus untermauern. Das Konfigurationsmanagement muss sicherstellen, dass Softwareeinheiten, ihre Versionen und ihre Beziehungen identifiziert und kontrolliert werden. Dies erstreckt sich auf SOUP (Software of Unknown Provenance -- Software unbekannter Herkunft), die alle Drittanbieter-Bibliotheken, Open-Source-Komponenten und Betriebssysteme umfasst, die im Gerät verwendet werden. Für jedes SOUP-Element müssen Sie den Titel, den Hersteller, die Version und alle bekannten Anomalien dokumentieren, die die Sicherheit oder Leistung Ihres Geräts beeinträchtigen könnten. Da moderne Software auf Dutzende oder sogar Hunderte von Open-Source-Abhängigkeiten angewiesen ist, erfordert das SOUP-Management systematische Werkzeuge und eine laufende Überwachung neu offengelegter Schwachstellen.

Die Beziehung zwischen IEC 62304 und Cybersicherheitsstandards verdient besondere Aufmerksamkeit. Während IEC 62304 Software-Lebenszyklusprozesse adressiert, behandelt er Cybersicherheit nicht umfassend. IEC 81001-5-1 (Gesundheitssoftware und Gesundheits-IT-Systeme -- Sicherheit, Wirksamkeit und Schutz) entwickelt sich zum massgeblichen Standard für Cybersicherheit in Medizinproduktesoftware und ist so konzipiert, dass er neben IEC 62304 eingesetzt wird. Darüber hinaus ist IEC 62443 (Industrielle Kommunikationsnetze -- Netz- und Systemsicherheit) für vernetzte Medizinprodukte relevant. Regulierungsbehörden erwarten zunehmend, dass Hersteller einen systematischen Ansatz zur Cybersicherheit nachweisen, der Bedrohungsmodellierung, Prinzipien des sicheren Designs, Schwachstellenmanagement und Verfahren für Sicherheitsupdates umfasst. Die Integration von Cybersicherheitsaktivitäten in Ihren IEC-62304-Lebenszyklus von Beginn an ist wesentlich effizienter, als sie nachträglich hinzuzufügen.

Für Software-Teams, die ihren IEC-62304-Weg beginnen, empfehlen wir folgendes Vorgehen: Beginnen Sie mit der Festlegung Ihrer Software-Sicherheitsklassifizierung mit einer dokumentierten Begründung, die mit Ihrer Risikomanagementakte verknüpft ist. Erstellen Sie dann einen Softwareentwicklungsplan, der Ihre tatsächlichen Prozesse ehrlich beschreibt, anstatt Prozesse anzustreben, die Sie nicht praktizieren. Bauen Sie Rückverfolgbarkeit von Tag eins in Ihre Werkzeugkette ein, sei es durch dedizierte ALM-Werkzeuge oder durch disziplinierten Einsatz von Anforderungsmanagement in Ihrem Issue-Tracker. Führen Sie einen SOUP-Managementprozess ein, der ein Verzeichnis aller Drittanbieter-Komponenten und ein Verfahren zur Überwachung und Bewertung von Sicherheitshinweisen umfasst. Bedenken Sie schliesslich, dass IEC-62304-Konformität keine einmalige Errungenschaft ist, sondern eine fortlaufende Disziplin. Ihre Prozesse müssen gepflegt, Ihre Dokumentation aktuell gehalten und Ihr Team in den Anforderungen geschult werden. Bei durchdachter Umsetzung stärkt IEC 62304 Ihren Entwicklungsprozess, reduziert Fehler und schafft die Nachweisbasis, die Regulierungsbehörden für die Marktzulassung benötigen.