Die Forderung nach „Design Verification“ erhebt keinesfalls nur die FDA. Dieser Beitrag beschreibt, was unter „Design Verification“ zu verstehen ist und welche regulatorischen Forderungen Medizinproduktehersteller erfüllen sollten.
1. Design Verification in Kürze
Design Verification ist die Überprüfung, ob die Entwicklungsergebnisse (Design Output z.B. Entwurfsdokumente in Form von Konstruktionszeichnungen) die im Design Input enthaltenen Anforderungen Inputs erfüllen.
Weil diese Überprüfungen nicht nur die Dokumente benötigt, sondern auch das Produkt, sollte die Design Verification stattfinden während der
- konstruktiven Phasen (links im V-Modell) beispielsweise in Form von Reviews und
- analytischen Phasen (rechts in V-Modell) typischerweise in Form von Tests.
Anmerkungen:
- Die Normen unterscheiden teilweise Stakeholer- und Produktanforderungen nicht präzise und zählen daher gesetzliche Anforderungen (Stakeholder-Anforderungen) zum Design-Input, obwohl die Überprüfung der Stakeholder-Anforderungen eine Validierungsaktivität darstellt.
- Entwicklungsergebnisse in Form von (Architektur-)Dokumenten entstehen oft im Rahmen mehrerer Entwicklungsaktivitäten und -phasen. Daher kann es mehrere Verifizierungen dieser Ergebnisse geben.
- Die abschließende Überprüfung, ob die Design Inputs in Form von Produktanforderungen erfüllt sind, gelingt erst auf Produktebene (in Abb. 1 als „Product System Test“ bezeichnet).
Die Herleitung und Diskussion findet sich im dritten Abschnitt dieses Artikels, häufige Missverständnisse im vierten Abschnitt.
2. Regulatorische Anforderungen
Anforderungen der FDA an die Design Validation
Die FDA fordert im 21 CFR part 820.30(f) Folgendes:
Design verification. 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.
Die bei einer Verifizierung zu überprüfenden „spezifizierten Eigenschaften bzw. Anforderungen“ beziehen sich somit bei der Design Verification auf den Design Input. Diesen Design Input beschreibt die FDA ebenfalls:
Design input. Each manufacturer shall establish and maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. The procedures shall include a mechanism for addressing incomplete, ambiguous, or conflicting requirements. The design input requirements shall be documented and shall be reviewed and approved by a designated individual(s). The approval, including the date and signature of the individual(s) approving the requirements, shall be documented.
FDA 21 CFR pat 820.30 (c)
Wie in einem Artikel zum Design Input geschrieben entspricht dieser vor allem den Produkt-/Systemanforderungen (Product/System Requirements Specification).
Anforderungen der ISO 13485 an die Entwicklungsverifizierung
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.
3. Herleitung
a) Definitionen
Im Gegensatz zur „Design Validation“ definiert die FDA den Begriff „Design Verification“ nicht explizit. Allerdings definiert sie „Verification“.
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.
Gemäß 21 CFR part 820.3 und ISO 13485 entspricht die Design Verification den (geplanten) Aktivitäten, um den Design-Output zu überprüfen (verifizieren), ob er den Anforderungen des Design Inputs entspricht. Um das genauer zu verstehen, müssen mehrere Fragen geklärt werden:
- Was ist der Design Input?
- Was ist das Design und was sind die Design Outputs?
- Wie sollen Hersteller das Design verifizieren?
Antworten liefern die folgenden Abschnitte.
b) Design Inputs
Die Design Inputs sind in der Regel die Produktanforderungen, konkret Anforderungen an die Funktionalität, Leistungsfähigkeit, Gebrauchstauglichkeit und Sicherheit des Produkts. Wie oben dargelegt, zählt die ISO 13485 auch regulatorische Anforderungen zu den Design Inputs.
Regulatorische Anforderungen sind Stakeholder-Anforderungen. Allerdings stellen einige regulatorische Anforderungen konkrete Anforderungen ans Produkt, so dass für diese Anforderungen die Hersteller diese Stakeholder-Anforderungen nicht in Produktanforderungen überführen müssen.
- Beispiel: Die IEC 60601-1 legt die maximalen Ableitströme eines PEMS fest. Das ist eine (überprüfbare) Produktanforderung.
- Gegenbeispiel: Die IEC 62366-1 fordert, dass die Hersteller die Risiken durch Nutzungsfehler minimieren. Diese Anforderung müssen die Hersteller in konkrete (und überprüfbare) Anforderungen an das User Interface überführen.
Der „Practical Guide“ zur ISO 13485 nennt als weitere Elemente des Design Inputs:
- Erfahrungen aus ähnlichen Produkten
- „Benchmarking Results“
- Ergebnisse von Marktumfragen
- Anforderungen an die Verpackung
- Normen
c) Design & Design Outputs
Das Design ist der Entwurf des Produkts. Diese Entwurfstätigkeiten münden in vielerlei Artefakten:
- Konstruktionszeichnungen
- Bauteil-Listen, Komponentenspezifikationen
- Vorgaben für die Produktion einschließlich Produktprüfungen (z.B. Prozesse, Materialien, Werkzeuge)
- Software
- Gebrauchsanweisung, Installation- und Serviceanweisungen
Der Practical Guide zählt das Produkt nicht explizit zum Design Output, es sei den es ist eine Software as Medical Device.
d) Design Verification
Die ISO 13485 fordert zwei Überprüfungen:
- Laut Kapitel 7.3.4 sollen die Design Outputs (geprüft und) freigegeben werden, ob sie für die Design Verification geeignet („suitable“) sind.
- Im Kapitel 7.3.6 fordert die Norm die „Design and Development Verification“. Ähnlich wie die FDA im 21 CFR part 820.30 müssen die Hersteller überprüfen, ob die Design Output die Anforderungen des Design Inputs erfüllen.
Der Zeitpunkt und die Art (Methoden) der zweiten Überprüfung (Design and Development Verification) hängt vom überprüften Gegenstand ab:
- Dokumente
Einige Design Outputs in Form von Dokumenten (wie Konstruktionszeichnungen) können direkt nach deren Erstellung überprüft werden. Beispielsweise kann eine Systemarchitektur überprüft werden, ob sie die in den Produktanforderungen (Design Input) spezifizierten Schnittstellen bedienen kann. - Produkt, Komponenten
Andere Design Outputs lassen sich nur am Produkt oder dessen Komponenten überprüfen. Beispielsweise lässt sich die Performance eines Produkts nur am Produkt selbst nachweisen.
Abhängig von der Art dieser Überprüfung kommen bei der Design Verification unterschiedliche Methoden zum Einsatz:
- Dokumente: Reviews, Checklisten, …
- Produkt, Komponenten: (Bench)Tests wie beispielsweise Funktionstests, Lasttests, Simulationen, EMV-Prüfungen, Inspektionen und Methoden der formativen Evaluation wie Cognitive Walkthrough, heuristische Evaluation
4. Praktische Umsetzung
a) Missverständnisse vermeiden
Häufig nehmen Hersteller Bezug auf ein Modell der FDA (s. Abb. 2).
Dieses Schaubild lässt sich allerdings in mehrfacher Sicht missverstehen:
- Die Design Verification erfolgt zwar anhand des Design Outputs, aber nicht notwendigerweise (nur) am Ende des Entwicklungsprozesses. Dieser Prozess ist zudem meist nicht linear.
- Das Diagramm unterscheidet Tätigkeiten und Artefakte nicht präzise. Beispielsweise umfasst der „Design Process“ Tätigkeiten. Der „Design Output“ sind aber Artefakte wie Dokumente und Produkte.
- Es wirkt, als diene das Review der Überprüfung der Aktivitäten oder Artefakte. Dabei gilt allerdings zwischen einem „Design Review“ zu unterscheiden und einer Überprüfung von Zwischenergebnisse. Beides ist nicht deckungsgleich wie der Artikel „Design Review ungleich Review des Designs beschriebt.
- Es gibt keine gesetzliche Forderung, ein „Design Review“ bei den jeweiligen Aktivitäten durchzuführen.
- Ein Review ist nur eine von mehren möglichen Methode, um Zwischen- und Endergebnisse zu überprüfen.
Nicht jede Überprüfung der Design Outputs ist eine Design Verification. Eine Design Verifizierung muss als Ziel haben, die Erfüllung der „Design-Input-Anforderungen“ zu prüfen. Eine Überprüfung anhand der Design Outputs, ob der Design-Prozess eingehalten wurde, wäre eher ein Design Review im Sinn der ISO 13485.
b) Beispiel Software
Wie oben beschreiben, verlangen die Regularien, dass die Design Verification (Entwicklungsverifizierung) sicherstellt, dass die Entwicklungseingaben 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 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 Überprüfungen der Software-Architektur zum Ziel zu prüfen, ob die gewählte Planung/Architektur geeignet ist, die „Design Inputs“ (Software Requirements) zu erfüllen.
Die IEC 62304 spricht explizit von einer Verifizierung der Software-Architektur und nicht einem Review der Architektur. Denn ein Review ist nur eine Möglichkeit für diese Überprüfung. Andere Möglichkeiten umfassen das Überprüfen von Prototypen, die Bestimmung von Abhängigkeitsmetriken und das Nutzen von Checklisten.
In Summe lässt sich festhalten: Die Design Verification bei einer standalone Software umfasst
- immer die Software-Systemtests
- idealerweise auch die Integrations- und Unittests (und statischen Prüfungen des Quellcodes)
- sowie die Verifizierung der Software-Architektur.
5. Fazit und Zusammenfassung
Ähnlich missverstanden wie der Begriff Design Review ist die Design Verification. Dazu tragen auch regulatorische Vorgaben bei, die keinem erkennbaren und weltweit abgestimmten mentalen Modell folgen.
Dieser Artikel hat versucht, dieses Modell zu liefern.
Beachten Sie auch den Artikel zur Design Validation.
Änderungshistorie
- 2024-13-04: Artikel fast vollständig neu geschrieben
- 2015-10-15: Artikel erstmalige veröffentlicht
