Medizinproduktesoftware · Lebenszyklusnachweise · Risikokontrolle
IEC 62304 – der zentrale Standard für Medizinproduktesoftware
Der Code ist nur eine Ebene des Produkts
IEC 62304 macht die Entscheidungen hinter der Medizinproduktesoftware sichtbar. Der Standard verbindet Anforderungen, Architektur, Risiken, Prüfungen, Freigaben und Änderungen zu einem gelenkten Lebenszyklus.
In den Lebenszyklus einsteigen ↓Sicherheitsklasse
Akeine Verletzung Bnicht schwere Verletzung CTod oder schwere VerletzungAnforderungen
Zweck · Funktionen · KontrollenArchitektur
Elemente · Schnittstellen · TrennungImplementierung
Einheiten · Reviews · KonfigurationVerifizierung
Prüfungen · Ergebnisse · RückverfolgbarkeitFreigabe
Baseline · Anomalien · GenehmigungWartung
Probleme · Änderungen · RegressionDer regulatorische Wert
IEC 62304 macht aus Entwicklungsarbeit prüfbare Nachweise
Erklären
Was die Software leisten soll und wie ihre Architektur die Zweckbestimmung unterstützt.
Beherrschen
Wie Ausfälle, Änderungen, Konfigurationen und ungelöste Anomalien kontrolliert werden.
Nachweisen
Wie Anforderungen und Risikokontrollmaßnahmen zu objektiven Verifizierungsnachweisen führen.
01
Warum IEC 62304 entscheidend ist #
Medizinproduktesoftware besitzt möglicherweise keine beweglichen Teile, keine Sterilverpackung und keine physischen Werkstoffe. Hinter einer scheinbar einfachen Oberfläche steht jedoch ein eng verbundenes System aus Anforderungen, Algorithmen, Datenflüssen, Risikokontrollen, Prüfungen, Konfigurationen und Aktualisierungen. Werden diese Elemente nicht beherrscht, kann auch sauber geschriebener Code zu einem unsicheren Medizinprodukt werden.
IEC 62304 schafft den Rahmen, um dieses System unter Kontrolle zu bringen.
Der Standard trägt den offiziellen Titel „Medizinproduktesoftware – Software-Lebenszyklusprozesse“. Er legt Prozesse, Aktivitäten und Aufgaben für die Entwicklung und Wartung von Medizinproduktesoftware fest. Er gilt sowohl für Software, die Bestandteil eines Medizinprodukts ist, als auch für Software, die selbst ein Medizinprodukt darstellt. Die aktuelle konsolidierte Fassung ist IEC 62304:2006+A1:2015.
Der Standard sagt nicht, welche medizinischen Aussagen ein Hersteller treffen darf, wie sein Produkt nach MDR oder IVDR einzustufen ist oder ob die klinischen Nachweise ausreichen. Seine Aufgabe ist eine andere. Der Hersteller muss zeigen, dass die Software in einem gelenkten und risikobasierten Prozess entwickelt, freigegeben, gewartet und geändert wurde.
IEC 62304 beherrscht den Software-Lebenszyklus. Sie ersetzt nicht die vollständige regulatorische Bewertung des Medizinprodukts.
02
Zwei Fachwelten treffen in einem Standard zusammen #
IEC 62304 liegt an der Schnittstelle zweier beruflicher Welten.
Architektur
Quellcode
Versionskontrolle
Fehlerverfolgung
Regressionstests
62304
Risikoakzeptanz
Qualitätsaufzeichnungen
CAPA
Vigilanz
Technische Dokumentation
Softwareentwickler kennen sich mit Architektur, Quellcode, Versionskontrolle, Fehlerverfolgung, Integrationstests und Freigabemanagement aus. Regulatorische Konzepte wie Risikoakzeptanz, Vigilanz, CAPA und gelenkte technische Dokumentation sind ihnen möglicherweise weniger vertraut.
Fachleute für Medizinprodukte verstehen Qualitätsmanagementsysteme, Risikomanagement und Konformitätsbewertung. Weniger vertraut sind ihnen mitunter Softwarezerlegung, Konfigurationselemente, Regressionstests, ungelöste Anomalien und Software unbekannter Herkunft.
IEC 62304 verbindet beide Welten. Sie übersetzt Entwicklungsarbeit in regulatorische Nachweise und regulatorische Erwartungen in konkrete Entwicklungstätigkeiten. Deshalb kann die Umsetzung weder vollständig an das Regulatory-Team noch ausschließlich an die Entwickler delegiert werden.
03
Die Nachweiskette hinter der Software #
Das Grundprinzip der IEC 62304 ist leicht zu verstehen. Der Hersteller muss erklären können, was die Software leisten soll, was schiefgehen kann, wie das System diese Risiken beherrscht, wie die Risikokontrollen geprüft wurden, welche Konfiguration freigegeben wurde und wie künftige Probleme und Änderungen behandelt werden.
Zweck
Medizinische FunktionAnforderungen
Festgelegtes VerhaltenRisikokontrollen
Umgesetzte MaßnahmenVerifizierung
Objektive NachweiseFreigabe
Bekannte KonfigurationWartung
Gelenkte ÄnderungenZweckbestimmung und Systemanforderungen führen zu Softwareanforderungen. Die Softwareanforderungen beeinflussen Architektur und detaillierte Auslegung. Erkannte Risiken führen zu Risikokontrollmaßnahmen. Diese werden zu Anforderungen, die umgesetzt und verifiziert werden müssen. Prüfergebnisse müssen auf die jeweiligen Anforderungen zurückverweisen. Die freigegebene Konfiguration muss genau der Version entsprechen, die in den Nachweisen beschrieben ist.
Fehlt ein Glied, kann die technische Dokumentation für die Medizinproduktesoftware viele Dateien enthalten und trotzdem keine beherrschte Entwicklung nachweisen.
04
Software-Sicherheitsklassifizierung #
IEC 62304 ordnet das Softwaresystem einer Sicherheitsklasse A, B oder C zu. Diese Einstufung bestimmt, welche Lebenszyklusaktivitäten und Dokumentationsanforderungen gelten.
Keine Verletzung
Ein Versagen der Software kann nicht zu einer Verletzung oder Gesundheitsschädigung führen.
Grundlegende LebenszykluskontrollenNicht schwere Verletzung
Ein Versagen der Software kann zu einer Verletzung führen, die nicht schwerwiegend ist.
Zusätzliche Auslegungs- und VerifizierungsnachweiseTod oder schwere Verletzung
Ein Versagen der Software kann zum Tod oder zu einer schweren Verletzung führen.
Umfangreichste LebenszyklusnachweiseSoftware-Sicherheitsklasse A, B oder C
Regulatorische Produktklasse
Die Sicherheitsklassen der IEC 62304 dürfen nicht mit den MDR-Klassen I, IIa, IIb und III oder den IVDR-Klassen A, B, C und D verwechselt werden. Es handelt sich um getrennte Klassifizierungssysteme, die unterschiedliche Fragen beantworten.
Entscheidend ist die Schwere des Schadens, der durch einen Softwarefehler entstehen kann, nicht die Frage, ob die Software den Schaden unmittelbar oder mittelbar verursacht. Die Begründung der Sicherheitsklasse sollte mit dem Risikomanagementprozess des Produkts verbunden sein.
Stützt sich der Hersteller bei der Klassifizierung auf Risikokontrollen außerhalb der Software, müssen diese Kontrollen und ihre Wirksamkeit eindeutig dokumentiert werden. Eine Sicherheitsklasse darf niemals nur deshalb gewählt werden, weil sie den erforderlichen Aufwand verringert.
05
Was der Hersteller beherrschen muss #
Planung der Softwareentwicklung
Der Hersteller legt fest, wie die Software entwickelt, verifiziert, freigegeben und gewartet wird. Der Plan benennt Verantwortlichkeiten, Tätigkeiten, Verfahren, Ergebnisse, Konfigurationskontrollen und Verbindungen zum Risikomanagement.
Der Plan sollte das tatsächliche Entwicklungsmodell abbilden. Agile Entwicklung kann mit IEC 62304 vereinbar sein, wenn Anforderungen, Risiken, Reviews, Prüfungen, Änderungen und Freigaben gelenkt und rückverfolgbar bleiben.
Softwareanforderungen
Anforderungen beschreiben, was das System leisten muss und unter welchen Bedingungen es arbeitet. Sie können Funktionalität, Ein- und Ausgaben, Schnittstellen, Datenverarbeitung, Leistung, Alarme, Sicherheit, Gebrauchstauglichkeit und Risikokontrollen betreffen.
Unklare Anforderungen führen zu unklaren Prüfungen. Sicherheitsbezogene Anforderungen sollten auf die Gefährdungen und Risikokontrollmaßnahmen zurückgeführt werden können, aus denen sie entstanden sind.
Architektur und detaillierte Auslegung
Die Architektur erklärt, wie das System in Elemente gegliedert ist und wie diese zusammenwirken. Sie zeigt Schnittstellen, Abhängigkeiten, Datenflüsse, Trennungsmaßnahmen und Komponenten, deren Ausfall die Sicherheit beeinträchtigen kann.
Für höhere Sicherheitsklassen erwartet der Standard zunehmend detaillierte Angaben zu Softwareelementen und -einheiten. Ziel ist nicht die zeilenweise Dokumentation des Codes, sondern eine verständliche und prüfbare Darstellung der sicherheitsrelevanten Struktur.
Implementierung und Verifizierung
Die Implementierung folgt genehmigten Anforderungen und Auslegungsentscheidungen. Die Verifizierung zeigt, dass jedes Entwicklungsergebnis seine Eingangsanforderungen erfüllt.
Die Prüfungen können Einheiten-, Integrations-, System-, Schnittstellen- und Regressionstests umfassen. Aussagekräftige Nachweise benennen die Anforderung, die geprüfte Konfiguration, die Akzeptanzkriterien, das Ergebnis und den Umgang mit Abweichungen.
Konfigurationsmanagement
Der Hersteller muss die regulierte Version, die Quellcode-Baseline, Komponenten Dritter, die Build-Umgebung, die Dokumentation, Prüfnachweise und ungelöste Anomalien eindeutig identifizieren.
Bei cloudbasierten Produkten kann das Konfigurationsmanagement auch serverseitige Komponenten, APIs, Infrastrukturabhängigkeiten, Modelle, Datensätze und Dienste umfassen, die sich unabhängig von der Benutzeranwendung ändern können.
Problemlösung
Ein Problembericht darf nicht verschwinden, sobald ein Entwickler ein Ticket schließt. Der Hersteller bewertet seine Sicherheitsrelevanz, entscheidet über erforderliche Korrekturmaßnahmen, beurteilt die Auswirkungen einer Änderung, führt angemessene Regressionstests durch und bewahrt die Aufzeichnungen auf.
Nicht jede Anomalie muss zwingend vor der Freigabe behoben werden. Ungelöste Anomalien müssen dennoch dokumentiert, bewertet und begründet werden.
Softwarewartung
Der Lebenszyklus endet nicht mit der Freigabe. Die Wartung umfasst die Bewertung von Rückmeldungen, die Analyse von Problemen, die Umsetzung von Änderungen, die Verifizierung von Modifikationen und die Freigabe aktualisierter Konfigurationen.
IEC 62304 unterstützt diesen Prozess, ersetzt aber nicht das vollständige System zur Überwachung nach dem Inverkehrbringen, das MDR oder IVDR verlangen.
06
IEC 62304 wirkt innerhalb eines größeren Systems #
IEC 62304 ist gerade deshalb so wirkungsvoll, weil sie den Software-Lebenszyklus gezielt behandelt. Diese enge Ausrichtung bedeutet zugleich, dass der Standard nicht allein stehen kann.
Rahmen des Qualitätsmanagementsystems
Risikomanagement für Medizinprodukte
Software-Lebenszyklusprozesse
Gebrauchstauglichkeitsentwicklung
Klinische Nachweise oder Leistungsnachweise
Cybersicherheit über den gesamten Lebenszyklus
ISO 13485 bietet den übergeordneten Qualitätsmanagementrahmen für Verantwortlichkeiten, Dokumentenlenkung, Lieferantenmanagement, CAPA und weitere organisatorische Prozesse.
ISO 14971 legt den Risikomanagementprozess für Medizinprodukte fest. IEC 62304 verbindet Softwareaktivitäten mit diesem Prozess, ersetzt ihn aber nicht.
IEC 62366-1 behandelt die Gebrauchstauglichkeitsentwicklung. Eine Funktion kann technisch korrekt arbeiten und dennoch ein Risiko erzeugen, wenn Anwender ein Ergebnis falsch verstehen, einen Alarm übersehen oder den falschen Patienten auswählen.
IEC 62304 hilft, Entwicklung, Wartung und Änderungen zu beherrschen, bietet jedoch keinen vollständigen Rahmen für die Cybersicherheit. Sicherheitsarchitektur, Bedrohungsmodellierung, Schwachstellenmanagement, sichere Aktualisierungen und Überwachung nach dem Inverkehrbringen erfordern zusätzliche Maßnahmen. MDRC behandelt diese Elemente im Leitfaden zur Cybersicherheit von Medizinproduktesoftware.
Die klinische Bewertung nach MDR beziehungsweise die Leistungsbewertung nach IVDR bleibt eine eigenständige Anforderung. Auch perfekt entwickelte Software kann unzureichend belegen, dass ihre Ergebnisse klinisch oder diagnostisch relevant sind.
07
Was IEC 62304 nicht abdeckt #
Die Grenzen des Standards sind ebenso wichtig wie seine Anforderungen.
Entwicklungsprozess
Wartungsprozess
Verknüpfung mit Softwarerisiken
Konfigurationsmanagement
Problemlösung
Qualifizierung und Klassifizierung des Produkts
Endgültige Produktvalidierung und -freigabe
Klinische Bewertung oder Leistungsbewertung
Vollständige Nachweise zu Gebrauchstauglichkeit und Cybersicherheit
Konformitätsbewertung nach MDR oder IVDR
Die IEC erklärt ausdrücklich, dass IEC 62304 weder die endgültige Validierung noch die endgültige Freigabe des Medizinprodukts abdeckt, selbst wenn das Produkt vollständig aus Software besteht. Der Hersteller muss den Software-Lebenszyklus daher in einen übergeordneten Produktentwicklungs- und Validierungsprozess einbinden.
IEC 62304 entscheidet nicht, ob Software als Medizinprodukt zu qualifizieren ist, welche Verordnung gilt oder welche MDR- beziehungsweise IVDR-Klasse zutrifft. Diese Entscheidungen ergeben sich aus der Zweckbestimmung und den regulatorischen Merkmalen der Software. MDRC erläutert diese Abgrenzung im Beitrag über Software als Medizinprodukt oder Zubehör.
Der Standard bestimmt auch nicht die Angemessenheit klinischer Nachweise, ersetzt nicht die Gebrauchstauglichkeitsentwicklung, vervollständigt nicht die Cybersicherheitsakte und erfüllt nicht sämtliche Anforderungen an die technische Dokumentation. Eine Erklärung zur Einhaltung der IEC 62304 kann die Konformität mit MDR oder IVDR nicht allein belegen.
08
IEC 62304 und CE-Kennzeichnung #
Die MDR und die IVDR verlangen, dass Software unter Berücksichtigung des Stands der Technik, der Lebenszyklusgrundsätze, des Risikomanagements, der Informationssicherheit sowie der Verifizierung und Validierung entwickelt und hergestellt wird. IEC 62304 bietet eine anerkannte Struktur, um einen wesentlichen Teil dieser Nachweise zu erzeugen.
Die Anwendung von Standards bleibt freiwillig. Nach EU-Recht entsteht eine Konformitätsvermutung nur, wenn die Fundstelle einer harmonisierten Norm im Amtsblatt der Europäischen Union veröffentlicht wurde, und nur für die regulatorischen Anforderungen, die von dieser Norm abgedeckt werden. Die Europäische Kommission erläutert diese Unterscheidung in ihrem Leitfaden zur Normung von Medizinprodukten.
Die Einhaltung der IEC 62304 kann die Konformitätsargumentation des Herstellers stärken, führt aber nicht automatisch zur CE-Kennzeichnung oder zur Genehmigung durch eine Benannte Stelle.
Der vollständige Weg verlangt weiterhin eine korrekte Qualifizierung und Klassifizierung, technische Dokumentation, Risikomanagement, ein Qualitätsmanagementsystem, Gebrauchstauglichkeitsentwicklung, Cybersicherheit, klinische Bewertung oder Leistungsbewertung, Überwachung nach dem Inverkehrbringen und gegebenenfalls die Konformitätsbewertung durch eine Benannte Stelle.
09
Der häufigste Fehler bei der Umsetzung #
Ein besonders häufiger Fehler besteht darin, IEC 62304 als Dokumentationsaufgabe zu behandeln, die erst nach Abschluss der Entwicklung erledigt wird.
Teams versuchen dann, Anforderungen aus dem fertigen Code zu rekonstruieren, Prüfergebnisse mit Anforderungen zu verbinden, die zum Zeitpunkt der Prüfung noch nicht existierten, und Architekturentscheidungen zu begründen, die nie formell aufgezeichnet wurden.
Rekonstruierte Anforderungen
Unklare Auslegungsentscheidungen
Isolierte Prüfergebnisse
Lückenhafte Änderungshistorie
Geplante Anforderungen
Dokumentierte Architektur
Rückverfolgbare Verifizierung
Gelenkte Freigaben
Der erste Ansatz erzeugt Dokumente, aber selten eine überzeugende Rückverfolgbarkeit. IEC 62304 funktioniert am besten, wenn sie die Entwicklung von Anfang an prägt. Die Dokumentation sollte aus gelenkten Entwicklungstätigkeiten entstehen und nicht später verfasst werden, um lediglich den Anschein von Kontrolle zu erzeugen.
10
Das Fazit #
IEC 62304 ist nicht einfach ein Standard über Softwaredokumente. Sie ist ein Rahmen, der die Sicherheit von Medizinproduktesoftware erklärbar macht.
Der Hersteller muss nachweisen, wie die Software geplant, ausgelegt, implementiert, verifiziert, freigegeben, gewartet und geändert wurde. Der Standard verwandelt unsichtbare Entwicklungsentscheidungen in prüfbare Nachweise und verbindet den Software-Lebenszyklus mit dem Risikomanagement des Medizinprodukts.
IEC 62304 ersetzt weder die Konformität mit MDR oder IVDR noch verleiht sie die CE-Kennzeichnung. Sie bietet jedoch eine der stärksten Grundlagen für den Nachweis, dass Medizinproduktesoftware nicht einfach so lange programmiert wurde, bis sie zu funktionieren schien, sondern als gelenktes Medizinprodukt entwickelt wurde, dessen Risiken, Versionen und Änderungen über den gesamten Lebenszyklus verstanden werden.
Für Hersteller auf dem Weg zur CE-Kennzeichnung von Medizinproduktesoftware kann genau dieser Unterschied darüber entscheiden, ob die technische Dokumentation nur vollständig aussieht oder einer gründlichen regulatorischen Prüfung standhält.
Das praktische Ergebnis
Ein Lebenszyklus, der auch nach dem Wechsel der ursprünglichen Entwickler verständlich bleibt
Eine gute Umsetzung der IEC 62304 schafft mehr als eine Spur für den Auditor. Sie gibt dem Hersteller eine verlässliche Methode, die Auswirkungen eines Fehlers zu verstehen, eine geplante Änderung zu bewerten und die nächste Version freizugeben, ohne die Kontrolle über das Medizinprodukt zu verlieren.
Hier wird Softwareentwicklung zu regulatorischem Nachweis.
Konformität des Software-Lebenszyklus
Soll Ihr Entwicklungsprozess zu einem belastbaren Nachweissystem nach IEC 62304 werden?
Software-Lebenszyklus besprechen ↗Aus dem Wissenszentrum