Blog

Autor: Dr.-Ing. Marcus Jenke

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

Dr.-Ing. Marcus Jenke
27.02.2026

IEC 62366-1

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

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

Februar 2026

Executive Summary

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?

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.

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.

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

Dr.-Ing. Marcus Jenke
09.02.2026

Formative Usability Evaluation

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

Was Hersteller wissen müssen

Februar 2026

Executive Summary

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.

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

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.

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

Dr.-Ing. Marcus Jenke
09.01.2026

Human Factors Validation

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

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.

Usability-Anforderungen für Medizinprodukte auf dem chinesischen Markt gemäß NMPA

Dr.-Ing. Marcus Jenke
23.09.2025

NMPA Usability Guidance

NMPA Usability-Anforderungen für Medizinprodukte auf dem chinesischen Markt

Was Hersteller wissen müssen

September 2025

Executive Summary

Seit dem 8. Oktober 2024 ist die aktualisierte NMPA Usability & Human Factors Guideline in Kraft. Diese fordert im Rahmen der Medizinproduktezulassung in China klare Nachweise, dass Medizinprodukte sicher bedient werden können – unter Berücksichtigung chinesischer kultureller und sprachlicher Rahmenbedingungen. Dieser Artikel erläutert, welche Produkte betroffen sind, welche Anforderungen gelten und wie Sie diese erfolgreich erfüllen. Hierbei wird die empfohlene Vorgehensweise unserer Experten detailliert und anhand von konkreten Beispielen erläutert.

1Die Rolle der NMPA im Usability-Zulassungsprozess

Bei der zuständigen Aufsichtsbehörde handelt es sich um die National Medical Products Administration (NMPA) – die chinesische Behörde zur Regulierung und Überwachung von Arzneimitteln, Medizinprodukten und Kosmetika. Sie ist seit 2018 die Nachfolgeorganisation der CFDA (China Food and Drug Administration) und Teil der State Administration for Market Regulation (SAMR). Im Zusammenhang mit Medizinprodukten unterhält die NMPA verschiedene nachgeordnete Organisationen und Zentren, darunter das CMDE (Center for Medical Device Evaluation).

Das CMDE ist eine spezielle Einheit innerhalb der NMPA, die die Anzeige- und Zulassungsverfahren für Medizinprodukte aller Klassen technisch prüft und bewertet und auch für das Thema Usability zuständig ist. Ähnlich wie die amerikanische FDA (Food and Drug Administration) hat die NMPA eigene Gebrauchstauglichkeitsanforderungen (Usability Requirements) definiert und diese in Form von Guideline Dokumenten veröffentlicht. Die chinesischen Originaldokumente können Sie hier frei zugänglich herunterladen.

Eine Expertengruppe mit intensiver Mitwirkung durch USE-Ing. Experten hat eine kommentierte, englische Übersetzung des chinesischen Originaltextes erstellt, welches Sie hier frei zugänglich herunterladen können.

2Für welche Produkte gilt die NMPA Usability Guideline?

Die NMPA Usability Guideline ist prinzipiell auf Medizinprodukte aller Klassen anwendbar. Allerdings fordert die Guideline ausschließlich Usability Dokumentation für Medizingeräte der Klassen II und III. In Übereinstimmung mit IEC 62366-1:2015 wird in der Guideline nicht ausdrücklich darauf hingewiesen, dass Kombinationsprodukte aus Arzneimitteln und Medizinprodukten in den Anwendungsbereich fallen. Auf der Grundlage diverser Textpassagen der Guideline (insbesondere Abschnitt VI.(IV)) kann jedoch davon ausgegangen werden, dass die dargelegten Grundsätze auch für alle Medizinprodukte der Klassen II und III gelten, die Teil oder Bestandteil eines als Arzneimittel regulierten Produkts sind. In-vitro-Diagnostik-Reagenzien bleiben vom Anwendungsbereich ausgeschlossen.

Es ist zu erwähnen, dass die chinesische Risikoklassifizierung nicht deckungsgleich mit der US-amerikanischen oder europäischen Klassifizierung ist. Diese Risikoklassifizierung steuert allerdings den Umfang der durchzuführenden Usability-Aktivitäten maßgeblich, insbesondere in Bezug auf Usability Tests mit repräsentativen Anwendern. Die folgende Tabelle zeigt den in der Guideline enthaltenen Produktkatalog für Produkte der high Use-Risk Klasse aus Sicht der NMPA für welche unter bestimmten Voraussetzungen summative Usability Tests durchgeführt werden müssen (siehe Kapitel 3).

Product Name

Cardiac radio-frequency ablation equipment
Cardiac radio-frequency ablation catheter
Radio-frequency ablation equipment for cardiac surgery
Radio-frequency ablation forceps/pen for cardiac surgery
Surgical navigation and positioning system (with robotic arm and end effector)
Endoscopic surgical system
Control system for vascular interventional surgery
Therapeutic ventilator
Home healthcare environment ventilator
External defibrillation equipment

Haemodialysis equipment
Continuous blood purification equipment
Artificial liver device
Implantable circulation assistance equipment
Implantable drug infusion equipment
Syringe pump (Class III)
Needle-free injectors
Infusion pump (Class III)
Insulin pump (Class III)

Tabelle: Produktkatalog für Produkte der high Use-Risk Klasse – aus NMPA Guideline (Stand 10/2024)

3Umfang der Usability Aktivitäten & Dokumentation

Welcher Umfang an Usability Engineering Aktivitäten von der NMPA erwartet wird, hängt vor allem von den folgenden Aspekten ab:

der Nutzungsrisikoklasse des Medizinproduktes (Use-Risk Level)
dem Vorhandensein von vergleichbaren Äquivalenzprodukten, welche sich bereits auf dem chinesischen Markt befinden
Verfügbaren Mensch-Produkt-Interaktionsinformationen über identifizierte Äquivalenzprodukt

In Abhängigkeit dieser Variablen erwartet die NMPA die Einreichung eines der folgenden zwei Dokumente:

Use Error Evaluation Report
Usability Engineering Research Report

Das folgende Ablaufdiagramm schildert das empfohlene Vorgehen zur Bestimmung des Usability Engineering Aufwands.

Im Folgenden werden die Teilschritte im Detail erörtert.

Schritt 1: Bestimmung der Nutzungsrisikoklasse des Medizinproduktes (Use-Risk Level)

Zu Beginn ist das Use-Risk-Level des Produkts zu bestimmen. Hierbei folgt die NMPA dem gängigen Vorgehen sowohl der FDA als auch der IEC 62366-1, indem sie betont, dass aufgrund der meist fehlenden Datengrundlage bei der Risikoklassifikation der Fokus auf den Schweregrad des Schadens und nicht auf die Eintretenswahrscheinlichkeit gelegt werden soll. Insbesondere folgt die NMPA dem Ansatz der bereits durch die FDA bekannten Critical Tasks. Hierbei definiert die NMPA wie folgt:

Der falsche Gebrauch von Medizinprodukten der Klasse II (medium Use-Risk) kann zu leichten Verletzungen führen.
Der falsche Gebrauch von Medizinprodukten der Klasse III (high Use-Risk) kann zu schweren Verletzungen oder zum Tod führen. Dieses Konzept ähnelt dem Critical Task-Ansatz der FDA.

Als Indikatoren für ein high Use-Risk Produkt gelten laut NMPA zudem die folgenden Merkmale:

Völlig neue Anwendungsarten
Lange Einarbeitungszeiten
Verwendung durch Laien
Hohe Komplexität der Bedienung

Darüber hinaus kann das Use-Risk-Level eines Medizinprodukts auch anhand von Post-Market Surveillance Daten und Recalls bestimmt werden:

High Use-Risk-Level: Bei schwerwiegenden, unerwünschten Ereignissen (adverse events) oder Rückrufen (recalls) der Klasse I im Zusammenhang mit Problemen bei der Anwendung ähnlicher Medizinprodukte nach dem Inverkehrbringen.

Medium Use-Risk-Level: Bei unerwünschten, Ereignissen oder Rückrufen der Klasse II im Zusammenhang mit Problemen bei der Anwendung ähnlicher Medizinprodukte nach dem Inverkehrbringen.

Low Use-Risk-Level: Wenn keine unerwünschten Ereignisse oder nur Rückrufe der Klasse III oder keine Rückrufe im Zusammenhang mit Problemen bei der Anwendung ähnlicher Medizinprodukte nach dem Inverkehrbringen vorliegen.

Die Bewertung orientiert sich inhaltlich an der ISO 14971:2019. Ergebnis ist eine Einordnung, ob ein Medizinprodukt mit high Use-Risk-Level vorliegt oder nicht.

Schritt 2: Äquivalenzprodukt-Analyse auf dem chinesischen Markt

Handelt es sich bei dem zu entwickelnden Medizinprodukt um kein Produkt mit high Use-Risk Level, kann der Usability Engineering Prozess verkürzt werden und direkt ein Use Error Evaluation Report angefertigt werden.

Liegt allerdings ein Produkt mit high Use-Risk-Level vor, ist eine Äquivalenzprodukt-Analyse auf dem chinesischen Markt durchzuführen. Hierfür ist eine systematische Recherche durchzuführen, ob im chinesischen Markt bereits äquivalente Produkte vorhanden sind. Relevante Quellen sind insbesondere NMPA-Registrierungen und öffentlich zugängliche Produktinformationen.

Definieren Sie klare Kriterien, womit die Äquivalenz begründet wird. Diese können zum Beispiel die folgenden Aspekte umfassen:

Übereinstimmung in Bezug auf intended use,
Übereinstimmung in Bezug auf intended user profiles,
Übereinstimmung in Bezug auf Funktionsprinzipien und
Übereinstimmung in Bezug auf charakteristischen UI-Merkmalen (Bedienelemente, Anzeigen und Labels)

in Kombination mit äquivalenten Arbeitsaufgaben und -abläufen.

Die Recherche ist nachvollziehbar zu dokumentieren, einschließlich Suchstrategie, herangezogener Quellen, identifizierter Produkte und der Begründungen für Ein- oder Ausschluss. Existiert ein Äquivalenzprodukt in China, sollten gezielt Daten zur Mensch-Produkt-Interaktion bezüglich dieses Produktes erhoben und aufbereitet werden, etwa in Form eines Comparative Evaluation Reports, der Teil des Usability Engineering Research Reports sein kann.

Schritt 3: Summative Usability-Evaluation

Wenn kein Äquivalenzprodukt nachweisbar ist, ist die Validierung in Form eines summativen Usability-Tests vorgesehen. Dies kann sowohl Inhouse als auch durch einen externen Usability Testing Dienstleister (Agentur / Prüflabor) erfolgen. Die NMPA betont hierbei allerdings klar, dass die an der Durchführung beteiligten Personen Expertise auf dem Gebiet des Usability Testing medizinischer Produkte und Geräte besitzen müssen und dass die Evaluation nicht durch Personen erfolgen darf, die Teil des Entwicklungsteams sind oder waren. Die summative Usability-Evaluation ist als validierende Studie anzulegen.

Hierfür sind repräsentative, chinesische Nutzer gemäß den intended user profiles zu rekrutieren. Die NMPA empfiehlt ähnlich wie die FDA die Durchführung des Usability Tests mit 15 Probanden je relevanter Nutzergruppe. Hinsichtlich der Durchführung des Usability Tests ist im Sinne eines simulated use tests auf die realitätsnahe Simulation der Nutzungsumgebung (use environment) zu achten. Dabei sind Labels, Gebrauchsanweisungen und notwendige Produkt-Trainings sind in der vorgesehenen Marktausprägung ebenfalls zu berücksichtigen.

Achten Sie hierbei auch auf ein eventuell notwendiges Trainings-Decay. Analog zu anderen Standards und Guidelines sind Use Errors, Close Calls und Use Difficulties zu erfassen und hinsichtlich Root Causes zu analysieren. In Zusammenarbeit mit dem Risikomanagement ist hierdurch eine ausreichende Datenbasis zum Nachweis der Funktionsfähigkeit der Risk Control Measures und hinsichtlich der Akzeptanz des Restrisikos zu generieren. Sind die Daten ausreichend, gilt es, den Usability Engineering Research Report zusammenzustellen.

4Wie sind der Use Error Evaluation Report und der Usability Engineering Research Report aufgebaut?

Je nach vorliegendem Fall stellt entweder der Use Error Evaluation Report oder der Usability Engineering Research Report die gesamte Argumentationskette und Evidenzlage in Bezug auf den sicheren und effektiven Gebrauch für die NMPA dar. Die folgende Tabelle zeigt die in der Guideline enthaltenen Empfehlungen zur Gliederung der beiden Dokumente:

Use Error Evaluation Report

Basic information
Level of risk of use
Core elements

4a. Analysis of post-market use problems of similar medical devices

5a. Use-risk management

6a. Conclusion

Usability Engineering Research Report

Basic information
Level of risk of use
Core elements

4b. Usability Engineering Process

5b. User interface requirements specification

6b. Use-risk management

7b. Verification and Validation of the User Interface

8b. User interface traceability analysis

9b. User training scheme

10b. Conclusion

Im Folgenden werden die einzelnen Kapitel näher der beiden Dokumente jeweils vertiefend erläutert (Use Error Evaluation Report (a), Usability Engineering Research Report (b).

Kapitel 1: Basic information

Beide Dokumente beginnen mit den Basic Information. Der Inhalt ist mit dem der Use Specification vergleichbar und bezieht sich vor allem auf allgemeine Produktbeschreibungen. Benutzerprofile und die Beschreibung der Nutzungsumgebung (use environment) sind allerdings in Kapitel 3 „Core elements“ aufzuführen.

Kapitel 2: Level of risk of use

Im Kapitel Level of risk of use ist die Herleitung des use risk levels für das vorliegende Produkt klar und nachvollziehbar dazulegen. Dieses Kapitel ist im Vergleich zur IEC 62366-1 und zur FDA Guidance neu und geht über die gängige Dokumentation in der Usability Engineering File hinaus. Ein risikobasierter Ansatz ist zwar auch in IEC 62366-1:2015 hinsichtlich der Auswahl von Hazard-related Use Scenarios oder der Definition von Critical Tasks gemäß FDA Guidance vorhanden, aber hier wird eine ausführlichere Begründung der Risikoeinschätzung gefordert.

Kapitel 3: Core elements

Im Kapitel Core elements fordert die NMPA die Erstellung von Use Scenarios im Sinne einer Abfolge von Mensch-Produkt-Interaktionen. Zusätzlich zu den Anforderungen der IEC-Norm sollten diese auch textliche und/oder bildliche Verweise auf das User Interface enthalten. Die Use Scenarios sollten außerdem detaillierte Beschreibungen der Anwendungssituationen (Use settings) und Umgebungsbedingungen (Environmental conditions) enthalten. Eine wesentliche Erweiterung gegenüber der IEC 62366-1 ist die Einordnung der betrachteten User Tasks entlang von drei zentralen Dimensionen: Kritikalität (Criticality), Dringlichkeit der Bedienung (Operation Urgency) und Häufigkeit der Bedienung (Operation Frequency). Diese detaillierte Einstufung unterstützt im Rahmen der NMPA-konformen Aufgabenanalyse die systematische Identifikation potenzieller Risiken.

Praktische Beispiele zur grundsätzlichen Veranschaulichung der Klassifizierung verschiedener User Tasks

Infusionspumpe
Einstellung der Durchflussrate (Flow Rate)

User Task Klassifizierung:

Critical,
Non-urgent,
Non-frequent

Begründung:

Kritikalität – Die Einstellung der Durchflussrate bestimmt die verabreichte Medikamenten- oder Flüssigkeitsmenge. Ein falsch eingestellter Wert kann zu Über- oder Unterinfusion führen und unmittelbar kritische physiologische Zustände verursachen (z. B. Hypotonie, Hyperkaliämie, Schock, Atemdepression – abhängig vom Wirkstoff). Die Aufgabe ist daher critical.

Dringlichkeit der Bedienung – Die Einstellung wird in der Regel nicht unter Zeitdruck vorgenommen. Sie erfolgt vor Therapiebeginn oder bei planmäßiger Anpassung. Obwohl der potenzielle Schaden hoch ist, besteht üblicherweise kein Sekunden- oder Minutendruck während der Eingabe. Die Aufgabe ist daher non-urgent.

Häufigkeit der Bedienung – Das Einstellen oder Ändern des Flow Rates ist nicht kontinuierlich erforderlich. Es handelt sich um eine episodische Handlung, die beim Start der Infusion oder bei einzelnen Therapieanpassungen ausgeführt wird. Die Aufgabe ist daher non-frequent.

Beatmungsgerät

Sofortige Sauerstoffsteigerung hinzuführen

User Task Klassifizierung:

Critical,
Urgent,
Non-frequent

Begründung:

Kritikalität – Die Sauerstoffkonzentration wirkt unmittelbar auf die Oxygenierung des Patienten. Eine unzureichende Erhöhung des O₂-Anteils kann schnell zu Hypoxie führen, die akute Organschäden oder Kreislaufversagen verursachen kann. Diese Aufgabe ist daher critical.

Dringlichkeit der Bedienung – Die Notwendigkeit zur Erhöhung der Sauerstoffzufuhr entsteht oft plötzlich, z. B. bei Sättigungsabfall, Ateminsuffizienz oder unerwarteter klinischer Verschlechterung. In diesen Situationen muss innerhalb von Sekunden reagiert werden. Die Aufgabe ist daher urgent.

Häufigkeit der Bedienung – Eine sofortige Sauerstoffsteigerung wird nicht routinemäßig durchgeführt. Sie tritt nur bei klinischen Komplikationen oder instabilen Patientenzuständen auf. Damit ist die Aufgabe non-frequent.

Patientenmonitor

Bestätigung eines Alarms

User Task Klassifizierung:

Non-critical,
Non-urgent,
Frequent

Begründung:

Kritikalität – Die Alarmbestätigung beeinflusst nicht unmittelbar die physiologischen Parameter des Patienten. Sie dient der Systeminteraktion, nicht der direkten Therapieanpassung. Der potenzielle Schaden entsteht erst indirekt – etwa durch Alarmmüdigkeit oder übersehen kritischer Alarme. Die Aufgabe ist daher non-critical.

Dringlichkeit der Bedienung – Die Bestätigung eines Alarms ist nicht zeitkritisch, da die klinisch relevante Handlung (z. B. Intervention bei kritischem Zustand) unabhängig von der Alarmquittierung erfolgen muss. Die Bestätigung dient primär der Alarmverwaltung und nicht der unmittelbaren Patientenstabilisierung. Die Aufgabe ist daher non-urgent.

Häufigkeit der Bedienung -Alarmquittierungen treten in klinischen Umgebungen – insbesondere auf Intensivstationen – sehr häufig auf. Die hohe Alarmrate führt zu regelmäßiger Interaktion mit dem Alarminterface. Die Aufgabe ist daher frequent.

Kapitel 4a : Analysis of post-market use problems of similar medical devices

Dieser Analysebericht kann im Zuge einer klinischen Literaturrecherche erstellt werden und enthält dabei üblicherweise Angaben zum Untersuchungsgegenstand der Recherche (dem Medizingerät), zum Ablauf und Inhalt der Recherche (Wie wurde vorgegangen und welche Quellen wurden durchsucht?) sowie zu den erzielten Ergebnissen (hier ist eine Dokumentenliste zu erstellen sowie Volltexte mit einzureichen). In der Regel sollte die Recherche die vergangenen fünf Jahre abdecken. Es ist zu beachten, dass der Umfang der Literaturrecherche sowohl die wichtigsten globalen Datenbanken zu Vorkommnissen (adverse events) und Produktrückrufen (recalls) medizinischer Geräte als auch chinesische und internationale Literaturdatenbanken umfassen sollte.

Kapitel 4b : Usability engineering process

Die NMPA fordert in diesem Kapitel die Veranschaulichung des projektspezifischen Usability-Engineering-Prozesses anhand eines Flussdiagramms. Ein Inhaltsverzeichnis für die Usability-Engineering-Akte soll ebenfalls zur Verfügung gestellt werden, sowie eine kurze Beschreibung der Inhalte und Anforderungen jeder im Prozess durchgeführten Aktivität.

Kapitel 5a & 6b: Use-risk management

Die NMPA-Richtlinie fordert die Einreichung der Risikomanagementdokumentation für das zuzulassende Medizingerät inklusive der klaren Kennzeichnung der darin enthaltenen nutzungsbezogenen Risiken (use-related risks). Alternativ kann eine eigene nutzungsbezogene Risikomanagementakte eingereicht werden. Das nutzungsbezogene Risikomanagement sollte eine Analyse der bereits auf Grund von Post-market Surveillance Daten bekannten Use Errors ähnlicher Medizinprodukte enthalten. Zudem sollte es eine umfassende Risikoanalyse aller bekannten Use Errors des eingereichten Medizinprodukts sowie der jeweiligen Risikokontrollmaßnahmen (risk control measures) abdecken, um nachzuweisen, dass das verbleibende nutzungsbezogene Restrisiko akzeptabel ist.

Kapitel 5b: User interface requirements specification

Hier wird die Darlegung der Spezifikationen der User Interface Anforderungen des Medizingerätes gefordert, was vergleichbar mit Kapitel 5.6 der IEC 62366-1:2015/AMD1:2020 ist. Wenn keine separate Spezifikationsdatei für die Benutzerschnittstelle vorliegt, kann die Produktspezifikationsdatei unter Angabe der enthaltenen User Interface Specification vorgelegt werden.

Kapitel 7b: Verification and Validation of the User Interface

Die NMPA fordert hier, den Inhalt und die Anforderungen der Evaluationsaktivitäten im Zusammenhang mit der Verifizierung und Validierung des User Interfaces des Medizingerätes zu beschreiben. Der Begriff „Verfication“ wird größtenteils mit der formativen Evaluation und „Validierung“ mit der summativen Evaluation gleichgesetzt. Im Vergleich zu anderen Normen und Richtlinie ist hervorzuheben, dass die NMPA-Richtlinie die Vorlage einer User Interface Verification fordert, was sinngemäß der formativen User Interface Evaluation des Medizingerätes entspricht. Wird eine vergleichende Bewertung (comparative evaluation) mit einem Äquivalenzprodukt durchgeführt, ersetzt diese den Plan und den Bericht des summativen Usability-Tests.

Kapitel 8b: User interface traceability analysis

An dieser Stelle wird die Erstellung und Einreichung eines User Interface Traceability Analysis Report gefordert, der die Beziehungen zwischen den Anforderungen an die Benutzerschnittstelle (User Interface), dem Design, der Verifizierung (formative Evaluationen) und Validierung (summative Evaluation) sowie dem Risikomanagement transparent und nachvollziehbar macht.

Das Kapitel 8b „User interface traceability analysis“ ist im Vergleich zu anderen gängigen Usability-Normen und -Richtlinien ein Novum. Wir empfehlen die Ausarbeitung einer Matrix-Struktur, welche alle zuvor genannten Aktivitäten aufzeigt und in Referenz setzt. Dies wird durch ausführliche Beschreibungen der Zusammenhänge zwischen den einzelnen Aktivitäten ergänzt, die erläutern, wie die einzelnen Aktivitäten ineinandergreifen.

Kapitel 9b: User training scheme

Falls zutreffend soll hier ein Trainingsschema für das zuzulassende Medizingerät ausgearbeitet werden, welches den Anwendertrainingsplan (User Training Scheme), die verwendeten Materialien, Methoden und Trainer erläutert sowie die Evaluation der Trainingseffektivität nachweist.

Kapitel 6a & 10b: Conclusion

Hier ist abschließend kurz der gesamte Usability-Engineering-Prozess zu beschreiben, quasi in Form einer Management Summary. Insbesondere ist darzulegen, inwiefern die nutzungsbezogenen Restnutzungsrisiken auf ein akzeptables Maß reduziert wurden, und die Sicherheit und Effektivität des User Interfaces gegeben ist.

5Wann sind Usability-Tests in China durchzuführen?

Ob summative Usability-Tests mit dem Medizingerät durchzuführen sind, ergibt sich aus der in Kapitel 3 „Umfang der Usability Aktivitäten & Dokumentation“ beschriebenen Entscheidungslogik, wobei Use-Risk-Level und verfügbare Datenbasis in Bezug auf Äquivalenzprodukte entscheidend sind. Bei Produkten mit high Use-Risk und ohne belastbares Äquivalenzprodukt erwartet die NMPA in der Regel eine summative Usability-Evaluation in Form von simulated use tests mit chinesischen Anwendern in einem ausreichend simulierten chinesischen Nutzungskontext / Simulationsumgebung. Die Richtlinie fordert mindestens 15 chinesische Teilnehmer pro relevanter Benutzergruppe, um Use Errors verlässlich zu identifizieren.

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 Test-Teilnehmer 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.

Steht fest, dass Usability-Tests in China erforderlich sind, stellt sich die Frage nach der praktischen Umsetzung. Die NMPA schreibt kein konkretes Qualifikationsprofil vor, formuliert aber klare Anforderungen an die Qualifikation und Unabhängigkeit der die Tests durchführenden Personen – Die Evaluation soll von Personen mit nachweisbarer Erfahrung im Usability Testing von Medizinprodukten geplant, durchgeführt und ausgewertet werden. Stark in die Entwicklung involvierte Mitglieder des herstellenden Unternehmens sollen nicht mit der Durchführung betraut werden.

Für internationale Hersteller haben sich in der Praxis im Wesentlichen zwei Umsetzungsmodelle etabliert:

Auf China-spezialisierte Usability-Prüflabore
Durchführung der Studie durch Partner mit erfahrenem Usability-Testing Personal und eigener Infrastruktur (Labore, Rekrutierungspanel), enger inhaltlicher Abstimmung mit dem zentralen Usability-Team des Herstellers.
Herstellerinterne Durchführung über lokale Niederlassungen
Durchführung in einer chinesischen Niederlassung oder einem unternehmenseigenen Usability-Labor, sofern die moderierenden Personen unabhängig vom Entwicklungsteam sind und über ausreichende Erfahrung im Usability Testing verfügen; häufig in Kombination mit externer Beratung zur NMPA-konformen Dokumentation.

Für die chinesische Behörde ist dabei weniger entscheidend, ob die Studie in einem Herstellerlabor, bei einem externen Prüflabor oder in einem Krankenhaus durchgeführt wird, sondern ob Design, Durchführung und Dokumentation der Evaluation nachvollziehbar zeigen, dass unter chinesischen Bedingungen alle Critical Tasks sicher beherrscht werden. Eine klare Dokumentation der Rollen (wer plant, moderiert, wertet aus), der Qualifikation der Beteiligten und der Schnittstellen zum Risikomanagement ist daher ein wesentlicher Bestandteil der einzureichenden Dokumentation.

6Fazit - So gelingt die Usability Dokumentation für die Zulassung auf dem Chinesischen Markt

Die „Guideline for Registration Review of Usability Engineering of Medical Devices“ der NMPA ist die zentrale Referenz für die Bewertung der Gebrauchstauglichkeit im chinesischen Zulassungsverfahren. Für Hersteller mit etabliertem Usability-Engineering-Prozess gemäß 62366-1:2015 bedeutet dies: Der grundlegende Ablauf – Use Specification, risikobasierte Use Scenarios, formative und summative Untersuchungen – bleibt vertraut. Die NMPA verschiebt den Schwerpunkt jedoch von einem primär internen Usability Engineering File hin zu prüffähigen Dokumenten, die im Dossier eigenständig bestehen müssen (Use Error Evaluation Report bzw. Usability Engineering Research Report). Die in Kapitel 4 dargestellte empfohlene Gliederung dieser Dokumente spiegelt genau diese Dossier-Orientierung wider.

Für eine erfolgreiche Zulassung in China reicht es deshalb nicht, einen bestehenden IEC-62366-1-Prozess einfach „mit einzureichen“. Entscheidend ist, dass Hersteller ihren Usability-Nachweis konsequent in den NMPA-Rahmen übersetzen: mit klarem Use-Risk-Level, nachvollziehbarer Entscheidungslogik (Use Error Evaluation Report vs. Usability Engineering Research Report), gegebenenfalls China-spezifischen summativen Usability Tests sowie prüffähiger Dokumentation im Registrierungsdossier. Hersteller, die entsprechend systematisch vorgehen, erhöhen nicht nur ihre Chancen auf eine zügige Marktfreigabe. Sie stellen auch sicher, dass ihre Produkte im chinesischen Alltag von den richtigen Nutzergruppen sicher und effektiv gemäß Kennzeichnung verwendet werden – und positionieren sich damit nachhaltig in einem der wichtigsten MedTech-Märkte der Welt.

Disclaimer

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

Go to blog

Blog

Autor: Dr.-Ing. Marcus Jenke

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

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

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

Executive Summary

Die Basis: Identifikation von foreseeable und known hazardous situations

Identifikation potenzieller use Errors: Interaktion als Risikotreiber systematisch beschreiben

Task Analysis als Basis der use scenarios

hazard-related use scenarios formulieren

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

Disclaimer

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?

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

Was Hersteller wissen müssen

Executive Summary

1Die Funktion formativer Evaluationen im Entwicklungsprozess

2Der Doppelte Zielrahmen: Design focus und Safety focus

3Team- und Methodenset für formative evaluationen

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

Schritt 1: User Interface Evaluation Plan etablieren

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

Schritt 3: Analyse der identifizierten Use Problems

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

5Dokumentationsanforderungen

Disclaimer

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?

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

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

Executive Summary

1Regulatorischer Kontext und Zielsetzung

2Critical Tasks als testleitende Einheit DER HUMAN FACTORS VALIDierung

3Erarbeitung des HUMAN FACTORS Validation Test Protocol (Testplan)

Zentrale Anforderungen der FDA an das Studiendesign

Realismusprinzip und Testumgebung

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

Labeling und IFU als Teil der finalen User Interface

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

4Stichprobe und TRAINING

Repräsentativität und relevante Merkmalsvariabilität

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

5Datenerhebung – Observational Data, Knowledge Tasks, Post-Use 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.

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.

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

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

6Auswertung – Root Cause Analysis und Residual Risk

Datenaggregation mit dem Ziel der Root Cause Analyse

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

Disclaimer

Der USE-Ing. Kompass

Bleiben Sie auf dem richtigen Kurs mit unserem Newsletter

Usability-Anforderungen für Medizinprodukte auf dem chinesischen Markt gemäß NMPA

NMPA Usability-Anforderungen für Medizinprodukte auf dem chinesischen Markt

Was Hersteller wissen müssen

Executive Summary

1Die Rolle der NMPA im Usability-Zulassungsprozess

2Für welche Produkte gilt die NMPA Usability Guideline?

3Umfang der Usability Aktivitäten & Dokumentation

4Wie sind der Use Error Evaluation Report und der Usability Engineering Research Report aufgebaut?

Kapitel 1: Basic information

Kapitel 2: Level of risk of use

Kapitel 3: Core elements

Praktische Beispiele zur grundsätzlichen Veranschaulichung der Klassifizierung verschiedener User Tasks

Kapitel 4a : Analysis of post-market use problems of similar medical devices

Kapitel 4b : Usability engineering process

Kapitel 5a & 6b: Use-risk management

Kapitel 5b: User interface requirements specification

Kapitel 7b: Verification and Validation of the User Interface

Kapitel 8b: User interface traceability analysis

Kapitel 9b: User training scheme

Kapitel 6a & 10b: Conclusion

5Wann sind Usability-Tests in China durchzuführen?