Wie unterscheiden sich die 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 Produkte, z. B. Medizinprodukte, sicher durch Zulassungen und Audits bekommen – Dank einer präzisen Verifizierung und Validierung.
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
Video laden
PGlmcmFtZSBzcmM9Imh0dHBzOi8vd3d3LnlvdXR1YmUtbm9jb29raWUuY29tL2VtYmVkL3lsY0pRdUhSbElFIiB0aXRsZT0iWW91VHViZSB2aWRlbyBwbGF5ZXIiIGFsbG93PSJhY2NlbGVyb21ldGVyOyBhdXRvcGxheTsgY2xpcGJvYXJkLXdyaXRlOyBlbmNyeXB0ZWQtbWVkaWE7IGd5cm9zY29wZTsgcGljdHVyZS1pbi1waWN0dXJlIiBhbGxvd2Z1bGxzY3JlZW49IiIgd2lkdGg9IjU2MCIgaGVpZ2h0PSIzMTUiIGZyYW1lYm9yZGVyPSIwIj48L2lmcmFtZT4=
1. Verifizierung
a) Definition
Definition: Verifizierung
„Bestätigung durch Bereitstellung eines objektiven Nachweises […], dass festgelegte Anforderungen […] erfüllt worden sind“.
Quelle: ISO 9000
Diese Definition erklärt nicht, welche Art von „Anforderungen“ durch die Verifizierung bestätigt werden müssen. Um Unklarheiten und Verwechslungen mit Stakeholder-Anforderungen zu vermeiden, empfiehlt es sich, diese Anforderungen auf Produkt- oder Komponentenanforderungen einzugrenzen.
Definition: Verifizierung
„Die Verifizierung ist eine Prüfung mit objektiven Mitteln, dass spezifizierte Eigenschaften (z. B. von Produkten, Komponenten) erfüllt sind“.
Quelle: Johner-Institut, angepasst aus ISO 9000
Diese Eigenschaften oder Merkmale finden sich beispielsweise in einer System Requirements Specification (SRS) oder in den Komponentenanforderungen spezifiziert.
b) Beispiele
Beispiele für spezifizierte Merkmale sind:
- Spezifikation der Benutzerschnittstelle (siehe nächstes Kapitel)
- Verhalten des Systems an den Datenschnittstellen (u. a. Interoperabilität)
- Verhalten des Systems an „Patientenschnittstellen“: 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 gegen
- spezifizierte Produktmerkmale (z. B. wie in einem Style-Guide oder in einem UI-Mockup beschrieben) oder/und
- allgemeine Regeln, wie sie beispielsweise 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
Definition: Validierung
„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“.
Quelle: ISO 9000:2015
Ob diese Anforderungen für einen bestimmten Gebrauch erfüllt sind, hängt auch von den Nutzern und dem Nutzungskontext ab. Beispielsweise könnte es sein, dass die Anforderungen an einen Defibrillator in einem OP-Setting mit professionellen Anwendern erfüllt sind, 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:
Definition: Validierung
„Bestätigung durch objektiven Nachweis, dass von den spezifizierten Nutzern im spezifizierten Nutzungskontext die spezifizierten Nutzungsziele (Zweckbestimmung) erreicht werden können“
Quelle: Johner-Institut
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: Die Prüfung, ob man mit dem Medizinprodukt das Nutzungsziel überhaupt erreichen kann. Die klinische Prüfung 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 ist Teil der Validierung und muss nachweisen, dass die Nutzungsziele erreicht werden, d. h., dass das Produkt sicher, leistungsfähig und wirksam ist. - Validierung der Gebrauchstauglichkeit: Die Prüfung, ob die spezifizierten Nutzer im spezifizierten Nutzungskontext die Nutzungsziele (Zweckbestimmung) effektiv, effizient und zufriedenstellend erreichen können
3. Software-Verifizierung und Validierung
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 diese Anforderungen an die Verifizierung und Validierung nach Stand der Technik erfüllt sind. Allerdings adressiert die IEC 62304 explizit nur die Verifizierung.
Die Verifizierung von Software erfolgt üblicherweise durch:
Eine wertvolle Ergänzung liefert das Guidance-Dokument der MDCG 2020-1, welches wir in unserem Fachartikel „Klinische Bewertung von Software“ zusammengefasst haben.
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.
- Software -Validierung im weiteren Sinn: Diese Validierung entspricht der Computerized Systems Validation oder dem, was die FDA im Guidance Document „Software Validiation“ vorgibt. Hier wird der Begriff Software-Validierung synonym mit Software-Qualitätssicherung genutzt. Letztere umfasst die Lebenzyklusphasen:
- 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
Data Scientists kennen eine Validierung von Machine-Learning-Modellen, die sich von den beiden eben genannten Validierungen unterscheidet. Mehr dazu erfahren Sie im Video oben.
b) Verzicht auf die Verifizierung bei Sicherheitsklasse A
Laut
IEC 62304 entscheidet die Software-Sicherheitsklasse über die Notwendigkeit von Software-Systemtests, die bei einer Verifizierung der Software erforderlich sind. Bei Sicherheitsklasse A waren in der IEC 62304:2006 keine Tests vorgeschrieben; keine Unit-, keine Integrations- und keine Systemtests. Das hat sich mit dem Amendment I geändert, das zumindest auf Software-Systemtests besteht.
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
In der Software-Entwicklung ist das V-Modell noch in vielen Köpfen verankert und wird auch von der IEC 62304 und der IEC 60601-1 referenziert.
Doch wie versteht die IEC 60601-1 dieses V-Modell?
Quelle: IEC 60601-1 bzw. IEC 62304
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. Es handelt sich um einen nicht definierten Begriff. Wahrscheinlich verstehen die Autoren darunter einen nicht näher spezifizierten Mischmasch aus Erfordernissen, Wünschen, Nutzungsanforderungen und direkt formulierten Systemanforderungen. Wer so unpräzise mit den Begrifflichkeiten umgeht, wird nachher auch unpräzise Ergebnisse erzielen.
Wohin diese mangelnde Präzision führt, erkennen Sie selbst: Die Norm glaubt, die Erfüllung von PEMS-Anforderungen, also Systemanforderungen, validieren zu können.
Systemanforderungen kann man (im Systemtest) 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 des Medizinprodukts erfolgreich ist und die Validierung nicht oder umgekehrt, wie folgende Beispiele zeigen:
- Am Defibrillator liegen die spezifizierten 3000 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 3000 V an den Pads nur 2000 V an (Verifizierung gescheitert). Das Herz des Patienten schlägt (Zweckbestimmung), und nach Anwendung des Produkts auch (Validierung erfolgreich).
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 verschafft Ihnen einen schnellen Überblick über die regulatorische Landschaft und führt Sie in sechs Schritten zur „Zulassung“ Ihres Medizinprodukts.
- Ein kurzer Artikel zu den 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″ von Thomas Geis vermittelt, wie man die Gebrauchstauglichkeit von Medizinprodukten gewährleistet und dies in der Verifizierung und Validierung nachweist.
- In unseren Usability Labs können Sie die Gebrauchstauglichkeit Ihrer Produkte prüfen lassen (Verifizierung und Validierung).
- Mehrere Hundert Videotrainings im Auditgarant beschreiben, wie Sie die Anforderungen an Ihre Medizinprodukte erheben, spezifizieren und im Rahmen der Verifizierung und Validierung prüfen. Premium-Mitgliedern stehen zudem Checklisten und Templates zur Verfügung, z. B. für einen Validierungsplan oder die Dokumentation der Validierungsergebnisse.
Nehmen Sie Kontakt mit uns auf!
Änderungshistorie
- 2021-09: Artikel völlig überarbeitet, neu strukturiert, regulatorische Anforderungen aktualisiert, Video ausgetauscht
