Blog

Autor: Dr.-Ing. Marcus Jenke

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

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 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

November 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.

Anpassen des Usability Engineering Prozesses gemäß IEC 62366-1

Dr.-Ing. Marcus Jenke
15.08.2025

IEC 62366-1

Effektives Anpassen des Usability Engineering Prozesses nach IEC 62366-1

Wie viel Aufwand ist wirklich erforderlich?

April 2025

Executive Summary

Dieser Artikel beleuchtet, wie sich der medizintechnische Usability-Engineering-Aufwand situationsgerecht anpassen lässt, ohne dabei die regulatorischen Anforderungen aus dem Blick zu verlieren. Der internationale Standard IEC 62366-1:2015 spezifiziert Anforderungen für den Usability-Engineering-Prozess im Rahmen der Entwicklung von Medizinprodukten. Er fokussiert sich auf die Reduktion von Anwendungsfehlern (Use Errors), die durch unzureichende Gebrauchstauglichkeit (Usability) entstehen können, und somit letztendlich ein Risiko für Patienten, Anwender oder Dritte darstellen. Dabei ist die Norm bewusst prozessorientiert aufgebaut, um unterschiedlichen Gerätetypen, Risikoniveaus und Entwicklungsumfängen gerecht zu werden. Und genau deshalb bietet die Norm einen gewissen Gestaltungsspielraum, um den Umfang der Usability Engineering Aktivitäten anzupassen und auf das jeweilige Entwicklungsprojekt maßzuschneidern.

Die Anpassung des Usability Engineering Aufwands (im Englischen auch häufig „Tailoring“ genannt) ist ein integraler und notwendiger Aspekt der Anwendung der IEC 62366-1 auf Medizinprodukte. Sie ermöglicht es Herstellern, den Usability Engineering Prozess an die spezifischen Merkmale des Medizinprodukts, insbesondere seiner Benutzerschnittstelle (User Interface), und seiner vorgesehenen Nutzung anzupassen. Durch die Berücksichtigung von Faktoren wie beispielsweise der vorherrschenden Komplexität des User Interfaces oder der Schwere des potenziellen, durch die Nutzung bedingten Schadens kann ein Hersteller Argumente ableiten, um einen angepassten, effizienten und dennoch umfassend sicheren Usability Engineering Prozess zu implementieren. Wie hierbei praktisch vorzugehen ist, wird in vorliegendem Fachartikel detailliert erläutert.

1Ziel der Aufwandsanpassung

Das Tailoring (Anpassen des Umfangs) dient dem Ziel, den Usability-Engineering-Prozess in Relation zur Art des Produkts, zum Risikoniveau und zum Nutzungskontext durchzuführen. Dabei sind vor allem Aktivitäten in voller Tiefe durchzuführen, die für die Identifikation und Risikominimierung potenzieller Use Errors notwendig sind. Der Aufwand für Dokumentation, Analyse und Evaluation lässt sich somit effizient skalieren, ohne auf zentrale Erkenntnisse zu verzichten.

Bei der Anpassung des Usability Engineering Aufwands ergibt sich für den Hersteller somit die Möglichkeit, gewisse Aktivitäten maßzuschneidern. Gleichzeitig bleibt der Hersteller allerdings in der Verantwortung die bestehenden Sicherheitsanforderungen im Rahmen der Medizinprodukteentwicklung sicherzustellen. Nimmt man eine solche Prozessanpassung vor, ist es also essentiell zu wissen, warum die jeweilige Anpassung möglich ist. Jede Anpassung sollte mit entsprechenden Argumenten hinterlegt und dokumentiert werden. Das übergeordnete Ziel bleibt – die Herstellung sicherer und effektiver Medizinprodukte.

3Welche Faktoren beeinflussen die Anpassung und das Ausmaß der Usability Aktivitäten?

In Kapitel 4.3 der IEC 62366-1:2015 nennt der Standard mehrere Faktoren, die als Begründung für eine Anpassung des Usability Engineering Prozessaufwands im Rahmen einer vorliegenden Medizinprodukteentwicklung angeführt werden können. Dabei kann sowohl das Maß an Aufwand sowie die Auswahl der Methoden und Werkzeuge, die zur Durchführung des Usability Engineering Prozesses verwendet werden, anhand der folgenden Faktoren angepasst werden:

Umfang und Komplexität der Benutzerschnittstelle (User Interface): Der Standard erwähnt, dass der Umfang und die Komplexität des User Interfaces als Argumentationsgrundlage für die Anpassung des Usability Engineering Aufwands angeführt werden können. So erfordert ein komplexeres User Interface typischerweise einen höheren Usability Engineering Aufwand, um relevante Use Errors zu identifizieren und zu mitigieren, als ein einfaches. Die Begriffe „Umfang“ und „Komplexität“ lassen sich hierbei verschiedenartig interpretieren und können unter anderem Aspekte wie Heterogenität oder Anzahl der Interaktionselemente beinhalten.

Schweregrad des Schadens, der mit dem Gebrauch des Medizinprodukts verbunden ist: Dies folgt der Argumentationsgrundlage, dass Produkte, deren Fehlbedienung zu schwerem Schaden führen kann, einen intensiveren Usability Engineering Prozess zur Risikominimierung durchlaufen sollten, als Produkte mit einem potenziell niedrigen Schadensschweregrad. Antworten liefern hier vor allem die Schweregraddefinitionen der hausinternen Risikomatrix sowie die detaillierte Analyse der hazard-related use scenarios.

Ausmaß oder Komplexität der Use Specification: Eine breite oder umfangreiche Variation an vorgesehenen Anwendungen, Nutzern oder Nutzungsumgebungen deuten auf die Notwendigkeit eines hohen Usability Engineering Prozessaufwands hin, während einfache Gebrauchsspezifikation mit nur einer Nutzergruppe und einer klar abgrenzbaren Nutzungsumgebung gegebenenfalls einen geringeren Aufwand rechtfertigen können.

Vorhandensein einer Benutzerschnittstelle unbekannter Herkunft (UOUP): Besitzt ein Medizinprodukt eine Benutzerschnittstelle unbekannter Herkunft gemäß der UOUP Definition in IEC 62366-1:2015 (Annex C) kann der dort dargelegte, deutlich reduzierte Usability Engineering Prozess angewendet werden, um die Aufwände zu reduzieren. Vereinfacht gesagt, handelt es sich bei einer UOUP um eine Benutzerschnittstelle von einem bereits entwickelten Medizinprodukt, für das keine ausreichenden Aufzeichnungen des Usability Engineering Prozesses nach der aktuellen Norm verfügbar sind. Hierbei gilt es allerdings genau hinzuschauen und die in der Norm definierten Voraussetzungen für die Anwendung des UOUP-Prozesses exakt zu prüfen, bevor man sich auf diesen Pfad begibt.

Ausmaß der Änderung an einem bestehenden User Interface eines Medizinprodukts, das dem Usability Engineering Prozess bereits unterzogen wurde: Bei geringen Modifikationen bereits gemäß Usability Engineering Prozess zugelassener Medizinprodukte kann der Usability Engineering Aufwand auf die geänderten Elemente der Benutzerschnittstelle und deren Auswirkungen auf die Nutzung des Produkts konzentriert werden. Wenn die Modifikationen die Benutzerschnittstelle und die Use Specification nicht beeinflussen, ist möglicherweise kein zusätzlicher Usability Engineering Aufwand erforderlich. Entscheidend ist hierbei oft die Frage: Führt die Modifikation zu neuen potenziellen Use Errors, die zu Risiken in einem nicht-akzeptablen Bereich führen?

Nachdem die grundlegenden Faktoren zuvor andiskutiert wurden, welche als Argumentationsgrundlage für eine Anpassung des Usability Engineering Prozesses herangezogen werden können, wird dies im Folgenden anhand von praktischen Beispielen verdeutlicht.

2Die Grundlage der Anpassung

Da Medizinprodukte und ihre Benutzerschnittstellen (User Interfaces) in Bezug auf Komplexität, Nutzungsumgebung und potenzielle Risiken stark variieren können, ist es nicht immer notwendig oder praktikabel, den Usability Engineering Prozess in identischem Umfang für jedes Produkt anzuwenden. Die IEC 62366-1:2015 erkennt dies an und erlaubt eine Anpassung des Usability Engineering Aufwands. Die Begründung hierfür liegt in der Notwendigkeit, den Prozess flexibel zu gestalten, um ihn an die spezifischen Merkmale des Medizinprodukts und seiner beabsichtigten Nutzung anzupassen. Die regulatorische Basis liefert Kapitel 4.3 „Tailoring of the usability engineering effort“ der IEC 62366-1:2015, welche diese Anpassungsmöglichkeit explizit thematisiert.

4Praktische Anwendungsbeispiele

Um die zuvor theoretisch dargelegten Faktoren praktisch zu verdeutlichen, werden im Folgenden zwei Medizinprodukte mit sehr unterschiedlichen Benutzerschnittstellen und Nutzungskontexten verglichen.

Als Beispiel für ein Medizinprodukt mit einer Benutzerschnittstelle, die einen geringen Usability Engineering Aufwand rechtfertigen könnte, wird eine Lanzette zur Blutzuckermessung herangezogen. Mögliche Argumentationsansätze könnten die folgenden Aspekte umfassen:

User Interface geringer Komplexität: Man könnte argumentieren, dass die Benutzerschnittstelle dieses manuell bedienbaren Stechhilfegerätes zur kapillaren Blutentnahme bei Diabetikern zumeist aus einem mechanischen Auslöseknopf und einer einfachen Tiefeneinstellung durch Drehmechanismus besteht. Zudem besitzt das Gerät keine Softwarebestandteile. Somit beschränkt sich die Mensch-Produkt-Interaktion auf wenige, klar definierte Schritte.
Geringer anzunehmender Schadensschweregrad: Die Analyse identifizierter hazard-related use scenarios könnte einen geringen bis mittleren Schadensschweregrad ergeben (z. B. leichte Verletzung ohne Notwendigkeit einer medizinischen Behandlung sowie ein geringes Infektionsrisiko).
Geringe Komplexität der Use Specification: Man könnte argumentieren, dass die Benutzerprofile klar definierbar sind und Benutzer in der Regel mit dem Gerät vertraut sind.

Die Betrachtung eines integrierten Anästhesie-Arbeitsplatzes mit Beatmung, Monitoring, Gasversorgung und Touchscreen-Steuerung könnte hingegen zum Ergebnis kommen, dass umfangreiche Usability Engineering Aktivitäten notwendig sind. Diese Erkenntnis beruht auf den folgenden Punkten:

User Interface hoher Komplexität: Das Medizinprodukt besitzt ein breites Spektrum an Benutzerschnittstellen. So kann dies neben mehreren Displayebenen mit Touchsteuerung ein Alarmsystem sowie numerische Eingaben umfassen.
Hoher anzunehmender Schadensschweregrad: Die Analyse der hazard-related use scenarios ergibt Schadensschweregrade im hohen bis kritischen Bereich (z. B. im Zusammenhang mit fehlender Beatmung beim Einleiten der Narkose oder der Verzögerung lebensrettender Maßnahmen) als Folge möglicher Use Errors.
Hohe Komplexität der Use Specification: Die Bedienung dieses Medizinproduktes erfolgt wahrscheinlich durch verschiedene Nutzergruppen. Die Use Specification könnte also mehrere intended user profiles, wie zum Beispiel Anästhesisten, Pflegepersonal oder Techniker, die wiederum konfigurierbare, hoch individuelle Benutzerprofile bedingen, umfassen.

Der kurze Vergleich dieser Medizinprodukte verdeutlicht, wie unterschiedlich die Bewertung der einzelnen Faktoren ausfallen kann. Somit ergibt sich ein entsprechender Spielraum für die Anpassung des Usability Engineering Umfangs.

5Wie geht man vor und welche Aktivitäten können angepasst werden?

Der Standard sowie der zugehörige technische Report IEC TR 62366-2:2016 deuten auf Aktivitäten des Usability Engineering Prozesses hin, die zwingend durchgeführt werden müssen, wohingegen bei anderen Aktivitäten mehr Handlungsspielraum besteht. Hierbei empfehlen wir das folgende Vorgehen.

Schritt 1 – Erstelle die Entscheidungsgrundlage

Wie zu Beginn erwähnt, steht die sichere Medizinprodukteentwicklung im Fokus des Standards. Um dies zu gewährleisten sind zunächst die folgenden, wichtigen Basisaktivitäten durchzuführen:

Die konzeptionelle Beschreibung der Benutzerschnittstellen (User Interface Description) des Medizinprodukte, welche die safety-related User Interface Characteristics beinhaltet

Das Erstellen einer Use Specification
Die Durchführung einer Nutzungsrisikoanalyse mittels
- Analyse der vorhandenen Post-Production / Post-Market Information sowie (der Fokus liegt hierbei auf bekannten use errors, die zu Nutzungsrisiken führen können)
- Analyse aller hazard-related use scenarios (der Fokus liegt hierbei auf potenziellen use errors, die zu Nutzungsrisiken führen können)

Optimalerweise basieren diese Informationen auf umfangreichen User Research Aktivitäten sowie einer fundierten, hausinternen Datenbasis in Bezug auf Beschwerden und Reklamationen. Dies sollte durch eine ausführliche Recherche in relevanten Datenbanken ergänzt werden. Hinzu kommt die systematische Identifikation von potenziellen use errors im Rahmen der Erstellung der hazard-related use scenarios.

Schritt 2 – Analysiere die Einflussfaktoren

Ist ausführliches Wissen in Form der User Interface Description, der Use Specification sowie der Nutzungsrisikoanalyse vorhanden, kann eine detaillierte Analyse der zuvor genannten Einflussfaktoren erfolgen, indem zum Beispiel die Komplexität des User Interfaces und der Use Specification sowie der anzunehmende Schadensschweregrad aufgearbeitet werden.

Schritt 3 – Definiere und dokumentiere die Anzahl und den Umfang der weiteren Usability Engineering Aktivitäten

In Abhängigkeit der Vollständigkeit und Detailtiefe der Use Specification sowie der bekannten und möglichen Use Errors wird nun der Umfang der weitere Usability Engineering Aktivitäten definiert. Dies umfasst vor allem den weiteren Umfang an

User Research Aktivitäten: Der Umfang richtet sich nach dem Ausmaß bestehender Lücken in der Use Specification, etwa zu Nutzergruppen, vorherrschenden Arbeitsabläufen oder Nutzungsumgebungsspezifikationen.

User Interface-Design-Iterationen: Je nach Komplexität reichen wenige Designschleifen bis hin zu umfangreichen iterativen Entwicklungszyklen. Design-Iterationen sollten stets Hand-in-Hand mit formativen Evaluationen geplant werden.

Formativen Evaluationen: Diese dienen der Identifikation von Problemen beim Gebrauch noch unausgereifter User Interfaces, um darauf aufbauend Design-Optimierungen durchzuführen. Die Anzahl und Tiefe dieser Evaluationen können variieren, in gewissem Maße gesteuert werden (etwa durch die Art der ausgewählten Evaluationsmethoden oder der Anzahl teilnehmender Testnutzer) und sind oft vom Umfang und Status der vorhanden User Interface Prototypen abhängig.

Summativer Evaluationsaktivität: Diese dient dazu, objektive Nachweise dafür zu erbringen, dass das nutzungsbezogene Restrisiko auf akzeptablem Niveau ist. Hier findet meist die Methode des Usability Tests Anwendung. Der Umfang einer summativen Evaluation wird durch die Risiken und die Vielfalt der Hazard-related Use Scenarios sowie den damit verbundenen User Groups bestimmt. Wenn nach der summativen Evaluation Änderungen am User Interface vorgenommen werden müssen, können zusätzliche Evaluationen notwendig werden, falls weitere Nutzungsrisiken durch die Änderungen verursacht werden könnten. Diese lassen sich allerdings auf die betroffenen Interaktionen/Teile der Schnittstelle konzentrieren.

Wichtig – Denken Sie an das Deliverable: Insbesondere die Festlegung der Anzahl sowie des Umfangs der durchzuführenden formativen Usability Evaluationen und die Methodik der summativen Evaluation sollten im User Interface Evaluation Plan festgehalten werden.

Fazit

Die IEC 62366-1:2015 ermöglicht ein flexibles und risikobasiertes Vorgehen bei der Anwendung des Usability-Engineering-Prozesses. Dies ist sinnvoll und zugleich notwendig, um ein Optimum an Sicherheit, Aufwand und Produktqualität zu erreichen. Die Anpassung des Usability Engineering Aufwands ermöglicht es Herstellern, diesen Prozess effizient zu gestalten, indem sie den Umfang an die spezifischen Risiken und die Komplexität des Produkts anpassen. Ein strategisches Tailoring, also eine maßgeschneiderte Definition der Usability Engineering Aktivitäten, ermöglicht es, Regelkonformität und Wirtschaftlichkeit im Entwicklungsprozess in Einklang zu bringen. Nehmen Sie sich diese Zeit zu Beginn Ihres Entwicklungsprozesses, um hier für sich Klarheit zu schaffen und sich viel Aufwand und Mühe im weiteren Projektverlauf zu sparen.

Achten Sie bei der Anpassung allerdings stets auf die Stimmigkeit Ihrer Argumentation, um die Einhaltung der Anforderungen gemäß IEC 62366-1:2015 sicherzustellen. Zuletzt folgende Anmerkung: Die IEC 62366-1 konzentriert sich strikt darauf, den Usability Engineering Prozess anzuwenden, um die Gebrauchstauglichkeit von Medizinprodukten in Bezug auf die Sicherheit zu optimieren. Umfangreichere Usability Aktivitäten sind somit eventuell nicht regulatorisch vorgeschrieben und nicht notwendig, um „durchzukommen“. Allerdings führen diese darüber hinausgehenden Aktivitäten häufig zu eben den nutzerzentrierten Verbesserungen, die letztendlich die Nutzerzufriedenheit im Arbeitsalltag ausmachen und somit über den Erfolg oder Misserfolg Ihres Produktes entscheiden.

Disclaimer

Die in diesem Fachartikel dargestellten Informationen zu Normen und Standards wurden nach bestem und fundiertem Erfahrungswissen 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 unterliegen regelmäßigen Überarbeitungen und Änderungen, die hier nicht immer unmittelbar berücksichtigt werden können. Dieser Artikel stellt keine verbindliche Normberatung dar und ersetzt keine Prüfung der jeweils gültigen Normen durch qualifizierte Fachpersonen oder offizielle Stellen. Für die Anwendung der Normen und deren Auslegung sind stets die aktuell gültigen Originaldokumente sowie die zuständigen Normungsorganisationen maßgeblich.

Als Usability-Engineering-Spezialisten unterstützen wir von USE-Ing. Sie gerne bei der Anpassung des Usability Engineering Aufwands im Rahmen Ihrer Medizinproduktentwicklung. Sie haben Fragen? Sprechen Sie uns gerne an

Go to blog

Blog

Autor: Dr.-Ing. Marcus Jenke

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?

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

Disclaimer

Der USE-Ing. Kompass

Bleiben Sie auf dem richtigen Kurs mit unserem Newsletter

Anpassen des Usability Engineering Prozesses gemäß IEC 62366-1

Effektives Anpassen des Usability Engineering Prozesses nach IEC 62366-1

Wie viel Aufwand ist wirklich erforderlich?

Executive Summary

1Ziel der Aufwandsanpassung

3Welche Faktoren beeinflussen die Anpassung und das Ausmaß der Usability Aktivitäten?

2Die Grundlage der Anpassung

4Praktische Anwendungsbeispiele