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 erfüllen.
Weil diese Überprüfungen nicht nur die Dokumente benötigen, sondern auch das Produkt, sollte die Design Verification stattfinden während der
- konstruktiven Phasen (links im V-Modell), beispielsweise in Form von Reviews, und der
- analytischen Phasen (rechts im V-Modell), typischerweise in Form von Tests.
Anmerkungen:
- Teilweise unterscheiden die Normen Stakeholder- 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 der Design Input in Form von Produktanforderungen erfüllt ist, gelingt erst auf Produktebene (in Abb. 1 als „product system test“ bezeichnet).
Herleitung und Diskussion finden sich im dritten Abschnitt dieses Artikels. Auf häufige Missverständnisse geht der vierte Abschnitt ein.
2. Regulatorische Anforderungen
Anforderungen der FDA an die Design Verification
Die FDA fordert in 21 CFR part 820.30(f):
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 part 820.30 (c)
Wie in diesem Beitrag zum Design Input geschrieben, entspricht dieser vor allem den Produkt-/Systemanforderungen (Product/System Requirements Specification).
Anforderungen der ISO 13485 an die Entwicklungsverifizierung
Analog fordert auch die ISO 13485 in Kapitel 7.3.5 „Entwicklungsverifizierung“, dass die Entwicklungsergebnisse die Entwicklungsvorgaben erfüllen und diese Verifizierung dokumentiert wird. Zu den Entwicklungsvorgaben zählt die ISO 13485 auch „Funktions-, Leistungs- und Sicherheitsanforderungen“, welche ebenfalls 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) in Hinblick darauf, 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?
Die folgenden Abschnitte geben Antworten auf diese Fragen.
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. Einige regulatorische Anforderungen stellen allerdings so konkrete Anforderungen an das Produkt, dass 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. Die Entwurfstätigkeit mündet in vielerlei Artefakten (Design Output):
- Konstruktionszeichnungen
- Bauteil-Listen, Komponentenspezifikationen
- Vorgaben für die Produktion, einschließlich Produktprüfungen (z. B. Prozesse, Materialien, Werkzeuge)
- Software
- Gebrauchsanweisung, Installations- und Serviceanweisungen
Der Practical Guide zählt das Medizinprodukt selbst explizit zum Design Output.
d) Design Verification
Die ISO 13485 fordert zwei Überprüfungen:
- Laut Kapitel 7.3.4 sollen die Elemente des 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 bei FDA 21 CFR part 820.30 müssen die Hersteller überprüfen, ob der Design Output die Anforderungen des Design Inputs erfüllt.
Der Zeitpunkt und die Art (Methoden) der zweiten Überprüfung (Design and Development Verification) hängen vom überprüften Gegenstand ab:
- Dokumente
Einige Design Outputs können direkt nach deren Erstellung überprüft werden, etwa Dokumente wie Konstruktionszeichnungen. Auch kann geprüft werden, ob die Systemarchitektur 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 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 nichtlinear.
- Das Diagramm unterscheidet Tätigkeiten und Artefakte nicht präzise. Beispielsweise umfasst der „Design Process“ Tätigkeiten. Den „Design Output“ bilden aber Artefakte wie Dokumente und Produkte.
- Es wirkt, als diene der Review der Überprüfung der Aktivitäten oder Artefakte. Dabei gilt es zu unterscheiden zwischen einem „Design Review“ und einer Überprüfung von Zwischenergebnissen. Diese Methoden sind nicht deckungsgleich, wie der Beitrag Design Review ungleich Review des Designs darlegt.
- Es gibt keine gesetzliche Forderung, ein „Design Review“ bei den jeweiligen Aktivitäten durchzuführen.
- Ein Review ist nur eine von mehreren möglichen Methoden, um Zwischen- und Endergebnisse zu überprüfen.
Nicht jede Überprüfung des Design Outputs ist eine Design Verification. Eine Design-Verifizierung muss als Ziel haben, die Erfüllung der „Design-Input-Anforderungen“ zu prüfen. Die Ü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
Die Regularien verlangen, dass die Design Verification (Entwicklungsverifizierung) sicherstellt, dass Entwicklungseingaben wie die System Requirements Specification erfüllt sind.
Die Design Verification muss folglich zumindest die Überprüfung dieser System Requirements Specification beinhalten. 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. Deshalb zählen auch die Tests auf den niedrigeren Teststufen zur Design Verification.
Streng genommen stellen auch die Überprüfungen der Software-Architektur sicher, 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 von einem Review der Architektur. Denn ein Review ist nur eine von vielen Möglichkeiten für diese Überprüfung. Andere umfassen das Überprüfen von Prototypen, die Bestimmung von Abhängigkeitsmetriken und das Nutzen von Checklisten.
Es kann festgehalten werden: 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-12-05: Artikel fast vollständig neu geschrieben
- 2015-10-15: Artikel erstmalig veröffentlicht
