Interaktive Prüfliste: Software-Lebenszyklus (IEC 62304 & MDR)

Qualifizierung als Medizinprodukt-Software

Ist die Software gemäß ihrer Zweckbestimmung als Medizinprodukt qualifiziert?

Referenz: MDR Artikel 2 Absatz 1, MDCG 2019-11.

Prüfhinweis: Überprüfen Sie die vom Hersteller angegebene Zweckbestimmung und stellen Sie sicher, dass sie mit der Definition eines Medizinprodukts übereinstimmt. Achten Sie auf Abgrenzungen zu reiner Wellness-, Lifestyle- oder IT-Infrastruktur-Software.

Klassifizierung der Software (MDR & IEC 62304)

Ist die Klassifizierung der Software korrekt erfolgt und begründet?

Referenz: MDR Anhang VIII Regel 11, IEC 62304 Clause 4.3.

Prüfhinweis:
MDR-Klasse: Überprüfen Sie, ob die Klassifizierung gemäß MDR Anhang VIII Regel 11 korrekt ist (z.B. Software, die ein Medizinprodukt steuert oder Informationen für Entscheidungen liefert, kann in einer höheren Klasse als Klasse I landen). Begründung der gewählten Klasse muss vorliegen.
IEC 62304 Sicherheitsklasse: Überprüfen Sie, ob die Software-Sicherheitsklasse (A, B oder C) nach IEC 62304 festgelegt und schlüssig begründet ist. Die Begründung muss auf einer initialen Risikoanalyse basieren, die den möglichen Schweregrad des Schadens durch einen Softwarefehler berücksichtigt (Klasse A: keine Verletzung; Klasse B: keine schwere Verletzung; Klasse C: Tod oder schwere Verletzung). Stellen Sie sicher, dass die gewählte Klasse die zu erwartenden Risiken adäquat widerspiegelt.

Nachweis der Anwendung von Normen

Ist nachvollziehbar dargelegt, welche harmonisierten Normen (insbesondere IEC 62304, ISO 14971, IEC 62366-1) und gegebenenfalls Gemeinsamen Spezifikationen (CS) angewendet wurden?

Referenz: MDR Anhang II Absatz 4.

Prüfhinweis: Die technische Dokumentation sollte eine Liste der angewendeten Normen und Spezifikationen enthalten. Prüfen Sie, ob Abweichungen von harmonisierten Normen begründet sind und ob die entsprechenden GSPR trotzdem erfüllt werden.

Software-Entwicklungsplan vorhanden

Existiert ein Entwicklungsplan, der alle relevanten Phasen und Aktivitäten des Software-Lebenszyklus abdeckt?

Referenz: IEC 62304 Clause 5.1.1.

Prüfhinweis: Der Plan sollte die Software-Sicherheitsklasse berücksichtigen und einen angemessenen Detaillierungsgrad aufweisen. Er dient als Roadmap für die gesamte Softwareentwicklung.

Berücksichtigung der Software-Sicherheitsklasse im Plan

Werden die Anforderungen an die Prozesse und Dokumentation im Entwicklungsplan der zugewiesenen Software-Sicherheitsklasse gerecht?

Referenz: IEC 62304 Clause 5.1.2.

Prüfhinweis: Für Klasse C sind beispielsweise detailliertere Dokumentationen (Architektur, detaillierte Tests) erforderlich als für Klasse A. Die Prozesse müssen der Risikokategorie entsprechen.

Definition der Entwicklungsumgebung

Ist die Software-Entwicklungsumgebung (Tools, Compiler, Betriebssysteme etc.) definiert, qualifiziert und konfigurationsverwaltet?

Referenz: IEC 62304 Clause 5.1.3.

Prüfhinweis: Alle verwendeten Tools, die die Qualität oder Sicherheit der Software beeinflussen können, müssen identifiziert und deren Versionsstände dokumentiert sein. Gegebenenfalls sind Nachweise der Tool-Qualifizierung oder Begründungen für deren Angemessenheit erforderlich (z.B. durch Validierung des Tool-Einsatzes).

Rollen und Verantwortlichkeiten

Sind Rollen, Verantwortlichkeiten und Befugnisse für alle Software-Lebenszyklus-Aktivitäten klar definiert und zugewiesen?

Referenz: IEC 62304 Clause 5.1.4.

Prüfhinweis: Überprüfen Sie Organigramme, Stellenbeschreibungen oder Prozessbeschreibungen, die die Zuständigkeiten im Software-Team und deren Schnittstellen zu anderen Abteilungen (z.B. Risikomanagement, Qualitätssicherung) festlegen.

Strategie für SOUP (Software Of Unknown Pedigree)

Ist eine Strategie für den Umgang mit SOUP-Komponenten (z.B. Open-Source-Bibliotheken, Betriebssysteme, kommerzielle Off-the-Shelf-Software) definiert und umgesetzt?

Referenz: IEC 62304 Clause 5.1.5.

Prüfhinweis: Dies umfasst eine Risikobewertung der SOUP-Komponenten, deren Verifikation im Kontext der Anwendung und eine Strategie zur Überwachung auf bekannte Schwachstellen (z.B. CVEs). Die Dokumentation sollte auch Lizenzbedingungen berücksichtigen.

Integration in das allgemeine Risikomanagement

Ist das Software-Risikomanagement vollständig in den übergeordneten Risikomanagement-Prozess des Medizinprodukts integriert?

Referenz: MDR Anhang I Absatz 3, IEC 62304 Clause 4.2, 7, ISO 14971.

Prüfhinweis: Das Risikomanagement sollte den gesamten Lebenszyklus umfassen und nicht nur auf die Entwicklung beschränkt sein. Es muss eine klare Verbindung zur übergeordneten Risikomanagement-Akte bestehen.

Gefährdungs- und Risikoanalyse (Software-spezifisch)

Sind alle relevanten softwarebedingten Gefährdungen und Gefährdungssituationen identifiziert und die damit verbundenen Risiken bewertet worden?

Referenz: IEC 62304 Clause 7.2, 7.3.

Prüfhinweis: Dies umfasst Softwarefehler (z.B. Logikfehler, Speicherlecks), Fehlfunktionen, Usability-Fehler, Cybersecurity-Risiken (siehe MDCG 2019-16) und das Zusammenspiel von Software und Hardware. Die Analyse sollte systematisch erfolgen (z.B. FMEA, FTA).

Risikobeherrschungsmaßnahmen

Sind angemessene Maßnahmen zur Risikobeherrschung für alle identifizierten Software-Risiken definiert und implementiert worden?

Referenz: IEC 62304 Clause 7.4.

Prüfhinweis: Hierzu gehören Designmaßnahmen (z.B. redundante Systeme, robuste Architektur), technische Maßnahmen (Fehlerbehandlung, Eingabeprüfung, Datensicherung), aber auch Verifikations- und Validierungsmaßnahmen sowie Informationen für die Benutzer (Gebrauchsanweisung).

Verifizierung der Risikobeherrschungsmaßnahmen

Ist die Wirksamkeit der implementierten Risikobeherrschungsmaßnahmen nachgewiesen (z.B. durch spezifische Tests, Reviews, Simulationen)?

Referenz: IEC 62304 Clause 7.5.

Prüfhinweis: Für jede implementierte Risikobeherrschungsmaßnahme muss ein Nachweis vorliegen, dass sie das Risiko wie beabsichtigt reduziert oder eliminiert. Dies kann durch Tests, Reviews von Code oder Design, oder andere Verifikationsaktivitäten erfolgen.

Restrisikobewertung

Sind alle Restrisiken bewertet und als akzeptabel deklariert worden?

Referenz: ISO 14971.

Prüfhinweis: Die Akzeptanzkriterien für Restrisiken müssen klar definiert und begründet sein (z.B. unter Berücksichtigung des Stands der Technik und der Vorteile des Produkts). Es muss eine Gesamtrisikobewertung des Geräts unter Einbeziehung der Software vorliegen.

Spezifikation der Software-Anforderungen

Sind die Software-Anforderungen vollständig, eindeutig, testbar und nachverfolgbar spezifiziert?

Referenz: IEC 62304 Clause 5.2.1.

Prüfhinweis: Die Anforderungen müssen sowohl funktionale als auch nicht-funktionale Aspekte (Leistung, Zuverlässigkeit, Sicherheit, Usability, Wartbarkeit, Schnittstellen) abdecken und die Allgemeinen Sicherheits- und Leistungsanforderungen (GSPR) der MDR berücksichtigen.

Anforderungen an Cybersecurity

Sind Cybersecurity-Anforderungen (z.B. Authentifizierung, Autorisierung, Datenintegrität, Schutz vor unbefugtem Zugriff, sichere Updates, Patch-Management, Vorkehrungen gegen Malware) spezifiziert und in der Software-Architektur berücksichtigt?

Referenz: MDR Anhang I Absatz 17, MDCG 2019-16.

Prüfhinweis: Überprüfen Sie, ob die relevanten Bedrohungsmodelle und Schutzmaßnahmen gegen Cyberangriffe in den Anforderungen berücksichtigt wurden.

Anforderungen an Gebrauchstauglichkeit

Sind Usability-Anforderungen definiert und in die Softwareentwicklung integriert, um Anwendungsfehler zu minimieren?

Referenz: MDR Anhang I Absatz 14.2, IEC 62366-1.

Prüfhinweis: Es sollte eine Verknüpfung zur Usability Engineering File (UEF) und den Ergebnissen der Usability-Tests bestehen. Anforderungen an die Benutzeroberfläche, Fehlermeldungen und intuitive Bedienung sind hier relevant.

Rückverfolgbarkeit (Traceability) der Anforderungen

Ist die Rückverfolgbarkeit von den Systemanforderungen zu den Software-Anforderungen, dem Design, der Implementierung und den Tests gegeben?

Referenz: IEC 62304 Clause 5.2.2.

Prüfhinweis: Eine Traceability-Matrix oder ein äquivalentes System sollte belegen, dass jede Anforderung im Design umgesetzt und getestet wurde, und dass jedes Designelement einer Anforderung zugeordnet werden kann.

Software-Architektur-Dokument vorhanden

Ist ein Dokument zur Software-Architektur vorhanden, das die Hauptkomponenten, Schnittstellen und deren Zusammenspiel beschreibt?

Referenz: IEC 62304 Clause 5.3.1.

Prüfhinweis: Das Dokument sollte die Software-Sicherheitsklasse reflektieren und die relevanten Elemente (z.B. Subsysteme, Module, Datenflüsse, externe Schnittstellen) klar darstellen. Es sollte auch die logische und physische Architektur umfassen.

Design für Fehlerbehandlung

Ist das Design der Fehlerbehandlung und Fehlertoleranz in der Architektur berücksichtigt?

Referenz: IEC 62304 Clause 5.3.2.

Prüfhinweis: Wie werden Fehler erkannt, protokolliert, behoben oder gemindert? Sind Mechanismen wie Redundanz, Checksummen, Watchdogs, Fehlerloggings und Wiederherstellungsstrategien vorgesehen?

Segregation von Software-Komponenten

Falls Komponenten unterschiedlicher Sicherheitsklassen existieren, ist nachgewiesen, dass die Segregation wirksam ist, um eine Beeinflussung höherer Sicherheitsklassen durch niedrigere zu verhindern?

Referenz: IEC 62304 Clause 5.3.5.

Prüfhinweis: Eine Analyse und Dokumentation der Schnittstellen und des Isolationsprinzips ist erforderlich. Dies ist kritisch, wenn zum Beispiel nicht-sicherheitskritische Komponenten auf die gleiche Hardware wie sicherheitskritische Komponenten zugreifen.

Detailliertes Software-Design

Existiert ein detailliertes Design für die Software-Einheiten, das die interne Struktur, Algorithmen und Datenstrukturen beschreibt?

Referenz: IEC 62304 Clause 5.4.1.

Prüfhinweis: Dies ist besonders wichtig für sicherheitskritische Software (Klasse C). Das Design sollte ausreichend detailliert sein, um die Implementierung zu leiten und eine Überprüfung zu ermöglichen.

Implementierung

Ist die Software gemäß dem Design implementiert?

Referenz: IEC 62304 Clause 5.5.1.

Prüfhinweis: Prüfen Sie, ob Code-Richtlinien verwendet wurden und ob Tools zur statischen Code-Analyse eingesetzt wurden, um potenzielle Fehler oder Sicherheitslücken frühzeitig zu erkennen.

Verifizierung der Software-Einheiten (Unit-Tests)

Sind die einzelnen Software-Einheiten (Module, Funktionen) verifiziert (z.B. durch Unit-Tests)?

Referenz: IEC 62304 Clause 5.5.2.

Prüfhinweis: Es müssen Nachweise der Testdurchführung und der Testergebnisse, idealerweise mit Angabe der Testabdeckung (z.B. Code Coverage), vorliegen.

Integration der Software-Einheiten

Ist der Prozess der Integration der Software-Einheiten beschrieben?

Referenz: IEC 62304 Clause 5.6.1.

Prüfhinweis: Es sollte eine klare Definition der Integrationsstrategie (z.B. Top-down, Bottom-up, Big Bang) vorhanden sein.

Integrationstests

Sind Integrationstests durchgeführt und deren Ergebnisse dokumentiert, um das korrekte Zusammenspiel der integrierten Einheiten und Module zu überprüfen?

Referenz: IEC 62304 Clause 5.6.2.

Prüfhinweis: Vorhandensein von Testfällen, Testprotokollen und einer Dokumentation der Fehlerbehebung und Regressionstests.

Systemtestplan und -spezifikation

Existiert ein Software-Systemtestplan, der die Testziele, Testumgebung und die zu testenden Anforderungen (basierend auf den Software-Anforderungen) festlegt?

Referenz: IEC 62304 Clause 5.7.1, 5.7.2.

Prüfhinweis: Der Plan muss die Abdeckung aller funktionalen, nicht-funktionalen und insbesondere der sicherheitsrelevanten Anforderungen sicherstellen.

Durchführung und Dokumentation der Systemtests

Sind die Software-Systemtests durchgeführt und deren Ergebnisse (inklusive Abweichungen und deren Behebung) dokumentiert?

Referenz: IEC 62304 Clause 5.7.3.

Prüfhinweis: Vollständige Testprotokolle, Nachweis der Fehlerbehebung und Durchführung von Regressionstests nach Fehlerkorrekturen.

Test zur Erfüllung der GSPR

Wurden spezifische Tests durchgeführt, um die Einhaltung aller relevanten GSPR (Allgemeine Sicherheits- und Leistungsanforderungen) der MDR zu überprüfen, die die Software betreffen?

Referenz: MDR Anhang I.

Prüfhinweis: Überprüfen Sie Verweise auf entsprechende Testprotokolle und Berichte, die die Erfüllung der GSPR belegen (z.B. Tests zur Datenverschlüsselung, Überprüfung der Datenkorrektheit bei der Übertragung, Usability-Validierungstests).

Freigabeprozess

Ist ein Prozess zur Freigabe der Software definiert, der die Kriterien für die Freigabe und die erforderlichen Überprüfungen festlegt?

Referenz: IEC 62304 Clause 5.8.1.

Prüfhinweis: Der Prozess sollte die Beteiligung relevanter Parteien (z.B. Risikomanagement, klinische Bewertung) sicherstellen.

Freigabe-Dokumentation

Ist die Freigabe der Software dokumentiert und nachvollziehbar?

Referenz: IEC 62304 Clause 5.8.2.

Prüfhinweis: Ein formelles Freigabeprotokoll, das die erfolgreich abgeschlossenen Tests und die abschließende Risikobewertung bestätigt, muss vorhanden sein.

Software-Wartungsplan

Existiert ein Plan für die Wartung der Software nach der Inverkehrbringung?

Referenz: IEC 62304 Clause 6.1.

Prüfhinweis: Der Plan sollte Verantwortlichkeiten, Prozesse für Fehlerbehebung, Updates, Upgrades und die Bereitstellung von Sicherheits-Patches umfassen. Dies ist eng mit dem PMS-Plan verbunden.

Formalisierter Problemlösungsprozess

Ist ein formalisierter Problemlösungsprozess für Softwarefehler definiert und implementiert?

Referenz: IEC 62304 Clause 8.

Prüfhinweis: Dieser Prozess sollte die folgenden Schritte umfassen:

• Fehlererkennung und -meldung (IEC 62304 Clause 8.1): Prozess zur Erfassung von Softwarefehlern (intern und Post-Market).
• Analyse von Problemen (IEC 62304 Clause 8.2): Prozess zur Analyse der Ursachen von Softwareproblemen, einschließlich Root-Cause-Analyse.
• Fehlerbehebung und -verifizierung (IEC 62304 Clause 8.3): Prozess zur Behebung und Verifizierung der Fehlerbehebung, einschließlich notwendiger Regressionstests.

Rückmeldungsmechanismen (PMS)

Sind Prozesse für die Sammlung und Analyse von Rückmeldungen nach dem Inverkehrbringen (Post-Market Surveillance, PMS) etabliert, die auch Softwarefehler und Cybersicherheitsvorfälle einschließen?

Referenz: MDR Artikel 83, 87, 88.

Prüfhinweis: Die Integration der Software-PMS in das Gesamtsystem des Herstellers ist entscheidend. Dies beinhaltet die Überwachung von Datenbanken für Cybersicherheitslücken (z.B. CVEs) und die Analyse von Felddaten zu Softwareproblemen.

Prozess für Software-Änderungen

Ist ein definierter Prozess für die Verwaltung von Änderungen an der Software etabliert?

Referenz: IEC 62304 Clause 6.2, 6.3, 6.4, MDR Anhang II Absatz 4.9.

Prüfhinweis: Der Prozess muss die Bewertung der Auswirkungen der Änderung auf die Risikobewertung, die Klassifizierung und die regulatorische Konformität umfassen. Es muss klar sein, wann eine Notifizierung der Benannten Stelle erforderlich ist.

Risikobewertung von Änderungen

Wird bei jeder Software-Änderung eine Risikobewertung durchgeführt, um neue oder geänderte Risiken zu identifizieren und zu beherrschen?

Referenz: IEC 62304 Clause 7.6.

Prüfhinweis: Nachweis der Aktualisierung der Risikomanagementakte und der Entscheidung über die Notwendigkeit weiterer Tests.

Verifizierung und Validierung von Änderungen

Werden Software-Änderungen angemessen verifiziert und validiert (z.B. durch Regressionstests), um sicherzustellen, dass die geänderte Software weiterhin die Anforderungen erfüllt und keine neuen Fehler eingeführt wurden?

Referenz: IEC 62304 Clause 6.3.

Prüfhinweis: Die Teststrategie für Änderungen muss umfassend sein und alle potenziell betroffenen Bereiche abdecken.

Konfigurationsmanagement

Ist ein Konfigurationsmanagement-System für die Software (Quellcode, ausführbare Dateien, Dokumentation, Testfälle) implementiert, das die Identifikation, Versionskontrolle und Kontrolle der Software-Assets ermöglicht?

Referenz: IEC 62304 Clause 9.

Prüfhinweis: Nachweis der Versionskontrolle, des Release-Managements und der Fähigkeit, frühere Versionen bei Bedarf wiederherzustellen.

Plan für Außerbetriebnahme

Ist ein Plan für die geordnete Außerbetriebnahme der Software vorhanden?

Referenz: MDR Anhang I Absatz 14.1.

Prüfhinweis: Umgang mit Restrisiken, Datenmigration, Bereitstellung von Support während der Außerbetriebnahmephase und Entsorgung der Software.

Vollständigkeit der Software-Dokumentation

Ist die Software-Dokumentation vollständig und konsistent mit den Anforderungen der IEC 62304 und der MDR?

Referenz: MDR Anhang II Absatz 4.

Prüfhinweis: Alle geforderten "Work Products" (Pläne, Spezifikationen, Berichte, Testergebnisse, Freigabedokumente, Problemlösungsberichte, Konfigurationsmanagement-Aufzeichnungen) müssen vorhanden und nachvollziehbar sein.

Klare Darstellung der Architektur

Ist eine klare Darstellung der Software-Architektur, ihrer Subsysteme und der Schnittstellen (intern und extern zum Device) vorhanden?

Referenz: MDR Anhang II Absatz 4.9.

Prüfhinweis: Dies ist entscheidend für das Verständnis der Software, ihrer Interaktionen mit dem physischen Medizinprodukt und anderen Systemen (z.B. KIS, PACS). Diagramme und Beschreibungen sollten übersichtlich sein.

Funktionale und nicht-funktionale Beschreibung

Sind die funktionalen und nicht-funktionalen Anforderungen, Leistungsmerkmale und die bestimmungsgemäße Verwendung der Software klar beschrieben?

Referenz: MDR Anhang II Absatz 4.1.

Prüfhinweis: Die Beschreibung muss der Zweckbestimmung des Produkts entsprechen und alle relevanten Funktionen des Geräts, die durch die Software realisiert werden, umfassen.

Erfüllung aller relevanten GSPR (Software-bezogen)

Sind alle relevanten GSPR des Anhangs I der MDR bezüglich Software nachweislich erfüllt?

Referenz: MDR Anhang I.

Prüfhinweis: Überprüfen Sie Verweise auf entsprechende Testberichte, Risikoanalysen, Usability-Reports und andere Nachweise, die die Konformität belegen. Besonderes Augenmerk liegt auf:
- GSPR 14.1/14.2: Design für Gebrauchstauglichkeit (IEC 62366-1).
- GSPR 17: Cybersicherheit (MDCG 2019-16).
- GSPR 21/22: Kompatibilität und Interoperabilität.
- GSPR 23.4: Schutz der Daten und deren Integrität.

Software-spezifische Informationen

Sind alle notwendigen Informationen zur Software in der Kennzeichnung und Gebrauchsanweisung enthalten?

Referenz: MDR Anhang I Kapitel III, Anhang II Absatz 4.6.

Prüfhinweis: Überprüfung auf Vollständigkeit und Verständlichkeit für den Anwender. Dies beinhaltet: Software-Version, minimale Hardware-/Systemanforderungen, Hinweise zur Cybersicherheit, Interoperabilität, Warnungen, Installationsanweisungen etc.

Kohärenz der Dokumente

Ist die gesamte technische Dokumentation (Risikomanagementakte, klinische/Leistungsbewertung, Gebrauchstauglichkeit, Software-Dokumentation) kohärent und widerspruchsfrei?

Prüfhinweis: Querverweise zwischen den Dokumenten müssen nachvollziehbar sein. Informationen sollten nicht redundant und widersprüchlich sein. Achten Sie auf eine plausible Darstellung der Software im Kontext des gesamten Medizinprodukts.

Umfassende Rückverfolgbarkeit

Ist die Rückverfolgbarkeit von den GSPR über die Anforderungen, das Design, die Implementierung und die Tests bis zur Risikomanagementakte gegeben und belegt die Konformität mit der MDR?

Prüfhinweis: Eine konsolidierte Traceability-Matrix oder ein vergleichbares System, das die durchgängige Erfüllung der GSPR durch die Software belegt, ist hier ausschlaggebend.

Plausibilitätscheck bezogen auf das Device

Sind die Software-Prozesse und die resultierende Software-Dokumentation plausibel im Kontext des spezifischen Medizinprodukts und seiner Zweckbestimmung?

Prüfhinweis: Eine Software, die ein lebenserhaltendes Gerät steuert, erfordert einen höheren Detailgrad und strengere Kontrollen als eine Software für ein reines Diagnosegerät. Die Komplexität des Softwaresystems muss zum Risiko des Produkts passen.

Verweis auf klinische/Leistungsbewertung

Wurden die Ergebnisse der Software-Verifizierung und -Validierung in die klinische Bewertung / Leistungsbewertung einbezogen?

Referenz: MDR Artikel 61, Anhang XIV; IVDR Artikel 56, Anhang XIII, MDCG 2020-1.

Prüfhinweis: Insbesondere bei Software as a Medical Device (SaMD) ist die klinische Bewertung von großer Bedeutung und muss die Softwareleistung und -sicherheit direkt adressieren.

Post-Market Surveillance Plan

Ist die Software in den Post-Market Surveillance (PMS) Plan integriert, um Softwarefehler, Cybersicherheitsbedrohungen und andere unerwünschte Ereignisse systematisch zu erfassen?

Referenz: MDR Artikel 84, Anhang III.

Prüfhinweis: Der PMS-Plan sollte spezifische Maßnahmen für Software umfassen, wie z.B. das Monitoring von Software-Logs, das Management von Cybersecurity-Vorfällen und die regelmäßige Aktualisierung der Software-Risikomanagementakte.