Wie unterscheiden sich Verifizierung und Validierung und wie sind diese Begriffe definiert? Selbst Normen und Gesetze verwenden die Begriffe falsch oder missverständlich.
Erfahren Sie hier, wie Sie Ihre Medizinprodukte sicher durch Zulassungen und Audits bekommen – dank präziser Verifizierung und Validierung.
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
Eine sehr ausführliche Darstellung des Themas Verifizierung und Validierung finden Sie in unserer Publikation „Validation of artificial intelligence containing products across the regulated healthcare industries“. Wir stellen das Konzept der Validierung in verschiedenen Kontexten vor: KI, Software-Validierung, Validierung von Medizinprodukten, Validierung im pharmazeutischen Kontext.
Den kostenfreien Preprint finden Sie bei arxiv.org.
1. Verifizierung
a) Definition
„Bestätigung durch Bereitstellung eines objektiven Nachweises […], dass festgelegte Anforderungen […] erfüllt worden sind“.
ISO 9000
Diese Definition erklärt nicht, welche „Anforderungen“ durch die Verifizierung bestätigt werden muss. Um Unklarheiten und Verwechslungen mit Stakeholder-Anforderungen zu vermeiden, empfiehlt es sich, die Anforderungen auf solche an Produkte oder Komponenten einzugrenzen.
„Die Verifizierung ist eine Prüfung mit objektiven Mitteln, dass spezifizierte Eigenschaften (z. B. von Produkten, Komponenten) erfüllt sind“.
ISO 9000
Diese Eigenschaften oder Merkmale sind beispielsweise in einer System Requirements Specification (SRS) oder in den Komponentenanforderungen spezifiziert.
b) Beispiele
Beispiele für spezifizierte Merkmale sind:
- Spezifikation der Benutzerschnittstelle z.B. mit Mockups oder Zeichnung (siehe nächstes Kapitel)
- Verhalten des Systems an den Datenschnittstellen (u. a. Interoperabilität)
- Verhalten des Systems an „Patientenschnittstellen“ (Anwendungsteil): So könnte spezifiziert sein, dass an einem Defibrillator eine gewisse Spannung in einer bestimmten Pulsfolge anliegen muss. Die Verifizierung wäre dann die Prüfung, ob diese Spannung in der spezifizierten Pulsfolge tatsächlich anliegt.
c) Sonderfall: Verifizierung im Kontext der Gebrauchstauglichkeit
Die Verifizierung der Gebrauchstauglichkeit ist der objektive Nachweis, dass spezifizierte Produktmerkmale mit Bezug auf die Gebrauchstauglichkeit erfüllt sind. Sie ist also eine Untermenge der Verifizierung und wird von der IEC 62366 gefordert.
Beispiele für spezifizierte Produktmerkmale sind Schriftgrößen, Farben, Kontrastverhältnisse oder allgemeine Regeln wie das Markieren von Pflichtfeldern. Diese Prüfung (Verifizierung) erfolgt beispielsweise in Form von Inspektionen durch Usability-Experten. Diese prüfen anhand von
- spezifizierten Produktmerkmalen (z. B. wie in einem Styleguide oder in einem UI-Mockup beschrieben) oder/und
- allgemeinen Regeln, wie sie etwa die ISO 9241-Familie sehr umfassend beschreibt.
Möchten Sie mehr über die Verfahren zur Verifizierung und Validierung der Gebrauchstauglichkeit erfahren? Dann empfehlen wir Ihnen das Seminar „Usability & Requirements“ von Thomas Geis.
2. Validierung
a) Definition
„Bestätigung durch Bereitstellung eines objektiven Nachweises […], dass die Anforderungen […] für einen spezifischen beabsichtigten Gebrauch oder eine spezifische beabsichtigte Anwendung erfüllt worden sind“.
ISO 9000
Ob diese Anforderungen für einen bestimmten Gebrauch erfüllt sind, hängt u. a. von den Nutzern (Anwendern) und dem Nutzungskontext ab. Beispielsweise können die Anforderungen an einen Defibrillator in einem OP-Setting mit professionellen Anwendern erfüllt sein, bei der Anwendung durch Laien auf einer regennassen Straße in der Nacht aber nicht.
Daher ließe sich die Definition des Begriffs Validierung auch erweitern:
„Bestätigung durch objektiven Nachweis, dass von den spezifizierten Nutzern im spezifizierten Nutzungskontext die spezifizierten Nutzungsziele (Zweckbestimmung) erreicht werden können“
Johner Institut angelehnt an IEC 62366-1
b) Beispiele
Damit ist die Validierung der objektive Nachweis, dass ein spezifizierter Nutzer im spezifizierten Nutzungskontext seine spezifizierten Nutzungsziele erreichen kann. Diese Prüfung hat zwei Aspekte:
- Klassische Validierung: Das ist die Prüfung, ob man mit dem Medizinprodukt das Nutzungsziel überhaupt erreichen kann.
Die klinische Bewertung ist ein Beispiel für eine solche Validierung. Für In-vitro-Diagnostika führt man eine klinische Leistungsbewertung durch.
Die Nutzungsziele finden sich in der Zweckbestimmung beschrieben.
Die klinische Bewertung bzw. Leistungsbewertung sind Teil der Validierung und müssen nachweisen, dass die Nutzungsziele erreicht werden, d. h., dass das Produkt sicher, leistungsfähig und wirksam ist. - Validierung der Gebrauchstauglichkeit: Das ist die Prüfung, ob die spezifizierten Nutzer im spezifizierten Nutzungskontext die Nutzungsziele (Zweckbestimmung) effektiv, effizient und zufriedenstellend erreichen können. Diese Prüfung erfolgt üblicherweise in Form einer summativen Evaluation (Usability Test).
3. Verifizierung und Validierung bei Software
a) Regulatorische Anforderungen
MDR und die IVDR fordern gleichlautend:
Bei Produkten, zu deren Bestandteilen Software gehört, oder bei Produkten in Form einer Software wird die Software entsprechend dem Stand der Technik entwickelt und hergestellt, wobei die Grundsätze des Software-Lebenszyklus, des Risikomanagements einschließlich der Informationssicherheit, der Verifizierung und der Validierung zu berücksichtigen sind.
MDR Anhang I Absatz 17.2.
b) Erfüllung der regulatorischen Anforderungen
Hersteller wenden üblicherweise die IEC 62304 an, um nachzuweisen, dass die Anforderungen an Verifizierung und Validierung nach Stand der Technik erfüllt sind. Allerdings adressiert die IEC 62304 explizit nur die Verifizierung und verweist bei der Validierung auf die IEC 82304-1.
Verifizierung
Die Verifizierung von Software erfolgt üblicherweise durch:
- Unit-Tests
- Integrationstests
- Software-Systemtests (s. auch Übersichtsartikel), bei denen auch Blackbox-Testverfahren zum Einsatz kommen
- Code-Reviews
- Statische Code-Analyse
Validierung
Die wichtigsten Methoden zur Validierung von (Standalone-)Software sind:
- Validierung der Gebrauchstauglichkeit (summative Evaluation), typischerweise durch Usability Tests
- Klinische Bewertung, welche ggf. klinische Prüfungen bedingen
Eine wertvolle Ergänzung liefert das Guidance-Dokument MDCG 2020-1. Eine Zusammenfassung davon finden Sie in unserem Fachartikel Klinische Bewertung von Software.
Der schnellste und kostengünstigste Weg Ihr Medizinprodukt auf den Markt zu bringen
Mit unseren Videotrainings und dutzenden Vorlagen erhalten Sie eine umfassende Anleitung zur Erhebung, Spezifikation und Prüfung der Anforderungen an Ihre Medizinprodukte. Die Schritt-für-Schritt-Anleitungen machen es Ihnen leicht, den Überblick zu behalten und alle notwendigen Schritte zu durchlaufen.
4. Typische Fallen
a) Verwechslung der verschiedenen „Validierungen“
Die alte Medizinprodukte-Richtlinie für Medizinprodukte, die “Medical Device Directive” (93/42/EWG), forderte:
“Bei Geräten, die Software enthalten oder bei denen es sich um medizinische Software an sich handelt, muss die Software entsprechend dem Stand der Technik validiert werden, wobei die Grundsätze des Software-Lebenszyklus, des Risikomanagements, der Validierung und Verifizierung zu berücksichtigen sind.”
um 2007/47/EC ergänzte MDD
Diese Anforderung verwendet den Begriff „Validierung“ bzw. „validiert“ in zwei unterschiedlichen Kontexten, die nicht verwechselt werden sollten:
Software-Validierung im engeren Sinn
Damit ist die oben beschriebene Validierung gemeint und als Abgrenzung zur Verifizierung zu verstehen. Sie prüft, ob die Zweckbestimmung erreicht und die Stakeholder-Anforderungen erfüllt werden.
Software-Validierung im weiteren Sinn
Diese Validierung entspricht dem, was die FDA im Guidance-Dokument „Software Validiation“ vorgibt. Hier wird der Begriff Software-Validierung synonym mit Software-Qualitätssicherung genutzt. Letztere umfasst die Lebenszyklusphasen:
- Erheben der Anforderungen
- Spezifikation der Software-Architektur und des Software-Designs
- Implementierung der Software
- Software-Testing (Unit-, Integrations- und Systemtests)
- Bei Standalone-Software auch die Validierung im engeren Sinn
Ein Beispiel für die Validerung von Software im weiteren Sinne ist die Computerized Systems Validation.
Lesen Sie hier mehr zum Thema Computerized Systems Validation (CSV) sowie in dem oben verlinkten „Springer-Paper“.
Data Scientists kennen eine Validierung von Machine-Learning-Modellen, die sich von den beiden genannten Validierungen unterscheidet. Mehr dazu erfahren Sie im oben verlinkten Video.
b) Verzicht auf die Verifizierung bei Sicherheitsklasse A
In der IEC 62304:2006 entschied die Software-Sicherheitsklasse über die Notwendigkeit von Software-Systemtests. Bei Sicherheitsklasse A waren keine Tests vorgeschrieben; weder Unit- noch Integrations- noch Systemtests und damit auch keine Verifizierung. Damit wäre die Software-Entwicklung nicht konform mit den Vorgaben der Medizinprodukte-Verordnung MDR.
Das Amendment I hat die IEC 62304 geändert: Diese besteht jetzt zumindest auf Software-Systemtests .
Laut ISO 14971 müssen alle Maßnahmen, die zur Risikokontrolle beitragen, verifiziert werden. Wenn Sie also Maßnahmen in Software implementieren, müssen Sie diese unabhängig von der Sicherheitsklasse einer Verifizierung unterziehen.
c) Verwechslung von Verifizierung und Validierung
Nicht nur in der Software-Entwicklung ist das V-Modell in vielen Köpfen verankert und wird sowohl von der IEC 62304 als auch der IEC 60601-1 referenziert.
Doch wie versteht die IEC 60601-1 dieses V-Modell?
Nach dieser Norm werden aus „Anwenderbedürfnissen“ Anforderungen an ein programmierbares elektrisches medizinisches System, kurz PEMS, abgeleitet; also Systemanforderungen (siehe Abbildung).
Zunächst muss man sich fragen, was die Norm unter „Anwenderbedürfnissen“ versteht. Dieser Begriff wird nicht definiert. Wahrscheinlich verstehen die Autoren darunter eine nicht näher spezifizierte Mischung aus Erfordernissen, Wünschen, Nutzungsanforderungen und direkt formulierten Systemanforderungen. Wer so unpräzise mit den Begriffen umgeht, wird später keine präzisen Ergebnisse erzielen.
Wohin diese mangelnde Präzision führt, erkennen Sie selbst: Die Norm glaubt, die Erfüllung von PEMS-Anforderungen, also Systemanforderungen, könnten validiert werden.
Die Erfüllung von Systemanforderungen lässt sich verifizieren, aber nicht validieren.
Validieren kann man definitionsgemäß hingegen Nutzungsanforderungen. Doch die tauchen überhaupt nicht auf, sondern gehen im Nebel der Anwenderbedürfnisse unter.
d) Irrglaube, dass eine erfolgreiche Verifizierung die Voraussetzung für eine erfolgreiche Validierung ist
Die Ergebnisse von Verifizierung und Validierung können unabhängig voneinander sein. Es ist durchaus denkbar, dass die Verifizierung eines Medizinprodukts erfolgreich ist und die Validierung nicht; oder umgekehrt. Das zeigen die folgenden Beispiele:
- Am Defibrillator liegen die spezifizierten 3.000 V an den Pads an (Verifizierung erfolgreich). Das Herz des Patienten schlägt (Zweckbestimmung) aber nach Anwendung des Produkts nicht (Validierung gescheitert).
- Am Defibrillator liegen statt der spezifizierten 3.000 V an den Pads nur 2.000 V an (Verifizierung gescheitert). Das Herz des Patienten schlägt (Zweckbestimmung) trotzdem nach Anwendung des Produkts wieder (Validierung erfolgreich).
Lesen Sie hier mehr zum Thema Verifizierung und Validierung von IVD.
e) Verifizierung nur des Produkt bzw. dessen Komponenten
Nicht nur das (Medizin-)Produkt und seine Komponenten müssen die Hersteller verifizieren (siehe rechte Seite des V-Modells).
Auch die Entwicklungsdokumente, die während der konstruktiven Phase entstehen (graue Kästchen) sind zu verifizieren (grüne Kreise). Die Validierung schließt die Entwicklung ab (blaues Kästchen).
5. Unterstützung
Eine erfolgreiche und gesetzeskonforme Verifizierung und Validierung zählen zu den wichtigsten Voraussetzungen für die Zulassung von Medizinprodukten. Daher sollten den Herstellern dabei keine Fehler unterlaufen.
Um Probleme zu vermeiden, stehen zahlreiche Hilfestellungen bereit:
- Das kostenlose Starter-Kit des Johner Instituts verschafft Ihnen einen schnellen Überblick über die regulatorische Landschaft und führt Sie in sechs Schritten zur „Zulassung“ Ihres Medizinprodukts.
- Dieser kurze Artikel zu Software-Systemanforderungen erläutert, wie man diese formuliert und damit die Voraussetzungen für Software-Systemtests schafft.
- Ein weiterer Artikel beschreibt, was speziell bei der Validierung von Software als Medizinprodukt zu beachten ist.
- Das wegweisende Seminar “Usability, Requirements und IEC 62366″ vermittelt, wie man die Gebrauchstauglichkeit von Medizinprodukten gewährleistet und dies mit der Verifizierung und Validierung nachweist.
- In den Usability Labs des Johner Instituts können Sie die Gebrauchstauglichkeit Ihrer Produkte prüfen lassen (Verifizierung und Validierung).
Nehmen Sie Kontakt mit uns auf!
Änderungshistorie
- 2023-04-18: V-Modell eingefügt
- 2023-02-18: Publikation zur Verifizierung und Validierung verlinkt
- 2021-09: Artikel völlig überarbeitet, neu strukturiert, regulatorische Anforderungen aktualisiert, Video ausgetauscht
validierung prüft, ob etwas etwas vom aufbau und seiner struktur her grundsätzlich kann bzw. können müsste, also von der idee, konzept und logik her funktionieren müsste. verifizierung prüft, ob etwas ewtas in einer bestimmten festgelegten weise tut und damit ein spezifisches gefordertes verhalten zeigt. im grunde können die beiden im hinblick auf die nutzererfordernisse BEIDE daneben liegen. etwas kann vom prizip her richtig konstruiert sein, aber trotzdem das falsche verhalten zeigen, oder aber das richtige verhalten zeigen, aber falsch konstruiert sein, so dass es eher zufall war. zusammenführen lässt sich das nur durch eine übergeordnete qualifizierung, die sowohl bauart als auch verhalten im hinblick auf ein wiederholt erwartbares ergebnis qualifiziert.
Vielen dank für die ausgezeichnete Erklärung.
MfG
Danke, ich freue mich!
Viele Grüße, Christian Johner
Vielen Dank für die Überarbeitung des Artikels zur Verifizierung und Validierung! Tolle Arbeit!
Dieser und das dazugehörige Video zeigen sehr gut die Herausforderungen, die man zwangsläufig hat, wenn man in diesem Metier arbeitet.
Vielen Dank! Das werde ich an Herrn Prof. Johner weiterleiten, er wird sich freuen! Herzliche Grüße, Anja Segschneider | Redaktion
Vielen Dank für den sehr gut strukturierten und verständlichen Artikel zu dem Thema!
Mir ist jedoch etwas aufgefallen. Unter Abbildung 2 wird folgende Erklärung genannt:
„Auch die Entwicklungsdokumente, die während der konstruktiven Phase entstehen (graue Kästchen) sind zu validieren (grüne Kreise). Die Validierung schließt die Entwicklung ab (blaues Kästchen).“
Ist das so korrekt? Nach meinem Verständnis – und der Farbgebung in der Darstellung – werden die Entwicklungsdokumente *verifiziert*, nicht *validiert*.
Sehr geehrte Rebecca W,
danke für Ihre wichtige Frage!
Die kurze Antwort ist: Sie haben Recht, ich habe das geändert.
Die etwas längere Antwort lautet: Die regulatorischen Anforderungen sprechen meist von einer Validierung der Dokumente. Sie meinen damit eine Prüfung, ob die Dokumente den beabsichtigten Zweck erfüllen. Das ist in der Tat eine Validierung. Allerdings nutzen die Firmen meist Methoden, die der Verifizierung zuzuordnen wären. Die IEC 62304 spricht sogar von einer Verifizierung. Damit ist beides korrekt. Aber Sinne der Farbgebung sollte ich konsequent sein. Daher habe ich das Wort geändert.
Nochmals vielen Dank für Ihr aufmerksames Lesen und Ihren Hinweis!
Viele Grüße
Christian Johner