Verifizierung bezeichnet den objektiven Nachweis, dass festgelegte Anforderungen erfüllt wurden. Im Design- und Entwicklungsprozess für Medizinprodukte beantwortet die Verifizierung insbesondere die Frage: Erfüllen die Design Outputs die festgelegten Design Inputs?
Im Usability Engineering kann die Verifizierung beispielsweise Anforderungen an Anzeigen, Alarme, Bedienelemente, Bedienlogiken, Kennzeichnungen oder Gebrauchsanweisungen betreffen.
Von der Validierung ist sie klar abzugrenzen: Während die Verifizierung die Übereinstimmung von Entwicklungsergebnissen mit festgelegten Anforderungen prüft, untersucht die Validierung, ob das resultierende Medizinprodukt die Anforderungen der vorgesehenen Anwendung und die Bedürfnisse der vorgesehenen Benutzer erfüllt.
Verifizierung im Entwicklungsprozess
Verifizierungsaktivitäten sind ein zentraler Bestandteil des Design- und Entwicklungsprozesses. Sie liefern objektive Nachweise dafür, dass die entwickelten Design Outputs die zugrunde liegenden Design Inputs erfüllen. Im Usability Engineering kann dies beispielsweise die Prüfung folgender Elemente umfassen:
- Anzeigen und Displays
- Alarmsignale
- Bedienelemente
- Bedien- und Interaktionslogiken
- Softwarefunktionen
- Systemrückmeldungen
- Kennzeichnungen
- Gebrauchsanweisungen
- Schutz- und Verriegelungsmechanismen
Eine belastbare Verifizierung setzt voraus, dass die zu prüfenden Anforderungen eindeutig und überprüfbar formuliert sind. Anforderungen wie „gut sichtbar", „leicht verständlich" oder „intuitiv bedienbar" lassen ohne weitere Konkretisierung nicht eindeutig erkennen, anhand welcher Kriterien ihre Erfüllung bewertet werden soll. Für jede Verifizierungsaktivität sollten deshalb unter anderem festgelegt werden:
- zu verifizierende Anforderung
- Prüfgegenstand
- Prüfmethode
- Akzeptanzkriterien
- erforderliche Prüfumgebung
- benötigte Prüfmittel
- gegebenenfalls Stichprobengröße und deren Begründung
- Verantwortlichkeiten
- Umgang mit Abweichungen
Die Ergebnisse sowie erforderliche Folgemaßnahmen müssen dokumentiert und nachvollziehbar mit den zugrunde liegenden Anforderungen verknüpft werden.
Abgrenzung zwischen Verifizierung und Validierung
Verifizierung und Validierung werden in Entwicklungsprojekten häufig gleichgesetzt, verfolgen jedoch unterschiedliche Ziele. Verifizierung fragt: Wurden die festgelegten Anforderungen korrekt umgesetzt? Validierung fragt: Erfüllt das resultierende Produkt die Anforderungen der vorgesehenen Anwendung und die Bedürfnisse der vorgesehenen Benutzer?
Beispiel: Ein Design Input fordert, dass ein Alarm innerhalb eines festgelegten Frequenzbereichs einen definierten Schalldruckpegel erreicht. Die messtechnische Prüfung des erzeugten Alarms gegen diese Vorgaben ist eine Verifizierung. Die Untersuchung, ob die vorgesehenen Benutzer den Alarm unter repräsentativen Nutzungsbedingungen wahrnehmen, verstehen und angemessen darauf reagieren, ist Teil der Validierung der sicheren Verwendung.
Die Unterscheidung hängt jedoch nicht allein von der eingesetzten Methode ab. Auch eine Verifizierung kann Benutzer einbeziehen, wenn eine festgelegte Anforderung gegen objektive Akzeptanzkriterien geprüft wird. Umgekehrt kann eine Validierung neben Benutzerstudien auch andere Nachweise umfassen. Entscheidend sind daher: die zugrunde liegende Fragestellung, der Bezug zu Design Inputs oder Anforderungen der vorgesehenen Anwendung, der Reifegrad des Produkts und die Rolle des Nachweises im Entwicklungsprozess.
Die Verifizierung von Einzelanforderungen ersetzt nicht die Validierung des resultierenden Medizinprodukts beziehungsweise seiner sicherheitsrelevanten Benutzungsschnittstelle.
Typische Verifizierungsmethoden für Benutzungsschnittstellen
Die geeignete Verifizierungsmethode hängt von der jeweiligen Anforderung und dem zu prüfenden Design Output ab. Typische Methoden sind:
- Inspektionen
- Dokumentenprüfungen
- Expertenreviews
- checklistenbasierte Konformitätsprüfungen
- Messungen physikalischer Eigenschaften
- Software-, Integrations- und Systemtests
- Funktionstests
- Simulationen und Berechnungen
- Analyse von Zeichnungen und Spezifikationen
- Prüfung von Kennzeichnung und Gebrauchsanweisung
- Traceability-Analysen
- Vergleich mit festgelegten Normen und Akzeptanzkriterien
- gegebenenfalls evaluationsbasierte Prüfungen mit Benutzern
Beispiele für verifizierbare Eigenschaften einer Benutzungsschnittstelle sind:
- Größe und Abstand von Bedienelementen
- Zeichengröße und Kontrast
- Schalldruckpegel und Frequenz eines Alarms
- erforderliche Betätigungskraft
- Reaktionszeit der Benutzungsschnittstelle
- zulässige Eingabebereiche
- Vorhandensein definierter Systemrückmeldungen
- Verhalten bei ungültigen Eingaben
- Übereinstimmung der Gebrauchsanweisung mit der Produktspezifikation
- korrekte Umsetzung definierter Bedienabläufe
Für viele dieser Prüfungen sind keine repräsentativen Benutzer erforderlich. Bei wahrnehmungs-, verständnis- oder handlungsbezogenen Anforderungen kann eine Evaluation mit geeigneten Teilnehmern jedoch erforderlich sein. Die bloße Beteiligung von Benutzern macht eine Prüfung nicht automatisch zur Validierung. Maßgeblich bleibt, ob eine definierte Produktanforderung geprüft oder die Eignung für die vorgesehene Anwendung bewertet wird.
Zusammenhang mit Nutzungsrisiken
Viele Anforderungen an die Benutzungsschnittstelle entstehen aus der Nutzungsrisikoanalyse. Wird beispielsweise die eindeutige Unterscheidbarkeit zweier Anschlüsse als Risikobeherrschungsmaßnahme festgelegt, können daraus konkrete Design Inputs entstehen, etwa hinsichtlich Form, mechanischer Codierung, Position oder Kennzeichnung. Die anschließende Verifizierung muss nachweisen, dass die festgelegte Maßnahme umgesetzt wurde und dass die Maßnahme die beabsichtigte Risikobeherrschung tatsächlich erreicht.
Die Prüfung der Umsetzung kann häufig durch Inspektion, Messung oder technische Tests erfolgen. Die Prüfung der Wirksamkeit kann dagegen zusätzliche Methoden erfordern. Bei nutzungsbezogenen Risikobeherrschungsmaßnahmen kann beispielsweise untersucht werden, ob die vorgesehenen Benutzer die Anschlüsse unter repräsentativen Bedingungen zuverlässig unterscheiden und korrekt verbinden.
Nach ISO 14971 müssen sowohl die Umsetzung als auch die Wirksamkeit der Risikobeherrschungsmaßnahmen verifiziert werden. Die Wirksamkeitsprüfung ist dabei nicht automatisch mit einer Design Validation gleichzusetzen. Abhängig von der Maßnahme kann sie jedoch eine formative oder summative Evaluation mit Benutzern erforderlich machen. Zwischen folgenden Elementen sollte eine nachvollziehbare Traceability bestehen: Gefährdung → Gefährdungssituation → Risikobeherrschungsmaßnahme → Design Input → Design Output → Verifizierungsnachweis. Bei nutzungsbezogenen Risiken kann zusätzlich ein Bezug zu gefährdungsbezogenen Nutzungsszenarien und zur summativen Evaluation erforderlich sein.
Verifizierung von Usability-Anforderungen
Usability-bezogene Anforderungen müssen so formuliert werden, dass ihre Erfüllung objektiv und nachvollziehbar bewertet werden kann. Aussagen wie „Der Alarm muss gut wahrnehmbar sein.", „Die Anzeige muss leicht verständlich sein.", „Die Bedienung muss intuitiv sein." oder „Das Produkt muss einfach zu verwenden sein." sind als alleinige Design Inputs in der Regel nicht ausreichend.
Sie sollten in konkrete Anforderungen und geeignete Akzeptanzkriterien überführt werden. Diese können sich beispielsweise beziehen auf:
- Zeichengröße
- Kontrast
- Betrachtungsabstand
- Beleuchtungsbedingungen
- Lautstärke und Frequenz
- räumliche Anordnung von Bedienelementen
- erforderliche Bedienkräfte
- Systemreaktionszeiten
- eindeutige Darstellung von Einheiten
- Trennung kritischer Funktionen
- zulässige Eingabebereiche
- Verhalten bei ungültigen oder widersprüchlichen Eingaben
Nicht jede usability-relevante Anforderung lässt sich ausschließlich anhand technischer Messgrößen verifizieren. Anforderungen an das Erkennen, Verstehen oder korrekte Ausführen einer Handlung können evaluationsbasierte Prüfungen erfordern. Dabei muss sorgfältig unterschieden werden, ob eine konkrete Anforderung verifiziert, eine Designlösung formativ untersucht oder die sichere Nutzung der finalen Benutzungsschnittstelle summativ validiert wird.
Fehlerraten, Bearbeitungszeiten und Aufgabenerfolg können geeignete Messgrößen sein. Ihre regulatorische Bedeutung hängt jedoch vom Untersuchungsziel, den Teilnehmern, den Nutzungsbedingungen, dem Produktstand und den festgelegten Akzeptanzkriterien ab. Solche Messgrößen sind deshalb nicht automatisch reine Verifikationskriterien.
Typische Schwachstellen in der Praxis
Ein häufiger Fehler besteht darin, Verifizierung ausschließlich als technische Prüfung zu verstehen und usability-relevante Anforderungen nicht in die Verifizierungsplanung einzubeziehen. Weitere typische Schwachstellen sind:
- unklare oder nicht überprüfbare Design Inputs
- fehlende Akzeptanzkriterien
- Akzeptanzkriterien, die erst nach Durchführung der Prüfung festgelegt werden
- fehlende Traceability zwischen Design Input, Design Output und Verifizierungsnachweis
- Verifizierung gegen veraltete Anforderungen oder Produktstände
- unzureichend definierte Prüfbedingungen
- fehlende Begründung von Stichprobengrößen
- ungeeignete oder nicht kalibrierte Prüfmittel
- fehlende Prüfung von Grenz- und Fehlerfällen
- unzureichende Dokumentation von Abweichungen
- fehlende Wiederholungsprüfung nach Designänderungen
- Vermischung von Verifizierungs- und Validierungszielen
- ausschließliche Prüfung der Umsetzung von Risikobeherrschungsmaßnahmen ohne Bewertung ihrer Wirksamkeit
- fehlende Abstimmung zwischen Entwicklung, Human Factors, Risikomanagement und Qualitätsmanagement
Problematisch ist auch die Aussage, dass eine bestimmte Methode grundsätzlich der Verifizierung oder Validierung zuzuordnen sei. Ein Expert Review kann beispielsweise eine Verifizierungsaktivität sein, wenn die Übereinstimmung mit festgelegten Anforderungen geprüft wird. Es kann aber auch eine formative Evaluation darstellen, wenn damit noch nicht bekannte Schwächen der Benutzungsschnittstelle identifiziert werden sollen. Ebenso kann ein Test mit Benutzern je nach Zielsetzung eine Anforderung prüfen, eine Designlösung formativ untersuchen oder Bestandteil der summativen Validierung sein.
Regulatorischer Bezug
Die ISO 13485:2016 fordert, dass die Design- und Entwicklungsverifizierung nach geplanten und dokumentierten Vorgaben durchgeführt wird. Dabei ist nachzuweisen, dass die Design Outputs die Design Inputs erfüllen. Die Verifizierungsplanung muss geeignete Methoden und Akzeptanzkriterien enthalten. Falls statistische Verfahren oder Stichproben eingesetzt werden, müssen auch die zugrunde liegenden Begründungen berücksichtigt werden. Die Ergebnisse und alle erforderlichen Maßnahmen müssen dokumentiert werden. Die Anforderungen an Design und Entwicklung sind in Abschnitt 7.3 der ISO 13485 verankert.
Die IEC 62366-1 beschreibt einen Prozess zur Analyse, Spezifikation, Entwicklung und Evaluation der Gebrauchstauglichkeit eines Medizinprodukts mit Bezug zur Sicherheit. Dabei entstehen unter anderem Anforderungen und Spezifikationen an die Benutzungsschnittstelle, deren Umsetzung im Design- und Entwicklungsprozess überprüft werden muss. Die Norm konzentriert sich jedoch nicht ausschließlich auf die Verifizierung technischer Anforderungen, sondern verlangt auch eine summative Evaluation der sicherheitsrelevanten Nutzung der Benutzungsschnittstelle.
Die ISO 14971 verlangt die Verifizierung der Umsetzung und der Wirksamkeit von Risikobeherrschungsmaßnahmen. Für nutzungsbezogene Maßnahmen müssen geeignete Nachweise ausgewählt werden. Abhängig von der Maßnahme können technische Prüfungen, Inspektionen, Analysen oder Evaluationen mit Benutzern erforderlich sein.
Für den US-amerikanischen Markt gilt seit dem 2. Februar 2026 die FDA Quality Management System Regulation (QMSR). Die QMSR bindet ISO 13485:2016 in 21 CFR Part 820 ein. Die Design-and-Development-Anforderungen ergeben sich insbesondere aus 21 CFR 820.10(c) in Verbindung mit ISO 13485:2016, Abschnitt 7.3. Frühere Verweise auf 21 CFR 820.30(f) als eigenständige FDA-Anforderung an Design Verification entsprechen daher nicht mehr der aktuellen regulatorischen Struktur.
Die europäische MDR verlangt im Rahmen der technischen Dokumentation unter anderem Nachweise zur Verifizierung und Validierung des Produkts. Für usability-relevante Anforderungen ergibt sich daraus in der Praxis eine Kombination aus technischen Verifizierungsnachweisen, Risikomanagementaktivitäten und der Evaluation der Benutzungsschnittstelle.
Häufige Fragen (FAQ)
Ist ein summativer Usability-Test eine Verifizierung?
Nein. Eine summative Usability-Evaluation beziehungsweise Human Factors Validation untersucht, ob die finale oder produktionsäquivalente Benutzungsschnittstelle durch die vorgesehenen Benutzer unter repräsentativen Bedingungen sicher verwendet werden kann. Sie dient damit primär der Validierung der sicheren Verwendung und nicht lediglich der Prüfung einzelner Design Inputs. Einzelne technische oder dokumentarische Eigenschaften des Testgegenstands können im Vorfeld jedoch verifiziert werden, beispielsweise der Produktstand, bestimmte Alarmparameter oder die Übereinstimmung mit der User Interface Specification.
Kann eine Expertenevaluation eine Verifizierung darstellen?
Ja. Wenn Experten anhand festgelegter Anforderungen und Akzeptanzkriterien prüfen, ob ein Design Output die Design Inputs erfüllt, kann die Expertenevaluation eine Verifizierungsaktivität darstellen. Wird ein Expert Review dagegen eingesetzt, um Schwächen zu entdecken, neue Anforderungen abzuleiten oder alternative Lösungen zu bewerten, handelt es sich eher um eine formative Evaluation. Eine Expertenevaluation ersetzt keine erforderliche summative Evaluation mit repräsentativen Benutzern.
Müssen alle Usability-Anforderungen verifiziert werden?
Dokumentierte Design Inputs müssen durch geeignete Nachweise abgedeckt werden. Dabei können unterschiedliche Verifizierungsmethoden erforderlich sein. Manche Anforderungen lassen sich vollständig durch Inspektionen, Messungen oder technische Tests verifizieren. Andere erfordern evaluationsbasierte Verfahren oder zusätzlich eine Validierung mit repräsentativen Benutzern. Entscheidend ist eine vollständige und nachvollziehbare Traceability zwischen Anforderungen, Entwicklungsergebnissen und Nachweisen.
Warum reicht die Verifizierung der Umsetzung einer Risikobeherrschungsmaßnahme nicht aus?
Weil die korrekte Implementierung einer Maßnahme noch nicht belegt, dass sie das betreffende Risiko tatsächlich wie vorgesehen reduziert. Beispielsweise kann verifiziert werden, dass ein Warnhinweis in der Gebrauchsanweisung vorhanden ist. Damit ist jedoch noch nicht nachgewiesen, dass die vorgesehenen Benutzer ihn finden, verstehen, erinnern und in der konkreten Anwendungssituation befolgen. Deshalb müssen sowohl die Umsetzung als auch die Wirksamkeit einer Risikobeherrschungsmaßnahme verifiziert werden.
Können Benutzer an einer Verifizierung teilnehmen?
Ja. Die Beteiligung von Benutzern macht eine Prüfung nicht automatisch zu einer Validierung. Wenn mit geeigneten Teilnehmern eine klar definierte Anforderung gegen vorab festgelegte Akzeptanzkriterien geprüft wird, kann dies Bestandteil der Verifizierung sein. Werden dagegen Nutzerbedürfnisse, die vorgesehene Anwendung oder die sichere Nutzung der finalen Benutzungsschnittstelle unter repräsentativen Bedingungen bewertet, handelt es sich um Validierung.
Muss nach jeder Designänderung erneut verifiziert werden?
Jede Designänderung muss hinsichtlich ihrer Auswirkungen auf Anforderungen, Risiken, bereits durchgeführte Verifizierungen und Validierungen bewertet werden. Die betroffenen Anforderungen und Entwicklungsergebnisse müssen erneut verifiziert werden. Zusätzlich ist zu prüfen, ob Regressionstests oder eine erneute Validierung erforderlich sind. Der Umfang richtet sich nach Art, Bedeutung und möglichen sicherheitsbezogenen Auswirkungen der Änderung.
Verifizierung prüft, ob dokumentierte Entwicklungsergebnisse die festgelegten Anforderungen erfüllen: Design Input → Design Output → Verifizierungsnachweis. Validierung untersucht dagegen, ob das resultierende Medizinprodukt die Anforderungen der vorgesehenen Anwendung und die Bedürfnisse der vorgesehenen Benutzer erfüllt.
Die Unterscheidung hängt nicht allein von der Methode oder der Beteiligung von Benutzern ab. Entscheidend sind die Fragestellung, die Bezugsanforderung und die regulatorische Funktion des Nachweises. Eine gemessene Alarmlautstärke ist ein typisches Beispiel für Verifizierung. Ob die vorgesehenen Benutzer den Alarm unter repräsentativen Bedingungen wahrnehmen, verstehen und angemessen darauf reagieren, ist eine Frage der Validierung.
Sie möchten Verifizierungs- und Validierungsaktivitäten für Ihre Benutzungsschnittstelle sauber trennen, risikobasiert planen und nachvollziehbar dokumentieren? Wir unterstützen Sie im gesamten Usability-Engineering-Prozess nach IEC 62366-1.
Mehr zu unserem Usability Engineering