Definition
Internationaler Standard für den Lebenszyklus von Software in Medizinprodukten. Definiert Prozesse für Software-Entwicklung, -Wartung und -Risikomanagement. Pflicht für alle Software as Medical Device (SaMD) und eingebettete Software unter MDR/IVDR. Ergänzt ISO 14971 und ISO 13485.
In der Praxis
Die IEC 62304 ist die Norm, bei der Software-Teams und QM am häufigsten aneinander vorbeireden. Der zentrale Hebel ist die Software-Sicherheitsklasse A, B oder C — sie bestimmt, wie tief die Entwicklungs-, Wartungs- und Risikomanagementprozesse ausfallen müssen. In der Praxis zeigen sich zwei Fehlermuster: Erstens wird die Klasse zu niedrig angesetzt, weil man den Dokumentationsaufwand scheut; die Klassifizierung richtet sich aber nach dem möglichen Schaden durch ein Versagen der Software, nicht nach dem Aufwand. Zweitens fehlt der Umgang mit SOUP — Software of Unknown Provenance, also zugekaufte Bibliotheken und Frameworks: Sie müssen identifiziert, mit Anforderungen versehen und im Risikomanagement berücksichtigt werden, inklusive bekannter Fehlerlisten des Lieferanten. Dazu kommt die Änderungssteuerung: Jedes Update ist eine Wartungsmaßnahme mit Bewertung der Auswirkungen, kein schneller Commit. Wer aus der Automotive-Welt kommt, findet in ASPICE ein verwandtes Prozessmodell — das ersetzt aber nicht die Lebenszyklus-Logik der IEC 62304, und bei KI-gestützter Software kommt der EU AI Act als weitere Ebene obendrauf.
Häufige Fragen zu IEC 62304
Gilt die IEC 62304 nur für eigenständige Software als Medizinprodukt?
Nein — die Norm gilt für den Software-Lebenszyklus von Medizinprodukten insgesamt (IEC 62304), also sowohl für eigenständige Software (Software as a Medical Device) als auch für Software, die in ein Gerät eingebettet ist oder es steuert. Sie definiert die Prozesse für Entwicklung, Wartung, Risikomanagement, Konfigurationsmanagement und Problemlösung. Abzugrenzen ist sie von der ISO 13485: Die liefert das übergeordnete QMS, die IEC 62304 die softwarespezifischen Lebenszyklusprozesse darin — beide greifen ineinander, und die ISO 13485 verlangt ihrerseits die Validierung von Software-Anwendungen. Auch zur ASPICE aus dem Automotive-Umfeld besteht Verwandtschaft im Prozessdenken, aber keine Gleichwertigkeit: Die IEC 62304 ist die regulatorisch anerkannte Referenz für Medizinprodukte-Software.
Was bedeuten die Software-Sicherheitsklassen A, B und C konkret für uns?
Die Klasse richtet sich nach dem Schaden, der durch ein Versagen der Software entstehen kann (IEC 62304, Kapitel 4.3): Klasse A, wenn keine Verletzung oder Schädigung möglich ist; Klasse B, wenn eine nicht schwerwiegende Verletzung möglich ist; Klasse C, wenn Tod oder schwerwiegende Verletzung möglich sind. Die Einstufung erfolgt zu Beginn und steuert den erforderlichen Umfang der Prozesse — bei Klasse C ist die volle Tiefe von Architektur über detailliertes Design bis zu umfangreicher Verifizierung gefordert, bei Klasse A ein reduzierter Satz. Wichtig: Die Klassifizierung muss dokumentiert und begründet sein, und sie kann sich ändern, wenn Risikokontrollmaßnahmen außerhalb der Software greifen. Eine zu niedrig angesetzte Klasse ist im Audit ein klassischer Major — die Begründung wird immer hinterfragt.
Wie gehen wir praktisch mit SOUP und Updates um?
SOUP — Software of Unknown Provenance, also zugekaufte oder fremde Softwarekomponenten ohne vollständige Entwicklungsdokumentation — behandeln Sie als eigenen Bestandteil der Architektur: inventarisieren, mit funktionalen und Leistungsanforderungen versehen, bekannte Fehlerlisten des Anbieters auswerten und im Software-Risikomanagement berücksichtigen. Für Updates gilt: Jede Änderung läuft über den Wartungsprozess (IEC 62304, Kapitel 6) — Auswirkungen bewerten, festlegen, welche Entwicklungs- und Verifizierungsaktivitäten zu wiederholen sind, dann erst freigeben. Das Konfigurationsmanagement muss jederzeit zeigen können, welche Version mit welchen SOUP-Versionen ausgeliefert wurde. Bewährt hat sich eine SOUP-Liste als lebendes Dokument, die bei jedem Release mitgepflegt wird. So bleibt die Kette aus Anforderung, Version und Risiko nachvollziehbar — genau das fragt die Benannte Stelle ab.