FDA Zulassung für Medizinprodukte: Human Factors Validierung einfach erklärt

Was Hersteller Medizinischer geräte bei der fda-Zulassung wissen müssen

Januar 2026

Executive Summary

Human Factors Validation Testing dient im FDA-Kontext als design validation-Baustein gemäß 21 CFR Part 820.30 mit dem spezifischen Nachweisziel, dass das Medizinprodukt durch die intended users in den intended use environments sicher und effektiv genutzt werden kann. Die Erwartungshaltung hierzu hat die FDA im Guidance Document „Applying Human Factors and Usability Engineering to Medical Devices“ dargelegt. Zentrale Grundlage ist eine risikobasierte Identifikation und Kategorisierung von critical tasks (nach Schwere des potenziellen Schadens), die im Test vollständig abgedeckt werden müssen. Die FDA erwartet typischerweise Usability Tests in Form von simulated-use testing mit finalem User Interface, realistischen Umgebungsbedingungen, repräsentativen Nutzerpopulationen (i. d. R. mindestens 15 Teilnehmende pro relevanter Nutzergruppe) und einer Durchführung, die eine unabhängige und natürliche Nutzung ohne Moderationseinfluss ermöglicht. In der Datenerhebung sind Observationsdaten, ggf. Knowledge task data sowie Post-use interviews zu kombinieren. Die Auswertung ist qualitativ und erfordert eine Root Cause Analysis für Use Errors, Close Calls und Use Difficulties sowie eine belastbare Argumentation zu Residual Risk. In diesem Artikel erfahren Sie, wie hierbei im Detail vorzugehen ist.

1Regulatorischer Kontext und Zielsetzung

Die FDA Guidances betonen im Kontext der FDA Zulassung den risikobasierten Charakter des Human Factors/Usability Engineering und fokussieren sich primär darauf, dass die Benutzerschnittstelle (User Interface) so gestaltet ist, dass Use Errors mit potenziell schädlichen Folgen eliminiert oder so weit wie möglich reduziert werden. HF Validation Testing wird am Ende der Entwicklung durchgeführt, um zu demonstrieren, dass die finale User Interface unter erwarteten Nutzungsbedingungen eine sichere und effektive Nutzung unterstützt und dass die implementierten Risikokontrollmaßnahmen wirksam sind.

2Critical Tasks als testleitende Einheit DER HUMAN FACTORS VALIDierung

Im Rahmen der FDA Zulassung ist ein zentrales Strukturprinzip die Definition von critical tasks. Darunter werden Aufgaben verstanden, deren fehlerhafte oder unterlassene Ausführung zu schwerem Schaden (serious harm) für Patient oder Nutzer führen kann, einschließlich einer Beeinträchtigung der medizinischen Versorgung. Die Identifikation und Begründung dieser critical tasks ist nicht nur für das Testdesign relevant, sondern prägt auch die Bewertungssystematik und die Argumentation im Bericht.

Beachten Sie in Bezug auf critical tasks die folgenden Grundsätze:

Alle critical tasks müssen im Validation Test ausgeführt werden.
Critical tasks werden im Vorfeld aus der Risikoanalyse abgeleitet.
Die Liste ist dynamisch und kann sich mit zunehmendem Verständnis der User-Device-Interaktion erweitern.

Die FDA empfiehlt, critical tasks über eine Kombination aus analytischen und empirischen Zugängen zu identifizieren:

Analytisch u. a. Task Analysis (PCA-Methodik), FMEA oder Fault Tree Analysis (FTA), idealerweise multidisziplinär.
Empirisch u. a. Contextual Inquiry, Interviews, Formative Evaluations (inkl. Cognitive Walkthrough und simulated-use formative testing).

Wichtig ist hierbei die FDA-Logik, dass die Eintrittswahrscheinlichkeit von Use Errors in der Praxis schwer belastbar zu quantifizieren ist; daher wird für die Priorisierung der Aufgaben insbesondere die severity of potential harm herangezogen.

3Erarbeitung des HUMAN FACTORS Validation Test Protocol (Testplan)

Um die Studie methodisch korrekt zu planen, in die Ausarbeitung eines Testplans notwendig. Im Englischen wird der Testplan mit dem Begriff „Test Protocol“ übersetzt. Die FDA fordert üblicherweise, die Human Factors Validation als Usability Test (simulated-use) durchzuführen und formuliert dafür klare Mindestanforderungen an das Studiendesign. Der Validation-Test ist dabei kein exploratives Format, sondern ein gezielt konstruiertes Nachweisformat, das zeigen soll, dass das finale User Interface von den intended users in den intended use environments sicher und effektiv genutzt werden kann – insbesondere in Bezug auf critical tasks

Zentrale Anforderungen der FDA an das Studiendesign

Im Kern fordert die FDA für HF Validation Testing, dass:

die Testteilnehmenden die intended users repräsentieren,
alle critical tasks im Test tatsächlich ausgeführt werden,
das User Interface den finalen Designstand repräsentiert,
und die Testbedingungen ausreichend realistisch sind, damit die Befunde auf die tatsächliche Nutzung übertragbar sind.

Diese Anforderungen sind im Protocol nicht nur zu behaupten, sondern operational zu definieren. Das bedeutet: Es muss nachvollziehbar dokumentiert werden, welche Nutzermerkmale als repräsentativ gelten (und warum), wie die Abdeckung aller critical tasks sichergestellt wird, welche Designversion als „final“ gilt (inkl. Labeling und Instruction for Use (IFU)), und welche Umwelt- und Kontextfaktoren für die Realitätsnähe relevant sind.

Realismusprinzip und Testumgebung

Simulated-use Bedingungen müssen realistisch genug sein, dass Ergebnisse auf reale Nutzung generalisiert werden können. Die FDA betont, dass relevante Umweltfaktoren risikobasiert in die Simulation einzubeziehen sind, sofern sie die Interaktion mit dem Gerät beeinflussen können. Als Beispiele nennt die Guidance u. a. dim lighting, distractions und multitasking.

Für die Protokollplanung bedeutet dies, dass Realismus nicht über „Kulisse“ erreicht wird, sondern über die gezielte Abbildung jener Bedingungen, die als beitragende Faktoren für Use Errors plausibel sind. Das Protocol sollte daher explizit definieren:

welche Umgebungsparameter realitätsrelevant sind (z. B. Licht, Geräusch, Platzverhältnisse, Geräte-Setup, typische Ablenkungen),
welche davon im Test kontrolliert, welche variiert und welche bewusst nicht adressiert werden,
und wie diese Entscheidungen mit Blick auf Use-related Risk Analysis und critical tasks begründet sind.

Gleichzeitig soll die Simulation methodisch stabil bleiben: Realismus darf nicht zu unkontrollierbaren Störvariablen führen. Die FDA-Anforderung zielt daher auf „sufficient realism“, nicht auf vollständige Replikation einer klinischen Umgebung. Entscheidend ist die argumentative Nachvollziehbarkeit, dass die wesentlichen Interaktionsbedingungen abgebildet wurden.

Methodische Abgrenzung: Keine Moderationseinflüsse, kein Think-Aloud

Für Validation gilt, dass Teilnehmende das Gerät unabhängig und natürlich verwenden sollen. Die FDA weist explizit darauf hin, dass think aloud in Validation-Studien nicht akzeptabel ist, da das Verbalisieren das Verhalten verändert und die Situation damit nicht repräsentativ für Real-Use ist. Das Protocol muss deshalb so gestaltet sein, dass relevante Daten primär aus Beobachtungen entstehen. Interaktionen sollen nicht durch Hinweise, Rückfragen oder „Hilfestellungen“ aus dem Studiensetting beeinflusst werden. Wenn Nachfragen erforderlich sind (z. B. zur Ursachenklärung), sollten diese in der Regel in ein post-use Interview verlagert werden, um die eigentliche Task-Performanz nicht zu verfälschen.

Labeling und IFU als Teil der finalen User Interface

Die FDA betrachtet Labeling – einschließlich Instructions for Use (IFU), Device Labels, Packaging, Quick Start Guides und vergleichbarer Informationsbestandteile – als Bestandteil der User Interface. Entsprechend müssen im Validation-Test die finalen Versionen dieser Materialien verwendet werden. Das ist methodisch relevant, weil viele critical tasks nicht nur von der Interaktionsgestaltung, sondern auch von der Verständlichkeit, Auffindbarkeit und Anwendbarkeit von Informationen abhängen. HF Validation prüft damit implizit, ob Nutzer in realistischen Nutzungssituationen mit dem bereitgestellten Labeling die richtigen Entscheidungen treffen und kritische Aufgaben korrekt ausführen können. Die FDA macht jedoch zugleich deutlich, dass Labeling/Training nicht als „Default“-Kompensation für designbedingte Use Errors bei critical tasks dienen darf. Wenn in der Validation Use Errors bei critical tasks auftreten, ist eine reine Nachbesserung über Labeling oder Training ohne zusätzliche Evidenz zur Wirksamkeit dieser Änderungen nicht akzeptabel.

Bestandteile des Test Protocol, die die FDA-Logik typischerweise voraussetzt

Auch wenn die Guidance keine starre Vorgabe macht, empfehlen wir die Folgenden Aspekte im Test Protocol zu beschreiben:

Test objectives mit explizitem Bezug auf safe and effective use und critical tasks,
Beschreibung der finalen User Interface inklusive Labeling-Set,
Use Scenarios und Task-Sets, aus denen die Test Cases zur vollständigen Abdeckung der critical tasks abgeleitet werden,
Success criteria pro Task, welche die erfolgreiche Aufgabenerfüllung klar definieren,
Trainingsanforderungen in Übereinstimmung mit Real-Use,
Test environment und Realismusparameter,
Data collection methods (primär observational, ergänzend Interview/Knowledge Tasks),
Rules for moderator behavior und Handling of deviations

Ein systematisch erarbeitetes Test Protocol zeigt, dass die Studie nicht nur „durchgeführt“, sondern methodisch so konstruiert wurde, dass sie die FDA-Anforderungen an HF Validation als risikobasierter Nachweis tatsächlich erfüllt.

4Stichprobe und TRAINING

Im Kontext der FDA Zulassung empfiehlt die FDA als praktische Untergrenze mindestens 15 Teilnehmende für Human Factors Validation Tests; bei mehreren relevanten User Groups sind mindestens 15 pro User Group vorzusehen.. User Groups unterscheiden sich insbesondere dann, wenn sich Merkmale oder Aufgabenverantwortung so unterscheiden, dass die Interaktion mit dem Gerät voraussichtlich beeinflusst wird (z. B. Lay User vs. Healthcare Professionals, pädiatrisch vs. Erwachsene). Bei der Auswahl der Testteilnehmenden ist es entscheidend, dass es sich um US-Residents handelt.

Repräsentativität und relevante Merkmalsvariabilität

Teilnehmende sollen die relevante Bandbreite der User Group abbilden, insbesondere hinsichtlich Eigenschaften, die Interaktionen beeinflussen können (z. B. sensorische, physische, kognitive Einschränkungen, Literacy/Language, Erfahrung). Für bestimmte Erkrankungen, die funktionelle Limitationen verursachen können, sind entsprechende Repräsentanzüberlegungen ausdrücklich zu berücksichtigen. Mitarbeitende des Herstellers sollen nicht als Teilnehmende von Human Factors Validation Tests eingesetzt werden (Ausnahmen nur in seltenen Spezialfällen).

Training und Real-Use-Nähe (inkl. Training Decay)

Die im Testing angewandte Training-Logik muss die Realität abbilden: Wenn reale Nutzer minimal oder gar nicht trainiert werden, dürfen Testteilnehmende nicht stärker trainiert werden. Training direkt vor dem Test ist problematisch; die FDA weist auf Training Decay hin und erwartet einen zeitlichen Abstand (je nach Gerät: bis zu einem Tag) zur realistischen Abbildung der Retention.

5Datenerhebung – Observational Data, Knowledge Tasks, Post-Use Interviews

Für eine erfolgreiche FDA Zulassung erwartet die FDA beim Human Factors Validation Testing eine Datenerhebung, die primär auf beobachtbarer Task-Performanz beruht und ergänzend jene Aspekte adressiert, die nicht zuverlässig aus Verhalten ableitbar sind (z. B. Verstehen, Interpretation, Entscheidungswissen). Entsprechend sollte das Datenerhebungskonzept im Protocol klar festlegen, welche Datenquellen genutzt werden (Observational Data, Knowledge Task Data, Interviews).

Observational Data als Primärnachweise für Task Performance

Die erfolgreiche Ausführung von critical tasks ist gemäß FDA primär beobachtungsbasiert zu erfassen. Observational Data sind damit die tragende Evidenzquelle für die zentrale Frage, ob die User Interface die sichere und effektive Nutzung unter den vorgesehenen Bedingungen unterstützt.

Aus methodischer Sicht bedeutet dies, dass das Test record (Observationsprotokoll) präzise festhalten muss:

Was als „Task completion“ gilt (Erfolgskriterien je Task, einschließlich erforderlicher Teilhandlungen, korrekter Systemzustände und korrekter Entscheidungen).
Welche Abweichungen als Use Error zu klassifizieren sind (z. B. falsche Auswahl, falsche Einstellung, Auslassen einer sicherheitskritischen Handlung, fehlerhafte Reaktion auf Rückmeldung/Alarm).
Welche Beobachtungsindikatoren als close calls oder use difficulty zu erfassen sind (z. B. Suchverhalten, wiederholtes Probieren, inkonsistente Strategien, Zögern an Entscheidungspunkten).

Die FDA weist zudem darauf hin, dass Zeitmessungen nur dann sinnvoll sind, wenn Geschwindigkeit tatsächlich klinisch relevant ist; andernfalls sollen keine Timing-Kriterien eingeführt werden, da dies die Validierungslogik verfälschen kann (z. B. Fokus auf „schnell“ statt „korrekt“).

Use Errors, Close Calls und Use Difficulties systematisch erfassen

Während der Durchführung des Simulated Use Tests ist es essentiell, Probleme, die während der Interaktion auftreten, detailliert zu dokumentieren. Die FDA unterteilt diese in Use Errors, Close Calls und Use Difficulties.

Use Errors werden als „Nutzerhandlung oder Unterlassung, die von der vom Hersteller erwarteten abwich und ein Ergebnis verursachte, das (1) von dem vom Nutzer erwarteten Ergebnis abwich und (2) nicht ausschließlich durch Geräteausfall verursacht wurde und (3) Schaden (harm) verursachte oder verursachen konnte“ definiert. „Harm“ umfasst ausdrücklich auch compromised medical care.

Bei Close Calls handelt es sich um Fehler, die durch Selbstkorrektur oder zufällige Recovery nicht zu einem final falschen Outcome geführt haben. Close calls sind methodisch besonders relevant, weil sie oft eine erhöhte Fehlerwahrscheinlichkeit anzeigen, auch wenn die Task „formal“ erfolgreich abgeschlossen wurde.

Darüber hinaus sollen Use Difficulties erfasst werden und das nicht nur als „Randnotizen“, sondern als systematische Indikatoren, insbesondere wenn sie wiederholt auftreten oder an sicherheitskritischen Interaktionsstellen konzentriert sind. Die FDA nennt als typische beobachtbare Marker u. a.:

wiederholte Versuche,
Zögern,
Verwirrung,
Suchverhalten.

Knowledge Task Data für nicht beobachtbare „Verstehens“-Tasks

Ein Teil der kritischen Nutzungssicherheit hängt nicht nur von motorischer Bedienung ab, sondern von Wissen und Verständnis, beispielsweise in Bezug auf:

Kontraindikationen,
Warnhinweise,
Umgebungsbedingungen/Vulnerabilitäten,
Wartung oder sicherheitskritische Vorbereitungsschritte.

Solche Aspekte sind aus reinem beobachtetem Verhalten häufig nicht zuverlässig ableitbar – insbesondere dann, wenn der Testaufbau nicht jeden seltenen Kontextfall praktisch darstellen kann. Die FDA empfiehlt hierfür knowledge tasks, also Wissens-/Verständnisaufgaben, die gezielt prüfen, ob Teilnehmende relevante Informationen korrekt interpretieren und passende Entscheidungen treffen würden. Wesentliche methodische Anforderungen dabei:

Einsatz offener, neutral formulierter Fragen (keine Suggestivfragen, keine Multiple-Choice-„Ratehilfe“ als Standard).
Trennung von Beobachtung und Wissensabfrage: Knowledge tasks sollten so platziert sein, dass sie das Verhalten während der Use Scenarios nicht „vorkonditionieren“.
Dokumentation der Informationsgrundlage: Wenn Wissen über Labeling/IFU abgedeckt werden soll, muss erkennbar sein, ob und wie Teilnehmende Zugriff darauf hatten und ob sie die Information tatsächlich finden/interpretieren konnten.

Post-Use Interview als Ergänzung, nicht als Ersatz

Post-use Interviews sind im FDA-Ansatz eine ergänzende Datenquelle. Sie sollen Observational Data vertiefen, dürfen sie aber nicht ersetzen. Interviews dienen insbesondere dazu:

die Ursachen (Root Causes) beobachteter Use Errors/Probleme systematisch zu explorieren,
subjektiv erlebte use difficulties zu erfassen, die ggf. nicht eindeutig beobachtbar waren,
und die Interaktionslogik aus Nutzerperspektive zu verstehen (z. B. mentale Modelle, Erwartungshaltungen, Informationsinterpretation).

Die FDA empfiehlt, Interviews nach Abschluss der Use Scenarios durchzuführen, um die Task-Performanz nicht zu beeinflussen. Dabei ist methodisch entscheidend, dass die Exploration jedes beobachteten Use Errors/Problems systematisch erfolgt – mit offenen, neutralen Fragen (z. B. „Was haben Sie an dieser Stelle erwartet?“; „Wie haben Sie diese Information interpretiert?“; „Was hat Sie zu dieser Entscheidung geführt?“), statt mit bestätigenden oder lenkenden Formulierungen.

Zusätzlich sollten Interviews explizit Raum bieten für:

subjektiv berichtete Schwierigkeiten (auch wenn keine Fehler sichtbar wurden),
wahrgenommene Unklarheiten in Terminologie, Symbolik oder Rückmeldungen,
sowie Gründe für Recovery-Strategien bei close calls.

6Auswertung – Root Cause Analysis und Residual Risk

Im Rahmen der FDA Zulassung positioniert die FDA HF Validation Testing als primär qualitatives Vorgehen: Ziel ist nicht die statistische Häufigkeitsabschätzung, sondern die Identifikation von designbezogenen Ursachen von Use Errors/Problems und die Ableitung wirksamer Risikokontrollen.

Datenaggregation mit dem Ziel der Root Cause Analyse

Die Analyse aggregiert Observational Data, Knowledge Tasks und Interviewdaten und leitet daraus eine Root Cause Analysis und Priorisierung im Verhältnis zur potenziellen Schadensschwere ab. Wesentliche FDA-Erwartungen dabei:

Use Errors/Problems, die serious harm verursachen könnten, erfordern eine klare Analyse, welcher UI-Bestandteil beteiligt war und wie die Interaktion zur Fehlhandlung führte.
Scheinbar offensichtliche Ursachen müssen dennoch im Interview exploriert werden; die Nutzerperspektive kann entscheidende Hinweise liefern.
Werden Änderungen implementiert, kann Retesting erforderlich werden, um die Wirksamkeit zu belegen und neue Risiken auszuschließen.

Residual Risk – wann „akzeptabel“ regulatorisch tragfähig ist

Die FDA stellt klar, dass Geräte nicht vollständig risikofrei sein können; Residual Risk bleibt. Allerdings gilt: Persistierende serious use errors sind in Premarket Submissions grundsätzlich nicht akzeptabel, außer es liegt eine robuste Begründung vor, dass weitere Reduktion nicht praktikabel ist und die Benefits die Risiken überwiegen.

Disclaimer

Die in diesem Fachartikel dargestellten Informationen zu Normen und Richtlinien wurden nach bestem und fundiertem Expertenwissen dargelegt. Sie spiegeln hierbei rein die Meinung des Autors wider. Es kann keine Gewähr für die Vollständigkeit, Aktualität und Richtigkeit der Angaben übernommen werden. Normen und Richtlinien unterliegen regelmäßigen Überarbeitungen und Änderungen, die hier nicht immer unmittelbar berücksichtigt werden können. Dieser Artikel stellt keine verbindliche Beratung dar und ersetzt keine Prüfung der jeweils gültigen Normen und Richtlinien durch qualifizierte Fachpersonen oder offizielle Stellen. Für die Anwendung der Normen und Richtlinien und deren Auslegung sind stets die aktuell gültigen Originaldokumente sowie die zuständigen Organisationen maßgeblich.

Als Human Factors und Usability-Engineering-Spezialisten unterstützen wir von USE-Ing. Sie gerne bei der Planung, Durchführung und Dokumentation von Human Factors Validation Tests in den USA. Sie haben Fragen? Sprechen Sie uns gerne an.