IEC 62304 ist die Prozessnorm für den Lebenszyklus von Software in Medizinprodukten. Sie legt keine Produktanforderungen fest, sondern die Aktivitäten, die ein Hersteller planen, durchführen und dokumentieren muss, damit Software als sicher entwickelt und gepflegt gelten kann. Anwendbar ist sie auf eigenständige Software, die selbst ein Medizinprodukt ist, und auf Software als Produktbestandteil. Die Verordnung (EU) 2017/745 verlangt in Anhang I Ziffer 17.2, dass Software nach dem Stand der Technik entwickelt und hergestellt wird, wobei die Grundsätze des Software-Lebenszyklus, des Risikomanagements einschließlich der Informationssicherheit sowie der Verifizierung und Validierung zu berücksichtigen sind. IEC 62304 ist die etablierte Referenz für diesen Nachweis.
Sicherheitsklassen A, B und C
Die Norm ordnet jedem Softwaresystem eine Sicherheitsklasse zu. Klasse A gilt, wenn kein Beitrag zu einer gefährlichen Situation möglich ist oder das daraus resultierende Risiko nach externen Risikokontrollmaßnahmen akzeptabel ist. Klasse B gilt, wenn eine nicht schwerwiegende Verletzung möglich ist, Klasse C, wenn Tod oder schwerwiegende Verletzung möglich sind. Maßgeblich ist der Schaden im schlimmsten Fall unter der Annahme, dass die Software versagt und externe Maßnahmen wirkungslos bleiben; die Fehlerwahrscheinlichkeit darf nicht mindernd angesetzt werden. Risikokontrolle außerhalb der Software, etwa in der Hardware, kann die Klasse um eine Stufe senken. Für einzelne Softwareelemente ist eine feinere Zuordnung möglich, wenn die Trennung begründet ist.
Der Softwareentwicklungsprozess
Kapitel 5 der Norm gliedert die Entwicklung in Planung, Anforderungsanalyse, Architekturentwurf, Detailentwurf, Implementierung und Verifizierung der Softwareeinheiten, Integration und Integrationstests, Systemtests sowie Freigabe. Der Entwicklungsplan legt Prozesse, Standards, Methoden, Werkzeuge und die zu erstellenden Ergebnisse fest. Der Umfang der Aktivitäten hängt von der Sicherheitsklasse ab: ein dokumentierter Detailentwurf einzelner Einheiten wird erst ab Klasse B verlangt, und die Anforderungen an Verifizierungstiefe und Nachvollziehbarkeit steigen zur Klasse C hin. Durchgängig gefordert ist die Rückverfolgbarkeit von Systemanforderungen über Architektur und Einheiten bis zu Tests und identifizierten Risiken.
Wartung, Konfigurationsmanagement und Problemlösung
Der Lebenszyklus endet nicht mit der Freigabe. Kapitel 6 fordert einen Wartungsplan, in dem Rückmeldungen bewertet, Änderungen kontrolliert umgesetzt und deren Auswirkungen auf Risiken und Verifizierung geprüft werden. Kapitel 8 verlangt Konfigurationsmanagement mit identifizierten Konfigurationselementen, Änderungskontrolle und Konfigurationsstatusberichten, sodass jede ausgelieferte Version reproduzierbar bleibt. Kapitel 9 regelt den Problemlösungsprozess: Erfassung und Bewertung von Problemen, Ursachenanalyse, Entscheidung über Maßnahmen, Verifizierung der Korrektur, Rückmeldung an betroffene Stellen und Prüfung, ob eine Meldepflicht nach den Vigilanzvorschriften ausgelöst wird. Kapitel 7 verzahnt die Softwareaktivitäten mit dem Risikomanagement.
Software unbekannter Herkunft und Fremdkomponenten
Fremdbezogene Bestandteile, in der Norm als Software unbekannter Herkunft, abgekürzt SOUP, bezeichnet, werden nicht nach IEC 62304 entwickelt, sind aber Teil des Produkts. Der Hersteller muss sie identifizieren, mindestens mit Name, Hersteller und eindeutiger Versionsbezeichnung, und für jede Komponente funktionale und leistungsbezogene Anforderungen sowie die benötigte Hardware- und Softwareumgebung festlegen. Veröffentlichte Anomalienlisten sind auf Relevanz für die Sicherheit zu bewerten, und für Updates ist ein Verfahren zu unterhalten. Bei quelloffenen Bibliotheken gehört dazu die laufende Beobachtung bekannter Schwachstellen, weil ein Fehler in einer Fremdkomponente dieselben Folgen hat wie ein eigener.
Abgrenzung zu ISO 14971, IEC 62366 und der Klassifizierung
IEC 62304 ersetzt keine der benachbarten Normen. ISO 14971 liefert das Risikomanagementsystem, auf das Kapitel 7 aufsetzt; die Sicherheitsklasse ist eine Größe der Prozesssteuerung und nicht das Ergebnis der Risikobewertung selbst. IEC 62366-1 deckt die Gebrauchstauglichkeit ab, also Bedienfehler und Benutzungsschnittstelle, die IEC 62304 nicht behandelt. ISO 13485 liefert den Rahmen des Qualitätsmanagementsystems, IEC 81001-5-1 ergänzt die Security-Aktivitäten im Lebenszyklus. Von allem zu trennen ist die regulatorische Risikoklasse des Produkts nach Anhang VIII, insbesondere Regel 11, zu der MDCG 2019-11 Qualifizierung und Klassifizierung von Software erläutert. Sicherheitsklasse und Risikoklasse sind unabhängige Größen.
Bedeutung für klinische Studien
Wird softwarebasierte Funktionalität in einer klinischen Prüfung untersucht, muss die zu prüfende Version eindeutig bestimmt und über die gesamte Studiendauer kontrolliert sein. Aus dem Konfigurationsmanagement ergibt sich, welcher Softwarestand an welchem Zentrum wann eingesetzt wurde; ohne diese Zuordnung sind Wirksamkeits- und Sicherheitsdaten nicht auswertbar. Änderungen während der Studie sind daher keine reine Entwicklungsfrage, sondern eine Prüfplanfrage: sie erfordern eine Bewertung der Auswirkung auf Endpunkte, Risikoanalyse und Verifizierung und gegebenenfalls eine Änderungsmeldung an Behörde und Ethik-Kommission.
Umgekehrt liefert die Studie Eingangsdaten für den Lebenszyklus. Im Prüfbetrieb festgestellte Fehlfunktionen und Bedienprobleme laufen in den Problemlösungsprozess und in die Bewertung, ob ein schwerwiegendes Vorkommnis oder eine Sicherheitskorrekturmaßnahme vorliegt. Erhebungsinstrumente müssen technische Auffälligkeiten daher strukturiert erfassen und von klinischen Ereignissen trennen. Full-Service-CROs wie Mediconomics unterstützen Hersteller bei der Verzahnung von Prüfplan und Versionskontrolle, bei der Bewertung studienbedingter Softwareänderungen, bei der Erfassung technischer Vorkommnisse sowie beim Medical Writing für klinische Bewertung und Studienunterlagen.
Häufig gestellte Fragen (FAQ)
Wie wird die Sicherheitsklasse bestimmt?
Über den schlimmstmöglichen Schaden bei Softwareversagen, ohne mindernde Berücksichtigung der Fehlerwahrscheinlichkeit und unter der Annahme, dass externe Maßnahmen ausfallen. Wirksame Risikokontrolle außerhalb der Software kann die Klasse um eine Stufe senken.
Entspricht die Sicherheitsklasse der Risikoklasse nach der MDR?
Nein. Die Sicherheitsklasse A, B oder C steuert den Umfang der Lebenszyklusprozesse. Die Risikoklasse I bis III nach Anhang VIII bestimmt den Konformitätsbewertungsweg. Beide werden getrennt ermittelt.
Muss quelloffene Software besonders behandelt werden?
Ja, als Software unbekannter Herkunft. Erforderlich sind Identifikation mit Version, festgelegte Anforderungen, Bewertung bekannter Anomalien und Schwachstellen sowie ein kontrolliertes Vorgehen bei Aktualisierungen.
Regulatorische Referenzen
- Verordnung (EU) 2017/745, Anhang I Ziffer 17 – Anforderungen an programmierbare Systeme und Software
- IEC 62304 – Software-Lebenszyklus-Prozesse für Medizinprodukte-Software, Kapitel 4 bis 9
- ISO 14971 – Anwendung des Risikomanagements auf Medizinprodukte
- IEC 62366-1 – Anwendung der Gebrauchstauglichkeit auf Medizinprodukte
- MDCG 2019-11 – Qualifizierung und Klassifizierung von Software
