Verifizierung und Validierung: Unterschied & Definitionen

Video zum Unterschied von Verifizierung und Validierung

Verifizierung (Definition und Beispiele)

Verifizierung von Produkten (allgemein)

Der diese Definition den Begriff der Anforderungen nicht weiter benennt, empfiehlt es sich, im Kontext von Produkt-Anforderungen die Definition etwas anzupassen.

Diese (Produkt-)Eigenschaften oder Merkmale finden sich beispielsweise in einer System Requirements Specification (SRS).

Beispiele für spezifizierte Merkmale sind die Gestaltung der Benutzerschnittstelle (siehe auch Verifizierung der Gebrauchstauglichkeit), das Verhalten des Systems auf Aktionen über dessen technische oder Datenschnittstellen oder am Anwendungsteil. So könnte spezifiziert sein, dass an einem Defibrilator eine gewissen 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.

Verifizierung der Gebrauchstauglichkeit

Definition: 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 als solche sein. Diese Prüfung (Verifizierung) erfolgt üblicherweise in Form einer Inspektion durch einen Experten. Man prüft entweder gegen spezifizierte Produktmerkmale oder gegen 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 Usability & Requirements Seminar von Thomas Geis. Und hier finden Sie einen Überblick unserer Medizintechnik- und Medizinsoftware-Seminare.

 Validierung (Definition und Beispiele)

Die Validierung hingegen ist der objektive Nachweis, dass ein spezifizierter Nutzer im spezifizierten Nutzungskontext seine spezifizierten Nutzungsziele erreichen kann.  Diese Prüfung hat zwei Aspekte, nämlich

1. „Klassische Validierung“: Die Prüfung, ob man überhaupt das Nutzungsziel mit dem Medizinprodukt erreichen kann. Die Nutzungsziele finden sich in der Zweckbestimmung beschrieben.
2. Validierung der Gebrauchstauglichkeit: Die Prüfung, ob die spezifizierten Nutzer im spezifizierten Nutzungskontext, die Nutzungsziele (Zweckbestimmung) effektiv, effizient und zufriedenstellend erreichen können.

Deshalb ließe sich die Definition des Begriffs Validierung auch erweitern:

Lesen Sie hier mehr zur Validierung von Medizinprodukten.

Benötigen Sie Unterstützung dabei, die Verifizierung und Validierung Ihrer Produkte normenkonform zu planen und zu dokumentieren Professor Johner und sein Team helfen gerne! Nehmen Sie Kontakt auf!

Kontakt aufnehmen

Ergebnisse der Verifizierung und  Validierung können unabhängig sein

Es ist durchaus denkbar, dass die Verifizierung des Medizinprodukts erfolgreich ist und die Validierung nicht und umgekehrt, wie folgende Beispiele zeigen:

• Am Defibrillator liegen die spezifizierten 3000 Volt 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 Volt an den Pads nur 2000 V an (Verifizierung gescheitert). Das Herz des Patienten schlägt (Zweckbestimmung) aber nach Anwendung des Produkts dennoch (Validierung erfolgreich).

Videotrainings zur Verifizierung und Validierung

In über 60 Videotrainings beschreibt der Auditgarant, wie Sie die Anforderungen an Ihre Medizinprodukte erheben, spezifizieren und im Rahmen der Verifizierung und Validierung prüfen. Den Premium-Mitgliedern stehen zudem Checklisten und Templates zur Verfügung z.B. für einen Validierungsplan und die Dokumentation der Validierungsergebnisse.

Videotrainings zur Verifizierung und Validierung ansehen

Software-Verifizierung und Validierung: Besonderheiten von stand-alone Software

Im Folgenden lesen Sie mehr über

• Regulatorische Anforderungen
• Verifizierung von Software-Anforderungen bei Sicherheitsklasse A
• Besonderheiten der Verifizierung und Validierung von Mobile Medical Apps

1. Regulatorische Anforderungen an die Entwicklung von Medizinprodukten

Die Richtlinien für Medizinprodukte, speziell die “Medical Device Directive” (93/42/EWG) und die “Active Implantable Device Directive” sind sich einig: Zu den grundlegenden Anforderungen eines Medizinproduktes zählt:

“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.”
Ergänzung durch die 2007/47/EC

Und wie lassen Sie nun Ihren Auditor vermuten, dass Sie Ihre Software nach dem Stand der Technik validiert haben? Normalerweise würden Sie eine Norm einhalten. Für die Software-Verifizierung ist die IEC 62304 anzuwenden, für die Software-Validierung gibt es aber keine spezifische Norm.

Übrigens: Das übliche Blackbox-Testen ist meistens eine Verifizierungs- und keine Validierungsaktivität!

2. Verifizierung von Software-Anforderungen bei Sicherheitsklasse A

Laut ISO 14971 müssen Sie hingegen alle Maßnahmen, die zur Risikokontrolle beitragen, verifizieren. Wenn Sie also Maßnahmen in Software implementieren, müssen Sie diese unabhängig von der Sicherheitsklasse einer Verifizierung unterziehen!

3. Validierung und Verifizierung von Medical Apps

Zu meinem Beitrag zu den Mobile Medical Apps stellte man die folgende wichtige Frage:
Für mich bleibt dabei eine wesentliche Frage offen, die Apps von anderer Software unterscheidet: Wie muss ich die Plattform in den Prozess der Verifizierung und Validierung einbeziehen? Sprich, reicht es dass ich es auf einem System mit Android x.y teste, und dann kann ich es für alle Produkte mit dieser Version in Verkehr bringen? Oder muss ich unterschiedliche Hardware testen – die z.B. die von der App verwendete Bluetooth-Schnittstelle anders ansprechen? Was ist, wenn es ein Sicherheitsupdate der Android-Version gibt? Was ist, wenn andere Apps installiert werden, die auch dieselben Hardware-Schnittstellen nutzen möchten? Muss ich die alle testen?
Genau genommen sind das gleich mehrere Fragen. Lassen Sie uns diese einzelne adressieren:

a) Wie vollständig muss man Mobile Medical Apps verifizieren?

Die Verifizierung ist die Überprüfung, das spezifizierte Produkteigenschaften erfüllt sind – hier konkret die Software-Anforderungen. Zu diesen Software-Anforderungen zählt auch eine Beschreibung der Laufzeitumgebung, zu der die oben genannte Plattform zählt. Schauen Sie sich bitte im Institutsclub die Videotrainings zu den Software Requirements Specifications an, wenn Sie mehr darüber erfahren möchten.

Die Plattform umfasst Aspekte wie die Hardware einschließlich Bildschirmgrößen und Bildschirmauflösungen sowie das Betriebssystem, hier bestimmte Android-Versionen, ebenso wie die Verfügbarkeit und Korrektheit von Datenschnittstellen wie Bluetooth.

Ebenfalls ein Aspekt ist die „Verifizierung der Gebrauchstauglichkeit“, bei der der Hersteller gegen die „Spezifikation der Gebrauchstauglichkeit“ prüft, die wiederum eigene Forderungen enthält oder/und auf Normen wie die ISO 9241-Familie verweist.

Eine vollständige Verifizierung ist wie alle Prüfungen in der Regel ausgeschlossen. D.h. alle „Tests“ werden nur Stichprobenprüfungen sein. Nun stellt sich die Frage, wie umfangreich diese Stichproben sein müssen. Die Antwort darauf kann sich nur im Risikomanagement finden. Nur dort können Sie abschätzen, welche Risiken sich dadurch ergeben könnten, dass die Plattform sich anders verhält, als Sie das vermuten.

b) Wie sind Mobile Medical Apps zu validieren?

Die Antwort mit dem Risikomanagement passt auch für diese Frage. Wir können aber noch spezifischer werden: Bei der Validierung geht es um einen Nachweis, dass spezifizierte Nutzer im spezifizierten Nutzungskontext ihre spezifizierten Nutzungsziele erreichen. Wie könnte dieses Ausmaß von der Plattform abhängen: Eine entscheidende Rolle spielt sicher die Größe und Auflösung der Bildschirme. Die anderen Faktoren sollten konstant sein bzw. über die Verifizierung bereits geprüft und beherrscht sein.

c) Wie geht man damit um, dass es noch andere Apps gibt?

Spätestens jetzt wird Sie die Kombinatorik überfordern: Das Zusammenspiel aller möglichen Apps werden Sie niemals testen können. Auch hier müssen Sie das Risikomanagement zur Hilfe ziehen: Wenn (inakzeptable) Risiken dadurch entstehen, dass andere Apps Schnittstellen belegen (oder die Plattform in anderer Weise beeinträchtigen), müssen Sie den üblichen von der MDD vorgeschriebenen „Dreisprung“ wählen:

1. Inhärente Sicherheit anstreben (z.B. Funktionen nicht zu nutzen, Funktionalitäten nicht anzubieten, andere Plattform wählen usw.)
2. Schutzmaßnahmen wählen: Beispielsweise könnte man in der Software erst prüfen, ob Schnittstellen nach außen funktionieren (z.B. über einen „Webservice-Ping“, wenn über einen Webservice Daten geladen bzw. verschickt würden)
3. Nutzer über Risiken informieren.

Auch hier ist Testen kein Instrument, um die Korrektheit der Mobile Medical App nachzuweisen.

Auch die IEC 60601-1 verwechselt Verifizierung und Validierung

Wenn man in einer Schulung über Softwareentwicklung etwas gelehrt bekommt, ist es das V-Modell. Immer und immer wieder. Es ist auch ein wunderbares Modell, um vieles zu erklären.

Doch wie versteht die IEC 60601-1 dieses V-Modell?

Quelle: IEC 60601-1 bzw. IEC 62304.

Laut dieser Norm (siehe Abbildung) werden aus Anwenderbedürfnissen Anforderungen an ein programmierbares elektrisches medizinisches System, kurz PEMS, abgeleitet. Also Systemanforderungen.

Das erste, was man sich fragen muss, was die Norm unter Anwenderbedürfnissen versteht. Es handelt sich um einen nicht definierten Begriff. Wahrscheinlich verstehen die Autoren darunter ein nicht näher verstandenes 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 wie eben diskutiert überhaupt nicht in dem Bild auf, sondern gehen im Nebel der Anwenderbedürfnisse unter.

Noch mehr Informationen zur Verifizierung und Validierung von Software/Medizinprodukten

Ihre nächsten Schritte

•  Wenn Sie wissen wollen, wie man (Software)Systemanforderungen formuliert, welche die Gegenstand der Verifizierung sind, dann lesen Sie den kurzen Artikel zu den Software-Systemanforderungen.
• Wenn Sie hingegen wissen wollen, was man bei der Validierung zu beachten hat, dann lesen Sie den Artikel zur Validierung von Software als Medizinprodukt.
• Wenn diese Unterschiede nicht gleich einleuchten, dann empfehle ich das (zumindest für mich) wegweisende Seminar von Thomas Geis. Es heißt “Usability, Requirements und IEC 62366?. Thomas Geis ist sehr streng mit den Begrifflichkeiten. Und das macht seine Ergebnisse so sensationell. Wenn Sie eine Innovationsmaschine erleben wollen, besuchen Sie das Seminar – oder buchen Sie ihn am besten gleich. Mach ich auch so…

Nehmen Sie Kontakt mit uns auf!

War dieser Artikel hilfreich? Bitte bewerten Sie: