Fachwissen für digitale Entscheidungen
Wie plant man Verifikation und Validierung nach IEC 62304?
Kurzantwort
Prüfungen aus Risiko und Zweckbestimmung ableiten
IEC 62304:2006+A1:2015 definiert Prozesse, Aktivitäten und Aufgaben für Entwicklung und Wartung von Medizinsoftware. Ein Prüfplan beginnt deshalb nicht mit einer Liste technischer Testarten, sondern mit Zweckbestimmung, Softwareanforderungen, Architektur und Risikoakte. Jede sicherheitsrelevante Anforderung braucht einen nachvollziehbaren Nachweis; umgekehrt muss jeder Test erkennen lassen, welche Anforderung oder Risikokontrolle er prüft.
Die Norm unterscheidet die Software-Sicherheitsklassen A, B und C nach dem möglichen Schaden, zu dem ein Versagen beitragen kann. Vereinfacht steht A für keinen möglichen Gesundheitsschaden, B für möglichen nicht schwerwiegenden Schaden und C für möglichen Tod oder schwerwiegende Verletzung. Die Einstufung bestimmt die Tiefe der geforderten Aktivitäten, ersetzt aber nicht die MDR-Risikoklasse des Produkts. Beide Klassifikationen beantworten unterschiedliche Fragen.
Verifikation auf mehreren Ebenen
Ein belastbarer Plan deckt die Schritte des Softwarelebenszyklus ab:
- Anforderungen auf Eindeutigkeit, Widerspruchsfreiheit und Prüfbarkeit kontrollieren,
- Architektur und detailliertes Design gegen Anforderungen und Risikokontrollen prüfen,
- Softwareeinheiten implementieren und entsprechend ihrer Kritikalität verifizieren,
- Einheiten integrieren und Schnittstellen, Datenflüsse sowie Fehlerbehandlung testen,
- das Softwaresystem gegen die freigegebenen Anforderungen prüfen,
- offene Anomalien bewerten, Konfiguration dokumentieren und eine reproduzierbare Version freigeben.
Zu den Testarten können Unit-, Integrations-, System- und Regressionstests gehören. Für Medizinsoftware kommen je nach Produkt Grenzwert- und Fehlereinspeisungstests, Datenintegrität, Rollen und Rechte, Zeitverhalten, Kompatibilität, Installation, Update und sichere Rückfallebenen hinzu. Risikokontrollen müssen nicht nur vorhanden sein; ihre Wirksamkeit ist zu verifizieren.
Validierung umfasst das fertige Produkt
Verifikation beantwortet, ob ein Entwicklungsergebnis seine spezifizierten Anforderungen erfüllt. Validierung beantwortet, ob das fertige Produkt in der vorgesehenen Nutzung die Zweckbestimmung und Nutzerbedürfnisse erfüllt. Die IEC weist ausdrücklich darauf hin, dass sie die abschließende Validierung und Freigabe des Medizinprodukts nicht vollständig abdeckt – auch dann nicht, wenn das Produkt ausschließlich aus Software besteht. Dafür sind zusätzlich MDR-Anhang II Nummer 6, Gebrauchstauglichkeit nach IEC 62366-1 und klinische Bewertung zu berücksichtigen.
Freigabe mit objektiven Kriterien
Vor jedem Release sollten Testumfang, akzeptierte Restabweichungen, Rückverfolgbarkeit, Risikoauswirkung, bekannte Anomalien, Konfigurationsbaseline und Verantwortliche dokumentiert sein. Änderungen lösen eine begründete Auswahl von Regressionstests aus; eine pauschale Wiederholung aller Tests ist ebenso wenig belastbar wie Tests ohne dokumentierte Auswahl. Der Plan bleibt damit risikobasiert, versionsbezogen und auditierbar.
Beispiel aus der Praxis
Bei einer Alarmberechnung verweist die Risikokontrolle auf eine Softwareanforderung, diese auf Architektur und Testfälle. Neben korrekten Fällen werden fehlende, verspätete und widersprüchliche Eingangsdaten geprüft.
Kernfakten
- Normausgabe
- IEC 62304:2006+A1:2015
- Software-Sicherheitsklassen
- A, B und C
- MDR-Nachweis
- Anhang II Nummer 6
- Wichtige Abgrenzung
- IEC 62304 deckt nicht allein die finale Produktvalidierung ab
Quellen
Alle externen Angaben nachvollziehbar belegt.-
01
IEC 62304:2006+A1:2015 – Medical device software life cycle processes International Electrotechnical Commission (IEC)
-
02
Verordnung (EU) 2017/745, Anhang II Nummer 6 EUR-Lex / Europäische Union
-
03
ISO 14971:2019 – Risk management for medical devices International Organization for Standardization (ISO)