Design Verification von Medizinprodukten und standalone Software

Montag 19. Oktober 2015

Die Forderung nach „Design Verification“ erhebt keinesfalls nur die FDA. Dieser Beitrag beschreibt, was unter „Design Verification“ zu verstehen ist und welche regulatorischen Forderungen Sie als Medizinproduktehersteller erfüllen sollten.

Definition des Begriffs Design Verification

Im Gegensatz zur „Design Validation“ definiert die FDA den Begriff „Design Verification“ nicht explizit. Allerdings definiert sie „Verification“ als means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled.

Das entspricht der Definition der ISO 9000, die unter der Verifizierung eine Prüfung mit objektiven Mitteln versteht, ob spezifizierte Eigenschaften bzw. Anforderungen erfüllt sind.

Solche spezifzierten Eigenschaften können von Produkten aber ebenso von Dokumenten, Komponenten oder Prozessen verlangt werden. Bei der Design Verification betreffen diese Spezifikationen das Produkt d.h. sie entsprechen der System Requirements Specification.

Regulatorische Anforderungen an die Design Verification

Anforderungen der FDA

Die FDA fordert im 21 CFR part 820.30(f) Folgendes:

Each manufacturer shall establish and maintain procedures for verifying the device design. Design verification shall confirm that the design output meets the design input requirements. The results of the design verification, including identification of the design, method(s), the date, and the individual(s) performing the verification, shall be documented in the DHF.

Wie in einem Artikel zum Design Input geschrieben entspricht dieser den Systemanforderungen (System Requirements Specification).

Anforderungen der ISO 13485

Sehr analog fordert auch die ISO 13485 in Kapitel 7.3.5 („Entwicklungsverifizierung“), dass die Entwicklungsergebnisse die Entwicklungsvorgaben erfüllen und dass diese Verifizierung natürlich auch dokumentiert wird. Zu den Entwicklungsvorgaben zählt die ISO 13485 auch „Funktions-, Leistungs- und Sicherheitsanforederungen“, welche auch auf der Ebene der System Requirements Specification anzusiedeln sind. Allerdings nennt die ISO 13485 auch gesetzliche Anforderungen, die den Stakeholder-Anforderungen zuzurechnen sind. Eine Prüfung von Stakeholder-Anforderungen wäre eher eine Validierung…

Praktische Umsetzung

Nun stellt sich die Frage, was bei der Design Verification genau zu tun ist und welche Dokumente und Aktivitäten dazuzählen. Dies möchte ich am Beispiel von Software beschreiben.

Bei stand-alone Software

Wie oben beschreiben, verlangen die Regularien, dass die Design Verification (Entwicklungsverifizierung) sicherstellt, dass die Entwicklungsvorgaben wie die System Requriements Specification erfüllt ist.

Das bedeutet dass die Design Verification zumindest die Überprüfung dieser System Requirements Specification beinhaltet. Das entspricht dem Software-System-Test.

Die Design Verification bei Software muss zumindest den Software-Systemtest umfassen

Häufig gelingt es aber nicht mit ausreichender „Gewissheit“, die korrekte Umsetzung der System-/Software-Anforderungen nur auf Systemebene zu prüfen. Genau deshalb zählen die Tests auf den niedrigeren Teststufen ebenso zu Design Verification.

Streng genommen haben auch die Reviews der Software-Architektur zum Ziel zu prüfen, ob die gewählte Planung/Architektur geeignet ist, die „Design Inputs“ (Software Requirements) zu erfüllen.

In Summe können wir festhalten: Die Design Verification bei standalone Software umfasst

  • immer die Software-Systemtests
  • idealerweise auch die Integrations- und Unittests (und statischen Prüfungen des Quellcodes)
  • sowie die Reviews der Software-Architektur.

 

War dieser Artikel hilfreich? Bitte bewerten Sie:
1 Stern2 Sterne3 Sterne4 Sterne5 Sterne

Kategorien: FDA Zulassung - die U.S. Food and Drug Administration, Regulatory Affairs, Software & IEC 62304

Kommentar schreiben