Blog

Autor: Dr.-Ing. Marcus Jenke

HCP Recruiting für Usability Tests: Warum falsche Teilnehmer zum Problem werden

1 HCP Recruiting für Usability Tests: Wenn falsche Teilnehmer zum Problem werden

Usability Tests sind ein zentraler Bestandteil des Usability Engineering Prozesses gemäß IEC 62366-1 und gelten als wesentliche Grundlage für die Bewertung der Gebrauchstauglichkeit von Medizinprodukten. Entsprechend liegt in vielen Projekten ein starker Fokus auf Studiendesign, Use Error Analyse oder die Ausgestaltung realistischer Testaufgaben.

Ein entscheidender Erfolgsfaktor wird dabei jedoch häufig unterschätzt: die Auswahl der richtigen Testpersonen im Rahmen des HCP Recruiting für Usability Tests.

In der Praxis zeigt sich immer wieder ein ähnliches Muster: Unter Zeitdruck und organisatorischen Rahmenbedingungen wird das Recruiting von Healthcare Professionals häufig nach Verfügbarkeit statt nach tatsächlicher Relevanz organisiert.

Typische Konsequenzen:

  • Studien werden mit kurzfristig verfügbaren Personen durchgeführt
  • Die Differenzierung der Zielgruppen bleibt oberflächlich
  • Relevante Nutzungskontexte werden nicht ausreichend abgebildet 
  • Kritische Unterschiede zwischen Nutzergruppen bleiben unberücksichtigt

Parallel dazu bleibt auch der reale Nutzungskontext häufig unterrepräsentiert. Damit entsteht bereits vor Beginn der eigentlichen Studie eine Abweichung zwischen Testumgebung und realer Anwendung.

Diese Vorgehensweise ist nachvollziehbar und in vielen Projekten zunächst notwendig, um Studien überhaupt durchführen zu können. Gleichzeitig führt sie jedoch zu einem strukturellen Problem: Die Qualität der Ergebnisse wird bereits im Recruiting maßgeblich vorgeprägt – häufig ohne dass dies im Projektverlauf unmittelbar sichtbar wird.

1.1 Warum falsche Teilnehmer kritisch sind

Die Aussagekraft von Usability Tests hängt unmittelbar davon ab, ob die eingebundenen Personen die tatsächlichen Nutzer eines Medizinprodukts realistisch repräsentieren. Gerade im Kontext des HCP Recruiting für Usability Tests ist diese Passung entscheidend, da sich klinische Nutzungssituationen stark unterscheiden können.

Unterschiede zwischen Healthcare Professionals zeigen sich nicht nur oberflächlich, sondern betreffen grundlegende Aspekte der Anwendung. Dazu zählen beispielsweise Entscheidungsprozesse, Arbeitsabläufe oder Prioritäten unter Zeitdruck. Eine Pflegekraft auf der Intensivstation agiert unter anderen Bedingungen als eine Pflegekraft im ambulanten Bereich; ein erfahrener Facharzt trifft andere Entscheidungen als ein Assistenzarzt in der Ausbildung.

Diese Unterschiede beeinflussen direkt, wie ein Produkt verwendet wird – und damit auch, welche Use Errors auftreten können.

Werden diese Unterschiede im HCP Recruiting nicht berücksichtigt, entstehen typische Verzerrungen, die sich erst im Nachgang der Studie wirklich zeigen:

  • Kritische Nutzungssituationen werden nicht getestet
  • Relevante Use Errors bleiben unentdeckt
  • Optimierungsmaßnahmen basieren auf Annahmen, die im realen klinischen Einsatz nicht valide sind

Auf diese Weise entsteht eine trügerische Validität. Der Usability Test liefert nachvollziehbare Ergebnisse, bildet jedoch nicht die Realität ab, in der das Produkt später eingesetzt wird. Gerade im Kontext der Medizinprodukteentwicklung kann dies weitreichende Konsequenzen haben.

Usability Engineering fuer Medizintechnik 1

1.2 Auswirkungen auf Regulierung und Risiko

Die Relevanz dieser Problematik wird besonders im regulatorischen Kontext deutlich. Im Rahmen von Human Factors Engineering und Usability Validation wird nicht nur erwartet, dass Use Errors identifiziert und bewertet werden, sondern auch, dass die zugrunde liegenden Studien unter realistischen Bedingungen durchgeführt wurden.

Sowohl FDA Guidelines als auch die IEC 62366-1 fordern explizit, dass Usability Studien mit repräsentativen Nutzergruppen und in realistischen Nutzungskontexten durchgeführt werden. Entscheidend ist dabei nicht nur die Durchführung der Tests, sondern auch die nachvollziehbare Begründung, warum genau diese Teilnehmer ausgewählt wurden.

Wenn diese Anforderungen im HCP Recruiting für Usability Tests nicht erfüllt sind, entstehen konkrete Risiken. Studienergebnisse können in ihrer Aussagekraft eingeschränkt sein, regulatorische Rückfragen treten häufiger auf und im ungünstigsten Fall müssen Studien wiederholt oder ergänzt werden. Der Aufwand verlagert sich damit von einem initial scheinbar effizienten Recruiting hin zu deutlich höheren Kosten im weiteren Projektverlauf.

Vor diesem Hintergrund verschiebt sich die Rolle von Recruiting grundlegend. Es ist nicht länger ein vorbereitender Schritt, sondern ein entscheidender Einflussfaktor auf die regulatorische Belastbarkeit und letztlich auch auf die Sicherheit des Produkts.

Der eigentliche blinde Fleck

Ein zentraler Punkt wird in vielen Projekten erst spät oder gar nicht erkannt: Nicht das Studiendesign ist die häufigste Ursache für unzureichende Ergebnisse, sondern die Auswahl der falschen Teilnehmer.

2 Warum HCP Recruiting für Usability Tests besonders schwierig ist

Die Herausforderungen im HCP Recruiting für Usability Tests & Human Factors Recruiting treten in der Praxis nur selten als isolierte Probleme einzelner Projekte auf. Vielmehr handelt es sich um ein strukturelles Thema, das sich aus den spezifischen Rahmenbedingungen des medizinischen Arbeitsumfelds ergibt. Genau diese Rahmenbedingungen unterscheiden das Recruiting von Healthcare Professionals grundlegend von klassischem UX Recruiting in anderen Branchen.

Ein zentraler Faktor ist die begrenzte Verfügbarkeit von medizinischem Fachpersonal. Healthcare Professionals arbeiten in einem Umfeld, das durch hohe Arbeitsbelastung, Zeitdruck und eine konsequente Ausrichtung auf die Patientenversorgung geprägt ist. Zusätzliche Aktivitäten wie die Teilnahme an Usability Tests müssen daher immer in bestehende klinische Abläufe integriert werden.

Diese Situation wird zusätzlich dadurch erschwert, dass der Zugang zu Healthcare Professionals meist nicht direkt erfolgt. Im Gegenteil: HCP Recruiting für Usability Tests ist häufig durch mehrstufige Zugangsstrukturen geprägt. Zwischen Studienverantwortlichen und potenziellen Teilnehmern liegen oft organisatorische Ebenen wie Klinikleitungen, administrative Prozesse oder interne Freigaben.

Neben Verfügbarkeit und Zugang stellt die Spezialisierung der Nutzergruppen eine weitere zentrale Herausforderung dar. Während Zielgruppen im Recruiting häufig auf einer abstrakten Ebene beschrieben werden, entscheidet in der Realität der konkrete Arbeitskontext über die Relevanz der Ergebnisse.

Für das HCP Recruiting von Teilnehmern für Usability Tests bedeutet das: Eine präzise Differenzierung von Nutzergruppen ist nicht optional, sondern Voraussetzung für valide Studien. Diese hohe Kontextabhängigkeit wirkt sich unmittelbar auf die Qualität von Usability Tests aus. Nur wenn Testpersonen reale Arbeitsabläufe, Entscheidungslogiken und Nutzungssituationen nachvollziehbar abbilden, lassen sich belastbare Erkenntnisse generieren.

In der Praxis entsteht daraus eine komplexe Ausgangssituation: Begrenzte Verfügbarkeit, indirekter Zugang und hohe Spezialisierung wirken gleichzeitig und verstärken sich gegenseitig. Das führt dazu, dass HCP Recruiting nur eingeschränkt planbar ist und häufig einen erheblichen Koordinationsaufwand erfordert.

Diese Dynamik macht deutlich, warum klassische Recruiting Ansätze im MedTech Kontext oft nicht ausreichen. Der eigentliche Aufwand liegt daher weniger im Recruiting selbst, sondern im Aufbau und der Nutzung von Zugangsstrukturen.

Zwischenfazit: Drei strukturelle Ursachen

Die Herausforderungen im HCP Recruiting für Usability Tests lassen sich im Kern auf drei miteinander verknüpfte Ursachen zurückführen:
Eingeschränkte Verfügbarkeit medizinischen Fachpersonals
Indirekter und häufig mehrstufiger Zugang zu geeigneten Teilnehmern
Hohe Spezialisierung und Kontextabhängigkeit der Nutzergruppen
Diese Faktoren wirken nicht isoliert, sondern verstärken sich gegenseitig – und prägen damit maßgeblich die Qualität von Usability Studien.

Die Herausforderungen im HCP Recruiting für Usability Tests lassen sich im Kern auf drei miteinander verknüpfte Ursachen zurückführen: die eingeschränkte Verfügbarkeit medizinischen Fachpersonals, der indirekte und häufig mehrstufige Zugang zu Teilnehmern sowie die hohe Spezialisierung und Kontextabhängigkeit der Nutzergruppen.

Erst im Zusammenspiel dieser Faktoren wird deutlich, warum Recruiting in diesem Umfeld nicht isoliert betrachtet werden kann. Es ist kein einzelner Prozess, der optimiert werden muss, sondern ein komplexes Zusammenspiel aus Zugang, Kontextverständnis und organisatorischer Einbindung.

Vor diesem Hintergrund wird verständlich, warum viele Teams HCP Recruiting für Usability Tests primär als operativen Engpass wahrnehmen. Tatsächlich liegt die Ursache jedoch tiefer – nicht in der Durchführung, sondern in der konzeptionellen Einordnung von Recruiting.

3 Der eigentliche Fehler: Recruiting wird als Task verstanden

In vielen Projekten folgt HCP Recruiting für Usability Tests einem scheinbar klaren und etablierten Ablauf: Zunächst wird der Bedarf definiert, anschließend werden geeignete Teilnehmer gesucht, und im nächsten Schritt wird die Studie durchgeführt. Dieses Vorgehen ist in vielen Bereichen effizient und ausreichend – insbesondere dort, wo Zielgruppen leicht erreichbar und standardisiert beschreibbar sind. Im Kontext von Healthcare Professionals stößt dieses Modell jedoch schnell an seine Grenzen. Die Annahme, dass Recruiting ein klar abgegrenzter und zeitlich begrenzter Prozessschritt ist, greift hier zu kurz. Sie unterschätzt die strukturelle Komplexität, die mit dem Zugang zu medizinischen Nutzergruppen verbunden ist.

Der eigentliche Fehler liegt dabei nicht in einzelnen Recruiting Maßnahmen, sondern in der zugrunde liegenden Perspektive. HCP Recruiting für Usability Tests wird häufig als kurzfristige Aufgabe verstanden, die im Rahmen eines Projekts „gelöst“ werden kann. In der Realität ist es jedoch eng mit Rahmenbedingungen verknüpft, die weit über den eigentlichen Suchprozess hinausgehen.

Dazu gehören insbesondere gewachsene Netzwerke und Kontakte, die über längere Zeiträume aufgebaut werden müssen. Ebenso spielen Beziehungen zu Kliniken, Organisationen und einzelnen Fachpersonen eine zentrale Rolle, da sie oft den entscheidenden Zugang zu potenziellen Teilnehmern ermöglichen. Diese Zusammenhänge führen dazu, dass Recruiting im medizinischen Kontext nicht als isolierter Prozess verstanden werden kann. Es ist Teil eines übergeordneten Systems, das Zugang, Beziehung, organisatorische Rahmenbedingungen und fachliches Kontextverständnis miteinander verbindet.

Intensivpflegekraft

Internationale UX Research Ansätze unterstreichen diese Perspektive, indem sie die Qualität von Studien direkt an die Passung der Teilnehmer knüpfen. Werden im HCP Recruiting für Usability Tests unpassende oder nur teilweise geeignete Personen ausgewählt, entstehen nicht nur methodische Schwächen, sondern auch erhebliche Folgekosten – etwa durch fehlerhafte Entscheidungen oder zusätzliche Studienzyklen.

Gerade im Umfeld regulierter Produkte verstärken sich diese Effekte. Wenn kritische Nutzungssituationen nicht durch die richtigen Nutzergruppen abgebildet werden, bleiben potenzielle Risiken unentdeckt. Gleichzeitig kann die regulatorische Aussagekraft der Studie eingeschränkt sein, wenn die Auswahl der Teilnehmer nicht nachvollziehbar begründet werden kann.

Vor diesem Hintergrund wird deutlich, dass der eigentliche Engpass nicht im Recruiting selbst liegt, sondern in der fehlenden strukturellen Vorbereitung darauf. Organisationen, die HCP Recruiting für Usability Tests ausschließlich projektbasiert denken, geraten zwangsläufig in Situationen, in denen sie unter Zeitdruck auf suboptimale Lösungen angewiesen sind.

Einordnung: Vom operativen Schritt zur strategischen Fähigkeit

Die beschriebenen Herausforderungen weisen auf eine grundlegende Verschiebung hin. Recruiting entwickelt sich von einem operativen Projektbaustein zu einer eigenständigen Fähigkeit, die kontinuierlich aufgebaut und gepflegt werden muss.

Während ein operatives Verständnis darauf abzielt, kurzfristig Teilnehmer zu finden, richtet sich ein struktureller Ansatz auf den langfristigen Aufbau von Zugang. Dazu zählen stabile Netzwerke, kontinuierliche Kontaktpflege sowie ein differenziertes Verständnis relevanter Nutzergruppen.

Nicht mehr: „Wie finden wir Teilnehmer für diese Studie?“,
sondern: „Wie stellen wir sicher, dass wir dauerhaft Zugang zu den richtigen Healthcare Professionals haben?

HCP Recruiting für Usability Tests ist kein isolierter Prozessschritt, sondern eine strukturelle Voraussetzung für valide und belastbare Ergebnisse. Oder zugespitzt formuliert: Das Problem liegt selten im Recruiting selbst, sondern darin, dass es zu spät und zu isoliert gedacht wird.

4 Reframing: Vom Recruiting zum Zugang

Vor dem Hintergrund der bisherigen Betrachtungen wird deutlich, dass die Herausforderungen im HCP Recruiting für Usability Tests nicht in erster Linie durch operative Schwierigkeiten entstehen. Vielmehr liegt die Ursache auf einer konzeptionellen Ebene: in der Art und Weise, wie Recruiting in Organisationen verstanden und eingeordnet wird.

In vielen Fällen wird HCP Recruiting weiterhin als kurzfristige Aufgabe betrachtet, die im Rahmen einer konkreten Studie zu lösen ist. Diese Perspektive erscheint zunächst plausibel und entspricht klassischen Projektlogiken. Im medizinischen Kontext führt sie jedoch regelmäßig an strukturelle Grenzen. Denn die eigentliche Herausforderung besteht nicht darin, Teilnehmer zu identifizieren, sondern darin, Zugang zu den relevanten Healthcare Professionals zu erhalten.

Damit verschiebt sich der Fokus grundlegend:

Der zentrale Engpass liegt nicht im Recruiting selbst, sondern im Zugang zu den richtigen Nutzergruppen.

Dieses Reframing markiert einen entscheidenden Wendepunkt. Während ein klassisches Recruiting Verständnis auf die Durchführung einzelner Studien ausgerichtet ist, rückt ein erweitertes Verständnis den Aufbau stabiler Zugangsstrukturen in den Mittelpunkt. Es geht nicht mehr primär darum, kurzfristig Teilnehmer zu gewinnen, sondern darum, langfristig sicherzustellen, dass relevante Nutzergruppen überhaupt erreichbar sind.

4.1 Was sich durch diesen Perspektivwechsel verändert

Dieser Perspektivwechsel hat direkte Auswirkungen auf die Planung und Durchführung von Usability Tests. Er verändert nicht nur einzelne Prozesse, sondern die zugrunde liegende Logik des HCP Recruiting für Usability Tests.

Die Unterschiede lassen sich wie folgt zusammenfassen:

Klassischer AnsatzNeuer Ansatz
Fokus auf einzelne TeilnehmerFokus auf Zugang zu Nutzergruppen
projektbasierte Planungkontinuierlicher Aufbau von Netzwerken
einzelne Studie im Mittelpunktlangfristige Strategie
operative Aufgabestrukturelle Fähigkeit

Diese Gegenüberstellung zeigt, dass es nicht um eine Optimierung bestehender Prozesse geht, sondern um eine Verschiebung auf eine andere Ebene. Recruiting wird damit nicht ersetzt – sondern neu eingeordnet.

4.2 Warum dieser Perspektivwechsel notwendig ist

Die steigende Komplexität im HCP Recruiting für Usability Tests lässt sich mit klassischen Ansätzen nur noch eingeschränkt bewältigen. Begrenzte Verfügbarkeit, indirekte Zugänge und hohe Spezialisierung führen dazu, dass kurzfristige Lösungen oft unzuverlässig bleiben.

Ein strategischer Umgang mit Zugang ermöglicht es hingegen, diese Faktoren systematisch zu adressieren. Bestehende Kontakte können gezielt ausgebaut werden, Zielgruppen werden differenzierter verstanden und organisatorische Rahmenbedingungen lassen sich frühzeitig berücksichtigen. Dadurch entsteht eine stabilere Grundlage für zukünftige Usability Tests.

5 Was bedeutet das konkret? Erste Handlungsmöglichkeiten

Die Transformation von operativem HCP Recruiting hin zu einer strukturellen Fähigkeit ist kein einmaliger Schritt, sondern ein kontinuierlicher Prozess. Gleichzeitig zeigt die Praxis, dass bereits vergleichsweise kleine Anpassungen im Projektalltag einen spürbaren Einfluss auf die Qualität von Usability Tests haben können. Entscheidend ist dabei, Recruiting nicht isoliert zu betrachten, sondern die Rahmenbedingungen zu verbessern, unter denen es stattfindet.

5.1 Netzwerke frühzeitig und kontinuierlich aufbauen

Ein häufiges Muster besteht darin, dass HCP Recruiting erst dann beginnt, wenn eine Studie konkret geplant ist. In diesem Moment fehlen jedoch oft die notwendigen Zugänge, um geeignete Teilnehmer zu identifizieren. Ein nachhaltiger Ansatz setzt deutlich früher an. Netzwerke sollten nicht projektbezogen aufgebaut, sondern kontinuierlich entwickelt werden. Dabei geht es weniger um die kurzfristige Aktivierung einzelner Kontakte als um den Aufbau belastbarer Beziehungen.

In der Praxis bedeutet das beispielsweise, Kontakte aus früheren Studien aktiv weiterzuführen, Kooperationen mit klinischen Einrichtungen schrittweise auszubauen und Fachveranstaltungen gezielt zu nutzen, um Zugang zu relevanten Nutzergruppen zu entwickeln. Ein solches Netzwerk reduziert nicht nur den operativen Aufwand zukünftiger Studien, sondern erhöht auch die Wahrscheinlichkeit, tatsächlich repräsentative Healthcare Professionals einzubinden.

5.2 Zielgruppen differenziert und kontextbezogen definieren

Ein zweiter zentraler Hebel liegt in der Präzisierung der Zielgruppen. Allgemeine Kategorien wie „Ärztinnen und Ärzte“ oder „Pflegepersonal“ reichen im Kontext von HCP Recruiting für Usability Tests nicht aus, um reale Nutzungssituationen abzubilden.

Für belastbare Ergebnisse ist es notwendig, Zielgruppen entlang konkreter Nutzungskontexte zu beschreiben. Entscheidend sind dabei nicht nur demografische Merkmale, sondern insbesondere Arbeitsabläufe, Verantwortlichkeiten und Erfahrungsniveaus im Umgang mit vergleichbaren Systemen.

Eine fundierte Zielgruppendefinition berücksichtigt daher Aspekte wie typische Workflows, Nutzungssituationen sowie die Einbindung in klinische Prozesse. Diese Kriterien sollten frühzeitig im Screener abgebildet werden, da sie maßgeblich darüber entscheiden, ob die ausgewählten Teilnehmer tatsächlich repräsentativ sind.

5.3 Recruiting‑Kanäle gezielt kombinieren

Ein weiterer wichtiger Schritt besteht darin, HCP Recruiting nicht auf einzelne Zugangswege zu beschränken. Gerade im medizinischen Kontext zeigt sich, dass kein einzelner Kanal ausreicht, um alle relevanten Nutzergruppen zuverlässig zu erreichen.

Erst die Kombination verschiedener Ansätze führt zu stabilen Ergebnissen. Direkte Kontakte ermöglichen Zugang zu realen Nutzungskontexten, bestehende Teilnehmerpools bieten kurzfristige Verfügbarkeit, während externe Partner oder Community-basierte Ansätze zusätzliche Reichweite schaffen. Durch diese Kombination lässt sich sowohl die Erfolgsquote des Recruitings erhöhen als auch die Vielfalt und Qualität der Teilnehmer verbessern.

5.4 Recruiting als kontinuierlichen Prozess verstehen

Der vielleicht wichtigste Schritt besteht darin, HCP Recruiting aus der Logik einzelner Projekte zu lösen. Solange Recruiting ausschließlich als Vorbereitung einer konkreten Studie verstanden wird, bleibt es reaktiv und nur eingeschränkt planbar.

Ein kontinuierlicher Ansatz integriert Recruiting in den laufenden Entwicklungsprozess. Ziel ist es, Wissen über Nutzergruppen systematisch aufzubauen und bestehende Kontakte langfristig zu pflegen.

In der Praxis bedeutet dies beispielsweise den Aufbau eines eigenen Teilnehmerpools, die strukturierte Dokumentation von Teilnehmerprofilen sowie die regelmäßige Aktualisierung von Kontakten. Dadurch entsteht eine verlässliche Grundlage für zukünftige Usability Tests und eine deutlich geringere Abhängigkeit von kurzfristigen Lösungen.

Kleine Schritte mit großer Wirkung

Die beschriebenen Ansätze zeigen, dass ein strategischer Umgang mit HCP Recruiting für Usability Tests nicht zwingend umfangreiche organisatorische Veränderungen erfordert. Bereits gezielte Anpassungen im Umgang mit Netzwerken, Zielgruppen und Prozessen können erhebliche Verbesserungen bewirken.
Der entscheidende Faktor liegt dabei weniger im einzelnen Recruiting Schritt, sondern in der Kontinuität, mit der Zugang zu relevanten Nutzergruppen aufgebaut und gepflegt wird.

Die dargestellten Handlungsmöglichkeiten bilden eine erste Grundlage für die Weiterentwicklung von HCP Recruiting im Usability Engineering. Sie ersetzen keine umfassende Strategie, zeigen jedoch, wie sich strukturelle Verbesserungen schrittweise in bestehende Prozesse integrieren lassen.

Im nächsten Abschnitt werden die zentralen Erkenntnisse des Artikels zusammengeführt und in einen größeren Kontext eingeordnet.

6 Ausblick: Wohin entwickelt sich HCP Recruiting für Usability Tests?

Die Anforderungen an Usability Tests im Bereich der Medizintechnik entwickeln sich kontinuierlich weiter. Insbesondere die gestiegene Bedeutung von Human Factors Engineering im regulatorischen Kontext hat dazu geführt, dass die Erwartungen an die Qualität, Nachvollziehbarkeit und Validität von Studien deutlich zunehmen. Gleichzeitig bleibt der Zugang zu Healthcare Professionals strukturell anspruchsvoll und es ist nicht zu erwarten, dass sich dieser Engpass in absehbarer Zeit grundlegend verändert.

Vor diesem Hintergrund zeichnet sich bereits heute eine Entwicklung ab, in der HCP Recruiting für Usability Tests zunehmend enger mit dem gesamten Entwicklungsprozess verzahnt wird. Statt als vorbereitender Schritt einzelner Studien verstanden zu werden, entwickelt sich Recruiting zu einem integralen Bestandteil von Usability Engineering und Produktentwicklung.

Parallel dazu ist eine zunehmende Professionalisierung im Umgang mit Netzwerken und Teilnehmerstrukturen zu beobachten. Organisationen beginnen, gezielt Beziehungen zu Healthcare Professionals, Kliniken und Versorgungseinrichtungen aufzubauen und über längere Zeiträume zu pflegen. Dabei verschiebt sich der Fokus weg von der reinen Anzahl potenzieller Teilnehmer hin zur Qualität und Differenzierung der Nutzergruppen.

Gleichzeitig gewinnen digitale Werkzeuge an Bedeutung, die eine strukturierte Organisation, Segmentierung und langfristige Nutzung von Teilnehmerdaten ermöglichen. Perspektivisch ist zu erwarten, dass datenbasierte Ansätze und systematische Segmentierung von Nutzergruppen eine zentrale Rolle bei der Weiterentwicklung spielen werden.

In der Gesamtschau wird deutlich, dass sich HCP Recruiting für Usability Tests zunehmend von einer operativen Aufgabe zu einer eigenständigen Kompetenz entwickelt. Organisationen, die frühzeitig beginnen, entsprechende Strukturen aufzubauen und Zugang zu relevanten Nutzergruppen kontinuierlich zu entwickeln, schaffen sich damit eine stabile Grundlage für zukünftige Studien.

Der entscheidende Unterschied wird dabei nicht in einzelnen Methoden oder Tools liegen, sondern in der Fähigkeit, den Zugang zu Healthcare Professionals langfristig und nachhaltig aufzubauen.

HCP Recruiting für Usability Tests wird damit weniger zu einer Frage der kurzfristigen Umsetzung – und zunehmend zu einem strategischen Vorteil, der sich über Zeit entwickelt.

Überarbeitete Conclusion

HCP Recruiting ist weit mehr als ein organisatorischer Schritt im Rahmen einer Usability Studie. Es entwickelt sich zunehmend zu einem zentralen Erfolgsfaktor, sowohl für die Qualität der gewonnenen Erkenntnisse als auch für deren regulatorische Belastbarkeit.

Die eigentliche Herausforderung liegt dabei nicht in der operativen Umsetzung einzelner Recruiting Maßnahmen. Entscheidend ist vielmehr der Zugang zu den richtigen Nutzergruppen. Nur wenn es gelingt, reale Nutzungskontexte durch passende Healthcare Professionals abzubilden, können Usability Tests ihre volle Aussagekraft entfalten.

Organisationen, die Recruiting in diesem Sinne nicht als isolierte Aufgabe, sondern als strategische Fähigkeit verstehen, schaffen die Grundlage für konsistente und belastbare Studienergebnisse. Sie sind nicht nur in der Lage, effizienter auf neue Anforderungen zu reagieren, sondern können auch komplexere und spezialisierte Nutzergruppen systematisch einbeziehen. Weitere Informationen zum Ablauf eines systematischen Rekrutierungs- und Managementprozesses von Healthcare Professionals erhalten Sie hier:

In weiteren Beiträgen wird darauf aufbauend vertieft, wie konkrete Methoden, Kanäle und Strukturen gestaltet werden können, mit dem Ziel, HCP Recruiting langfristig als belastbare und skalierbare Fähigkeit im Usability Engineering zu etablieren.

Häufig gestellte Fragen zu HCP Recruiting für Usability Tests

HCP Recruiting beschreibt die gezielte Auswahl und Ansprache von Healthcare Professionals, die als repräsentative Nutzergruppen an Usability Tests teilnehmen. Ziel ist es, reale Nutzungsszenarien valide abzubilden und belastbare Erkenntnisse zu generieren.

HCP Recruiting beschreibt die gezielte Auswahl und Ansprache von Healthcare Professionals, die als repräsentative Nutzergruppen an Usability Tests teilnehmen. Ziel ist es, reale Nutzungsszenarien valide abzubilden und belastbare Erkenntnisse zu generieren.

  • Auswahl nach Verfügbarkeit statt Relevanz
  • unklare Definition der Zielgruppen
  • fehlende Differenzierung nach klinischem Kontext
  • unzureichendes Screening der Teilnehmer

Die Anzahl hängt vom Studientyp ab. Während formative Tests mit kleineren Gruppen arbeiten, erfordert die summative Evaluation gemäß IEC 62366-1 repräsentative Teilnehmergruppen pro Nutzerprofil.

  • Aufbau eines strukturierten Teilnehmerpool
  • sklare Definition von Nutzerprofilen
  • systematisches Screening
  • langfristige Recruiting-Strategie statt projektbezogener Ad-hoc-Lösungen

Weiterführende Inhalte

Wie erstellt man hazard-related use scenarios und eine Nutzungsrisikoanalyse?

Hazard-related Use Scenarios

Wie identifiziert man hazard-related use scenarios und führt eine Nutzungsrisikoanalyse durch

Was Hersteller über die IEC 62366-1 Anforderungen wissen müssen

April 2026

Executive Summary

Kopie von auditive Visual Haptical Feedback 3

Hazard-related use scenarios gemäß IEC 62366-1 übersetzen Nutzung und Use Errors in eine strukturierte, testbare Form und sind damit ein Kernelement der Nutzungsbedingten Risikoanalyse (Use-related Risk Analysis).
Ausgangspunkt ist eine systematische Task Analysis, um User Interface-Merkmale mit Sicherheitsrelevanz und potenzielle Bedienfehler (Use Errors) zu identifizieren. Darauf aufbauend werden foreseeable und known hazardous situations zusammengeführt, um Risiken sowohl aus plausiblen Interaktionspfaden als auch aus bekannten Problemfeldern abzudecken. Hazard-related use scenarios beschreiben Ereignisketten einschließlich potenzieller Use Errors, die in hazardous situations münden können. Methodisch entscheidend sind der ausreichende Detailgrad in der Darstellung und die saubere Ableitung aus den identifizierten Use Scenarios. Für die Summative Evaluation ist eine begründete, risikobasierte Auswahl der relevanten Szenarien erforderlich.

Die Basis: Identifikation von foreseeable und known hazardous situations

Nutzungsrisikoanalyse (Use-related Risk Analysis) stellt die Verbindung zwischen der Benutzerschnittstelle (User Interface) und dem Risikomanagement her.  Dabei sollte sie zwei Quellen systematisch integrieren:

  • Foreseeable hazardous situations: Situationen, die plausibel aus potenziellen Use Errors entstehen können.
  • Known hazardous situations: Situationen, die aus vorhandenen Daten (z. B. Literatur, Datenbanken, Post-Market-Informationen) bekannt sind.

Die Kombination beider Perspektiven ist wichtig: Die rein projektinterne Analyse kann typische Fehlmuster übersehen, während reine Recherche ohne Interaktionsmodell häufig zu unscharfen, schwer testbaren Aussagen führt.

Methodisch sinnvoll ist, beide Quellen frühzeitig gegeneinander zu spiegeln: Known hazardous situations können als „Reality Check“ dienen (treffen typische Patterns aus dem Feld auf ähnliche UI- oder Workflow-Strukturen?), während foreseeable hazardous situations helfen, bekannte Risiken in produktspezifische, überprüfbare Ketten zu übersetzen. Entscheidend ist dabei, hazardous situations nicht als abstrakte Schlagworte zu führen, sondern als konkrete Situation, in der ein Hazard wirksam wird, z. B. durch falsche Parameterkombination, falschen Patientenbezug, fehlende Monitoring-Reaktion oder verzögerte Alarmwahrnehmung.

Identifikation potenzieller use Errors: Interaktion als Risikotreiber systematisch beschreiben

Während die Identifikation von known hazardous situations eher einer Fleißaufgabe ähnelt, ist eine methodische Vorgehensweise bei der Erarbeitung der foreseeable hazardous situations entscheidend. Hierbei gilt es zunächst potenzielle Use Errors zu identifizieren, die zu hazardous situations führen können, und diese systematisch zu bewerten sowie durch geeignete Maßnahmen zu kontrollieren. Methodisch ist dabei entscheidend, dass Risiken nicht abstrakt formuliert werden, sondern über konkrete Interaktionssequenzen und Nutzungskontexte nachvollziehbar werden.

Ausgangspunkt ist daher eine systematische Beschreibung der Nutzung als Risikotreiber: 

Welche Nutzergruppen führen welche Aufgaben mit welchen Zielen aus, unter welchen Rahmenbedingungen, mit welchen Informationsgrundlagen und mit welchen zeitlichen oder organisatorischen Zwängen

Risk Analysis

Erst wenn diese Nutzungssituation konkret beschrieben ist, lassen sich relevante Fehlhandlungen belastbar ableiten. Dazu gehört nicht nur „was“ getan wird, sondern „wie“ die Interaktion abläuft: 

Welche Anzeigen werden gelesen, welche Bedienelemente werden betätigt, welche Entscheidungen werden getroffen, welche Rückmeldungen werden erwartet und welche Systemzustände sind dabei kritisch. Interaktionsschritte, die im Normalfall trivial erscheinen, können unter realistischen Bedingungen (z. B. Stress, Unterbrechung, Handschuhe, eingeschränkte Sicht, Lärm, Zeitdruck oder Parallelaufgaben) zu systematischen Fehlbedienungen führen.

Task Analysis als Basis der use scenarios

Ein strukturierter Einstieg erfolgt über eine Task Analysis auf Basis erwarteter Aufgaben (anticipated tasks). Dabei wird die Mensch-Produkt-Interaktion schrittweise analysiert, um danach sicherheitsrelevante UI-Merkmale und potenzielle Nutzungsfehler (Use Errors) zu identifizieren. Eine belastbare Task Analysis betrachtet nicht nur „was“ getan wird, sondern auch „unter welchen Bedingungen“ und „mit welchen kognitiven Anforderungen“.

Für die Ableitung sicherheitsrelevanter Aussagen ist es hilfreich, Aufgaben in eine konsistente Struktur zu überführen. Dadurch werden Stellen sichtbar, an denen Nutzer auf kritische Informationen angewiesen sind (z. B. Statusanzeigen, Grenzwerte, Warnhinweise), an denen Werte eingegeben oder bestätigt werden, oder an denen ähnliche Optionen verwechselt werden können. Typische Risikotreiber entstehen besonders dort, wo 

  • mehrere Informationen integriert werden müssen,
  • Handlungen irreversibel sind,
  • Zeitdruck oder Unterbrechungen auftreten, oder
  • die User Interfaces mehrere Zustände ohne eindeutige Zustandsklarheit erlauben.

Eine gute Task Analysis integriert deshalb explizit bestehende Nutzungsumgebungseinflüsse (Use Environment Conditions) und kognitive Anforderungen. Dies wird beispielsweise durch den Einsatz der PCA (Perception, Cognition, Action)-Methodik ermöglicht. 

Stellen Sie sich bei der Erstellung die folgenden Fragen:

  • Welche Arbeitsschritte werden durchgeführt und bedingen welche Handlungen,
  • welche Aufmerksamkeit ist erforderlich (z. B. Monitoring parallel zu einer Intervention), 
  • welche Gedächtnislast entsteht (z. B. Parameterwerte merken, bevor sie eingegeben werden), 
  • welche Interpretationsleistung ist nötig (z. B. Trendkurven vs. Einzelwerte), 
  • welche Wahrnehmungsbedingungen gelten (z. B. Blendung, eingeschränkte Sicht, Handschuhe), und 
  • welche Team- oder Übergabesituationen sind typisch (z. B. Schichtwechsel, Übergabe im OP)? 
  • Zusätzlich sollten Abweichungen systematisch als „kalkulierte“ Variationen betrachtet werden: Welche Schritte werden erfahrungsgemäß abgekürzt, welche Workarounds sind plausibel, welche Routinen entstehen bei erfahrenen Nutzern – und welche Risiken werden dadurch begünstigt?

hazard-related use scenarios formulieren

Die Ableitung von Hazard-related Use Scenarios dient dazu, Nutzungsrisiken in eine überprüfbare Form zu überführen.

Ein Use Scenario beschreibt die Interaktion eines Nutzers mit dem Medizinprodukt, um in einer spezifischen Nutzungsumgebung (Use Environment) ein Ergebnis zu erreichen.

Ein Hazard-related Use Scenario erweitert diese Darstellung um eine Ereignissequenz einschließlich potenzieller Use Errors, die in eine hazardous situation münden kann, kurz gesagt:

Eine Hazard-related Use Scenario gemäß IEC 62366-1 ist ein Use Scenario, das zu einer Hazardous Situation führen kann, insbesondere infolge eines Use Error oder eines Reasonably Foreseeable Misuse (gemäß ISO 14971).

 

Wesentliche Qualitätskriterien sind:

  • Perspektive: Formulierung aus Sicht des Nutzers und des Nutzungskontextes.

  • Detailgrad: Ausreichend detailliert, um Ursachenketten und Interaktionsanforderungen nachvollziehen zu können.

  • Methodische Reihenfolge: Zunächst korrekte Use Scenarios definieren, anschließend daraus hazard-related use scenarios ableiten. Dadurch wird klar, an welcher Stelle der Abweichungspfad entsteht und welche UI-Merkmale oder Kontextfaktoren beitragend sind.

Ein Hazard-related Use Scenario sollte so aufgebaut sein, dass es direkt in Testdesign und Risikodokumentation überführbar ist. Praktisch bedeutet das: 

klare Startbedingungen (Systemzustand, Nutzerrolle),
erwartete korrekte Interaktion,
zugrunde liegende Use Errors und in Relation stehende UI-Merkmale,
Resultierende Hazardous situation, Hazards sowie Harms
die Einschätzung des Schadenschweregrads (Severity Level) in Rücksprache mit dem Riskmanagement
bestehende und zusätzlich zu definierende Risikokontrollmaßnahmen (Risk Control Measures)

Dadurch entsteht ein Szenarioformat, das sowohl argumentierbar (für ISO 14971) als auch testbar (für IEC 62366-1) ist.

Auswahl der Hazard-related Use SCenarios für die Summative Evaluation

Nicht jedes hazard-related use scenario muss zwingend Gegenstand der summativen Evaluation sein. Entscheidend ist ein transparentes, risikobasiertes Auswahlverfahren mit dokumentierter Begründung. Die Auswahl muss zeigen, dass jene Szenarien adressiert wurden, die für die Sicherheit der Nutzung maßgeblich sind. IEC 62366-1 führt drei zulässige Auswahlwege an:

Es werden alle Hazard-related Use Scenarios für die summativen Tests ausgewählt.
Es wird eine Teilmenge von Hazard-related Use Scenarios auf Basis des Schweregrads (Severity Level) des zu erwartenden Schadens (Harm) ausgewählt.
Es wird eine Teilmenge von Hazard-related Use Scenarios auf Basis des Schweregrads (Severity Level) und weiterer, für das Medizinprodukt und den Hersteller spezifischen Umständen ausgewählt.

Die Bedeutung der Schadensschwere wird deutlich. Die Einstufung dieser erfolgt gemäß ISO 14971. Die Normenverfasser haben in der neuesten Überarbeitung viel Spielraum für weitreichende Begründungen ermöglicht. Ein belastbares Auswahlverfahren macht explizit, warum ein Szenario in die Summative Evaluation aufgenommen wird. Entscheidend ist, dass die Auswahl nachvollziehbar dokumentiert ist und klar zeigt, dass die sicherheitskritischen Nutzungsszenarien in der summativen Prüfung abgedeckt wurden und somit im Einklang des Usability Engineering Prozesses für Medizinprodukte steht.

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.

Benedikt Janny

Als Usability-Engineering-Spezialisten unterstützen wir von USE-Ing. Sie gerne bei der Planung, Durchführung und Dokumentation von Nutzungsrisikoanalysen. Sie haben Fragen? Sprechen Sie uns gerne an.

Der USE-Ing. Kompass

Bleiben Sie auf dem richtigen Kurs mit unserem Newsletter

Wie führt man formative usability Evaluationen gemäß IEC 62366-1 durch?

Formative Usability Evaluation

Wie führt man formative usability evaluationen gemäß iec 62366-1 durch?

Was Hersteller wissen müssen

Februar 2026

Executive Summary

Kopie von auditive Visual Haptical Feedback 3

Formative usability Evaluationen sind ein methodischer Kernbestandteil des iterativen User Interface Designs gemäß IEC 62366-1, der normativen Referenz zur Umsetzung der europäischen Medical Device Regulation (MDR). Sie dienen sowohl der kontinuierlichen Verbesserung der Benutzerschnittstelle (Design focus) als auch der frühzeitigen Identifikation sicherheitsrelevanter Use Errors (Safety focus). Geeignete Methoden reichen von Expert Reviews und Cognitive Walkthroughs bis zu frühen simulated-use Usability Tests. Ein User Interface Evaluation Plan unterstützt die Konsistenz, indem er Ziele, Methoden und Kriterien für formative und summative Aktivitäten definiert.

Die Auswertung sollte Beobachtungen zu Use Errors, close calls und use difficulties systematisch mit Ursachenanalysen verknüpfen. Entscheidend ist die Rückkopplung der Ergebnisse in Designiterationen und – sofern sicherheitsrelevant – in die Nutzungsrisikoanalyse. Eine saubere Dokumentation schafft Nachvollziehbarkeit und Traceability über Entwicklungsschritte hinweg. Dieser Artikel erläutert, wie Sie hierbei zielgerichtet und effizient vorgehen sollten.

1Die Funktion formativer Evaluationen im Entwicklungsprozess

Formative usability Evaluationen dienen der iterativen Verbesserung der Benutzerschnittstelle und sind damit ein integraler Bestandteil der User Interface Design Methodology. Im Unterschied zu summativen Nachweisen steht bei formativen Maßnahmen nicht die abschließende Validierung, sondern ein strukturierter Lern- und Optimierungszyklus im Vordergrund. Ziel formativer Evaluationen ist es, Interaktionsprobleme möglichst frühzeitig zu identifizieren und User Interface Designoptimierungen abzuleiten, bevor sie sich in spätere Entwicklungsstände verfestigen und nur noch mit hohem Aufwand korrigierbar sind.

Formative Evaluationen haben zudem eine Risikofunktion. Sie unterstützen die frühzeitige Identifikation potenzieller Use Errors, die zu hazardous situations beitragen könnten, und ermöglichen dadurch eine gezielte Weiterentwicklung der Benutzerschnittstelle, bevor eine summative Bewertung ansteht. Damit tragen formative Evaluationen nicht nur zur Gebrauchstauglichkeit im Sinne effizienter und zufriedenstellender Bedienung bei, sondern auch zur Robustheit der Benutzung in sicherheitskritischen Situationen.

OR Formative Usability Test

2Der Doppelte Zielrahmen: Design focus und Safety focus

Formative Evaluationen lassen sich methodisch entlang zweier Zielrichtungen strukturieren, die sich in der Praxis ergänzen und häufig parallel adressiert werden. Die klare Trennung dieser Perspektiven unterstützt eine präzise Studienplanung, eine zielgerichtete Datenerhebung sowie eine nachvollziehbare Interpretation der Ergebnisse.
  • Design Focus
    Ziel ist die Gewinnung von Erkenntnissen zur Verbesserung der Benutzerschnittstelle während der Entwicklung. Im Vordergrund stehen dabei Aspekte wie Verständlichkeit, Konsistenz, Orientierung, Informationsdarstellung, Arbeitsflussunterstützung und die Reduktion unnötiger kognitiver Belastung. Der Design Focus fragt insbesondere, ob die Benutzerschnittstelle die erwarteten mentalen Modelle der Nutzer angemessen unterstützt, ob Interaktionslogiken intuitiv nachvollziehbar sind und ob Rückmeldungen, Statusanzeigen und Systemreaktionen so gestaltet sind, dass Nutzer Handlungsentscheidungen zufriedenstellend, effektiv und effizient treffen können. Ergebnisse aus dieser Perspektive führen typischerweise zu Designanpassungen, die Bedienbarkeit, Effizienz und Fehlertoleranz verbessern, ohne dass zwingend ein direkter Sicherheitsbezug im engeren Sinne vorliegen muss.
  • Safety Focus
    Ziel ist die Identifikation bislang unbekannter Use Errors, die zu hazardous situations führen könnten. Während der Design Focus häufig auf Optimierung „normaler“ Nutzung abzielt, betrachtet der Safety Focus gezielt jene Interaktionsstellen, an denen Fehlhandlungen plausibel sind und potenziell sicherheitskritische Konsequenzen haben können. Dabei werden nicht nur tatsächlich beobachtete Use Errors betrachtet, sondern ebenso close calls (Beinahe-Fehler), use difficulties oder Strategien, die auf eine erhöhte Fehlerwahrscheinlichkeit hinweisen. Methodisch relevant ist hier insbesondere die Frage, welche beitragenden Faktoren die Fehlbedienung begünstigen (z. B. unklare Rückmeldungen, Mehrdeutigkeiten, ungünstige Sequenzen, unzureichende Fehlerprävention oder -erkennung) und wie sich diese Faktoren durch UI-Designmaßnahmen oder begleitende risk control measures reduzieren lassen.

Diese Differenzierung ist in der Praxis hilfreich, da sie Auswahl, Tiefe und Zeitpunkt geeigneter Methoden steuert. Ein frühes Konzeptreview ist typischerweise stärker im Design Focus verankert: Es überprüft die grundlegende Handlungslogik, Konsistenz, Terminologie, Informationsarchitektur und potenzielle kognitive Belastungen, häufig noch bevor hochauflösende Prototypen verfügbar sind. Ein formativer usability test (z. B. simulated use in einem fortgeschritteneren Entwicklungsstand) kann dagegen stärker auf den Safety Focus ausgerichtet werden: Er adressiert risikorelevante Nutzungspfade, prüft die Robustheit der Benutzerschnittstelle in kritischen Situationen und macht sicherheitskritische Fehlhandlungen sowie close calls empirisch sichtbar.

In der praktischen Umsetzung bedeutet dies, dass formative Evaluationen nicht als „eine Art Test“ verstanden werden sollten, sondern als methodisch abgestufte Sequenz von Aktivitäten. Je nach Entwicklungsphase kann der Schwerpunkt zwischen Design Focus und Safety Focus variieren. Eine explizite Zielzuordnung erleichtert es zudem, Ergebnisse angemessen zu gewichten: Während designbezogene Findings häufig in inkrementelle Optimierungen münden, führen sicherheitsbezogene Findings regelmäßig zu priorisierten Maßnahmen, die unmittelbar in Risikoargumentation und nachfolgende Evaluationsplanung einfließen.

3Team- und Methodenset für formative evaluationen

Die Auswertung formativer Evaluationen erfolgt typischerweise multidisziplinär, da nutzungsbezogene Probleme selten ausschließlich auf „Usability“ im engeren Sinne zurückzuführen sind, sondern häufig aus einem Zusammenspiel von klinischem Anwendungskontext, technischen Randbedingungen, Informationsdarstellung, Arbeitsprozessen und Training entstehen. Entsprechend ist die Einbindung relevanter Stakeholder – beispielsweise aus Engineering, Clinical/Medical, Quality/Regulatory, Risk Management und Design – methodisch vorteilhaft, um Beobachtungen sowohl korrekt einzuordnen als auch in umsetzbare Design- und Risikomaßnahmen zu überführen. Ergänzend ist die Einbindung repräsentativer Nutzer sinnvoll und häufig notwendig, sofern Entwicklungsstand, Zugänglichkeit und Studiensetting dies erlauben. Repräsentative Nutzer ermöglichen insbesondere die Validierung oder Widerlegung von Annahmen über mentale Modelle, Routinen, Kontextfaktoren und typische Fehlerstrategien, die durch rein interne Reviews häufig nur eingeschränkt abbildbar sind.

Aus methodischer Perspektive ist zudem relevant, dass formative Evaluationen je nach Entwicklungsphase unterschiedlich „schwergewichtig“ angelegt werden können. In frühen Phasen stehen häufig schnelle, analytische Methoden im Vordergrund, die mit geringem Prototypreifegrad durchführbar sind. Mit zunehmender Reife der Benutzerschnittstelle verschiebt sich der Schwerpunkt hin zu empirischen Verfahren, um Interaktionsmuster unter realitätsnahen Bedingungen beobachtbar zu machen. In vielen Projekten ist daher ein kombiniertes Vorgehen zielführend: analytische Verfahren zur breiten Identifikation von Schwachstellen und empirische Verfahren zur Bestätigung, Priorisierung und Ursachenanalyse.

Als geeignete Methoden kommen unter anderem in Betracht:

  • Expert Reviews zur schnellen Identifikation offensichtlicher Interaktionsschwächen. Sie ermöglichen eine strukturierte Prüfung der Benutzerschnittstelle auf Inkonsistenzen, Mehrdeutigkeiten, fehlende Rückmeldungen, potenzielle Fehlbedienpfade sowie allgemein bekannte Interaktionsprinzipien oder Heuristiken. 
  • Cognitive Walkthroughs zur Analyse der Arbeitsabläufe und von mentalen Modellen, insbesondere bei komplexen Bediensequenzen oder sicherheitskritischen Entscheidungsstellen. Sie adressieren insbesondere die Frage, ob Nutzer die intendierten Handlungsschritte aus dem User Interface heraus plausibel ableiten können
  • Early-stage usability tests (simulated use) zur Beobachtung realer Interaktionsabläufe auf Prototypständen. Early-stage Tests ermöglichen die empirische Beobachtung von Interaktionsverhalten, einschließlich use difficulties, close calls und potenzieller Use Errors, unter realitätsnahen (simulierten) Bedingungen. Sie sind besonders wertvoll, um tatsächliche Bedienstrategien zu erfassen, die in analytischen Methoden häufig unterschätzt werden (z. B. Workarounds, Abkürzungen, fehleranfällige Routinen, Reaktionen auf Stress oder Ablenkung). Abhängig vom Entwicklungsstand können solche Tests mit Low- bis High-Fidelity-Prototypen durchgeführt werden, wobei sich mit zunehmender Prototypreife auch die Aussagekraft in Bezug auf Timing, Feedback und Interaktionsdynamik erhöht. Gerade für risikorelevante Nutzungspfade bieten simulated-use Tests die Möglichkeit, Hypothesen aus Task Analysis und hazard-related use scenarios empirisch zu prüfen und priorisierte Designänderungen abzuleiten.

4Das formative Vorgehensmodell: Planung, Durchführung, Iteration

Ein wirkungsvolles Vorgehensmodell für formative Evaluationen folgt typischerweise einem wiederholbaren Zyklus aus Planung, Durchführung, Analyse und Iteration. Entscheidend ist, dass formative Aktivitäten nicht als isolierte Einzelmaßnahmen verstanden werden, sondern als gesteuerte Abfolge, deren Ergebnisse nachvollziehbar in Designentscheidungen und – sofern relevant – in die risikobasierte Argumentation einfließen. Der methodische Anspruch besteht darin, die explorative Natur formativer Evaluationen mit einer hinreichenden Struktur zu verbinden, damit Erkenntnisse zuverlässig vergleichbar, priorisierbar und dokumentierbar sind.

Schritt 1: User Interface Evaluation Plan etablieren

Ein User Interface Evaluation Plan bildet die organisatorische und methodische Klammer formativer (und in der Regel auch summativer) Aktivitäten. Er sollte definieren, welche Ziele mit der jeweiligen Evaluation verfolgt werden, welche Methoden eingesetzt werden, welche Evaluationskriterien gelten und wie die Evaluation in die übergeordnete Entwicklungs- und Risikologik eingebettet ist. Besonders wichtig ist die explizite Verknüpfung zu risiko- und szenariobasierten Anforderungen, da sich formative Evaluationen häufig auf spezifische Interaktionspfade, UI-Merkmale oder Nutzungssituationen beziehen, die im Risikokontext relevant sind.

Ein konsistenter Plan verhindert, dass Ergebnisse als „punktuelle Beobachtungen“ stehen bleiben, und schafft stattdessen eine nachvollziehbare Struktur: Welche Fragestellung wurde mit welcher Methode beantwortet? Welche Version des Designs wurde untersucht? Welche Nutzergruppen und Nutzungskontexte wurden adressiert? Diese Klarheit ist auch für spätere Iterationen entscheidend, da nur so erkennbar bleibt, ob Verbesserungen tatsächlich wirksam waren oder ob sich Probleme lediglich verlagert haben.

Schritt 2: Durchführung mit geeigneter Realitätsnähe

Auch formative Tests profitieren von realistischen Aufgaben und plausiblen Kontextbedingungen, jedoch in einer bewusst explorativen Logik. Die Realitätsnähe dient hier nicht primär der regulatorischen Nachweisführung, sondern der Validierung von Annahmen über Nutzung, Entscheidungslogik und Umgebungsbedingungen. Geeignet ist ein Setting, das typische Arbeitsabläufe und relevante Kontextfaktoren hinreichend abbildet, ohne den Fokus auf Lern- und Optimierungsziele zu verlieren.

In der Durchführung ist insbesondere darauf zu achten, dass Aufgabenstellungen so formuliert sind, dass sie reale Handlungsentscheidungen auslösen und nicht nur „UI-Funktionen abprüfen“. Je nach Reifegrad des Prototyps kann die Realitätsnähe über unterschiedliche Mittel hergestellt werden, beispielsweise durch die Simulation relevanter Nutzungssituationen, geeignete Materialien (z. B. Instructions for Use (IFU)-Entwürfe), typische Zeit- und Aufmerksamkeitsbedingungen oder realistische Übergänge zwischen Arbeitsschritten. Gleichzeitig bleibt die formative Logik flexibel: Wenn sich während der Durchführung zeigt, dass zentrale Probleme in einer anderen Interaktionsstelle liegen als erwartet, ist eine Anpassung des Fokus methodisch zulässig, sofern sie transparent dokumentiert wird.

Schritt 3: Analyse der identifizierten Use Problems

Die Auswertung formativer Evaluationen sollte sich nicht auf eine reine Problemauflistung beschränken, sondern konsequent ursachenorientiert erfolgen. Zentral ist die Frage, welche Beobachtungen tatsächlich eine Relevanz für Designentscheidungen besitzen und welche Faktoren die beobachteten Schwierigkeiten erklären. Dazu gehört die strukturierte Betrachtung von:

  • Use Errors (Fehlhandlungen/Unterlassungen mit potenziell risikorelevanten Folgen),

  • close calls (Beinahe-Fehler, die häufig Hinweise auf erhöhte Fehlwahrscheinlichkeit geben),

  • use difficulties (Schwierigkeiten, Verzögerungen, Missverständnisse oder Workarounds).

Eine belastbare Analyse untersucht, welche UI-Merkmale, welche Informationsdarstellungen, welche Interaktionssequenzen oder welche Kontextbedingungen zu den beobachteten Problemen beitragen. Besonders wertvoll ist die Identifikation wiederkehrender Muster: Treten Schwierigkeiten bei mehreren Personen an derselben Stelle auf? Zeigen unterschiedliche Nutzer ähnliche Fehlstrategien? Gibt es typische Korrekturhandlungen (z. B. Rücksprünge, wiederholtes Probieren, Abbruch) als Indikator für unzureichende Systemtransparenz oder fehlende Fehlerprävention?

Die Ursache-Wirkungs-Argumentation sollte so formuliert sein, dass daraus konkrete Designmaßnahmen ableitbar sind. Damit werden formative Ergebnisse zu einem methodischen Entscheidungsinstrument und nicht lediglich zu einer Sammlung an Beobachtungen.

Schritt 4: Designänderungen und Rückkopplung in Risikoaktivitäten

Der zentrale Output formativer Evaluationen sind priorisierte Designänderungen und eine nachvollziehbare Begründung, weshalb diese Änderungen geeignet sind, die beobachteten Probleme zu reduzieren. In der Praxis ist es hilfreich, Designmaßnahmen nicht nur als „Fixes“ zu dokumentieren, sondern als Teil einer strukturierten Iteration: Welche Änderung adressiert welche Ursache? Welche Annahme wird damit verändert? Welche Interaktionsstelle wird stabilisiert?

Parallel dazu ist eine Rückkopplung in die Risikoaktivitäten erforderlich, sofern sich aus den Ergebnissen neue oder bestätigte Use Errors ableiten lassen, die sicherheitsrelevant sein könnten. Dies betrifft insbesondere Fälle, in denen close calls oder use difficulties als Vorläufer potenzieller hazardous situations interpretierbar sind. In solchen Situationen sollten die Erkenntnisse in die Nutzungsrisikoanalyse zurückgespielt werden, um die Risikologik konsistent zu halten und die Grundlage für eine risikobasierte Planung nachfolgender Evaluationen zu stärken.

Damit entsteht ein geschlossener Lernkreislauf: Formative Evaluationen verbessern nicht nur die Bedienbarkeit, sondern stabilisieren zugleich die sicherheitsbezogene Argumentation, indem sie risikorelevante Erkenntnisse frühzeitig sichtbar machen und gezielt in Design- und Risikomaßnahmen überführen.

5Dokumentationsanforderungen

Die Richtlinie sieht eine sorgfältige Auswahl der Teilnehmer, gegebenenfalls Schulungen und Datenerfassung mit dem Schwerpunkt auf die Critical Tasks vor. Die Richtlinie betont, dass Personen, die häufig an Usability-Tests desselben Geräts oder anderer Geräte desselben Herstellers teilnehmen, ausgeschlossen werden sollten. Interessant im Vergleich zu anderen Richtlinien ist, dass die NMPA-Richtlinie explizit eine Begründung erwartet, wenn keine Geräteschulung für die Testteilnehmer erforderlich ist. Die Testberichte sollten detaillierte Angaben zu den Zielen, Simulationsbedingungen, Ergebnissen in Bezug auf Use Errors und damit verbundene Root Causes sowie etwaigen Abweichungen enthalten. 

Formative Evaluationen sind in einer Weise zu dokumentieren, dass die Ergebnisse nachvollziehbar, reproduzierbar im Sinne der methodischen Logik und für nachgelagerte Aktivitäten anschlussfähig sind. In der Praxis erfolgt dies typischerweise über Test- oder Evaluationspläne (Evaluation Protocols) und Berichte (Evaluation Reports), die nicht nur einzelne Beobachtungen festhalten, sondern eine konsistente Argumentationskette von Zielsetzung über Methode bis zur abgeleiteten Maßnahme ermöglichen. Dabei ist weniger die reine Umfangstiefe entscheidend als die strukturierte Transparenz: Dritte sollen verstehen können, warum die Evaluation durchgeführt wurde, wie sie durchgeführt wurde, was beobachtet wurde und welche Schlussfolgerungen daraus methodisch begründet abgeleitet wurden.

Ein vollständiges Dokumentationsset umfasst in der Regel folgende Inhalte:

  • Ziele und Fragestellungen: klare Benennung, ob die Evaluation primär designorientiert, sicherheitsorientiert oder kombiniert ausgerichtet war, und welche UI-Aspekte oder Use Scenarios im Fokus standen.

  • Methodik und Studiendesign: Beschreibung der angewandten Methode(n) (z. B. Expert Review, Cognitive Walkthrough, Usability Test (simulated-use)), inklusive Begründung der Methodenauswahl im Verhältnis zum Entwicklungsstand des User Interface.

  • Stichprobe und Repräsentativität: Charakterisierung der einbezogenen Nutzer bzw. Experten, inklusive relevanter Merkmale in Bezug auf intended user profiles (z. B. Erfahrung, Qualifikation, potenzielle Limitationen), sowie – sofern zutreffend – eine Begründung der Abdeckung und Grenzen der Repräsentativität.

  • Testobjekt und Versionierung: eindeutige Angabe, welche Version der Benutzerschnittstelle bzw. welche Prototypstände bewertet wurden, einschließlich relevanter Begleitmaterialien (z. B. IFU-Entwürfe, Trainingsannahmen).

  • Aufgaben und Szenarien: Beschreibung der verwendeten Aufgabenstellungen, Use Scenarios und Rahmenbedingungen, idealerweise so, dass die Logik der Aufgabenableitung und die beabsichtigte Auslösung bestimmter Interaktionspfade erkennbar wird.

  • Datenerhebung und Auswertelogik: Darstellung, welche Daten erhoben wurden (z. B. Beobachtungen, Fehlerklassifikation, qualitative Notizen), wie Beobachtungen strukturiert wurden und nach welchen Kriterien Interpretation und Priorisierung erfolgten.

  • Ergebnisse in strukturierter Form: konsistente Dokumentation von use errors, close calls und use difficulties, inklusive Kontext, beobachteter Handlungssequenz sowie – soweit möglich – einer Root Cause Analysis bzw. beitragender Faktoren.

  • Abgeleitete Maßnahmen und Designentscheidungen: konkrete, nachvollziehbar begründete Maßnahmen, die aus den Ergebnissen abgeleitet wurden, einschließlich Priorisierung und Begründung, weshalb die Maßnahme geeignet ist, die beobachtete Ursache zu adressieren.

Wesentlich ist dabei die Anschlussfähigkeit: Die weitere Entwicklungsdokumentation sollte nachvollziehbar zeigen, wie formative Ergebnisse in Designentscheidungen und in die Nutzungsrisikoanalyse eingeflossen sind. Dies umfasst insbesondere die Verbindung zwischen beobachteten Problemen, ihrer Ursacheninterpretation und den implementierten oder geplanten Designänderungen.

Darüber hinaus hat die Dokumentation eine wichtige Steuerungsfunktion im Projektverlauf. Sie ermöglicht, über Iterationen hinweg zu prüfen, ob Maßnahmen wirksam waren, ob sich Probleme verlagert haben oder ob neue Risiken entstanden sind. Eine klare Versionierung und eine konsistente Ergebnisstruktur erleichtern zudem die spätere Vorbereitung summativer Evaluationsaktivitäten, da sie sichtbar machen, welche risikorelevanten Interaktionsstellen bereits adressiert wurden und welche Aspekte weiterhin kritisch bleiben.

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.

Benedikt Janny

Als Usability-Engineering-Spezialisten unterstützen wir von USE-Ing. Sie gerne bei der Planung, Durchführung und Dokumentation von Formativen Usability Evaluationen. Sie haben Fragen? Sprechen Sie uns gerne an.

Der USE-Ing. Kompass

Bleiben Sie auf dem richtigen Kurs mit unserem Newsletter

Wie führt man Human Factors Validation Tests im Einklang mit FDA Anforderungen durch?

Human Factors Validierung

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

Kopie von auditive Visual Haptical Feedback 3

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.

Human Factors Testing für FDA Zulassung

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.

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.

Benedikt Janny

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.

Der USE-Ing. Kompass

Bleiben Sie auf dem richtigen Kurs mit unserem Newsletter