| Inhaltsübersicht |
|---|
| Definition » |
| Regulatorische Anforderungen » |
| Praktische Umsetzung » |
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 Sicherheitsanforderungen“, 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.
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.
