Die Ursachenanalyse (engl. Root Cause Analysis, RCA) ist ein systematisches Verfahren zur Identifikation der zugrunde liegenden Ursachen eines beobachteten Problems, Anwendungsfehlers, Beinahe-Fehlers oder sicherheitsrelevanten Ereignisses. Im Usability Engineering von Medizinprodukten dient sie dazu, nicht nur den sichtbaren Use Error zu dokumentieren, sondern die dahinterliegenden Ursachen auf Ebene von Benutzungsschnittstelle, Nutzungskontext, Benutzermerkmalen, Arbeitsabläufen oder organisatorischen Faktoren zu identifizieren.
- Bedeutung im Usability-Engineering-Prozess
- Typische Ursachenkategorien bei Medizinprodukten
- Methoden der Ursachenanalyse
- Ursachenanalyse in formativen und summativen Evaluationen
- Häufige Fehler in der Praxis
- Zusammenhang mit Nutzungsrisikoanalyse und Risikomanagement
- Regulatorischer Bezug
- Häufige Fragen (FAQ)
Bedeutung im Usability-Engineering-Prozess
Die reine Beobachtung eines Use Errors liefert regulatorisch und entwicklungsseitig nur begrenzten Erkenntnisgewinn. Erst die Ursachenanalyse ermöglicht die Beantwortung der Frage, warum ein Fehler aufgetreten ist und welche Faktoren ihn begünstigt haben. Im Sinne von IEC 62366 werden Anwendungsfehler nicht primär als individuelles Versagen des Nutzers betrachtet, sondern als Hinweis auf ein mögliches Defizit der Gebrauchstauglichkeit oder Risikokontrolle. Die Ursachenanalyse bildet daher die Brücke zwischen Nutzerbeobachtung und konkreten Designmaßnahmen.
Typische Ursachenkategorien bei Medizinprodukten
In der Praxis zeigen sich Ursachen häufig in mehreren Ebenen gleichzeitig: unzureichende Wahrnehmbarkeit von Informationen (Displays, Kennzeichnungen, Alarme), Fehlinterpretation von Bedienelementen oder Statusanzeigen, unzureichende Konsistenz der Benutzungsschnittstelle, kognitive Überlastung des Anwenders, Nutzung unter realistischen Stress-, Zeit- oder Umgebungsbedingungen, unzureichende Berücksichtigung von Arbeitsabläufen oder mentalen Modellen sowie Defizite bei Schulung, Einweisung oder Begleitdokumentation. Eine belastbare Ursachenanalyse prüft systematisch, welche dieser Faktoren tatsächlich ursächlich oder beitragend waren.
Methoden der Ursachenanalyse
Mehrere etablierte Verfahren werden im Human Factors Engineering eingesetzt: die 5-Why-Methode (durch mehrmaliges Hinterfragen wird schrittweise von einem beobachteten Fehler zur Grundursache vorgedrungen), das Ishikawa-Diagramm (Fishbone Diagram), das potenzielle Ursachen entlang definierter Kategorien wie Mensch, Maschine, Methode, Material, Umgebung und Organisation strukturiert, die Fault Tree Analysis (FTA) als Top-down-Methode zur Analyse von Ursache-Wirkungs-Beziehungen bei sicherheitskritischen Ereignissen, die Barrier Analysis, die untersucht, welche Schutzmechanismen versagt haben oder nicht vorhanden waren, sowie Task Analysis und Cognitive Task Analysis zur Identifikation von Ursachen innerhalb komplexer Nutzungsschritte. Oft wird in Usability-Studien eine Kombination dieser Verfahren verwendet.
Ursachenanalyse in formativen und summativen Evaluationen
In formativen Evaluationen dient die Ursachenanalyse primär der Verbesserung des Designs: Beobachtete Anwendungsprobleme werden untersucht, um gezielte Designänderungen abzuleiten. In summativen Evaluationen besitzt sie zusätzlich regulatorische Bedeutung – tritt ein kritischer Use Error auf, muss bewertet werden, ob dessen Ursache bereits durch bestehende Risikokontrollen adressiert wurde, ob neue Risiken identifiziert werden müssen oder ob weitere Designmaßnahmen erforderlich sind. Die Analyse beeinflusst unmittelbar die Bewertung der Residualrisiken.
Häufige Fehler in der Praxis
Ein häufiger Fehler besteht darin, Ursachen vorschnell dem Anwender zuzuschreiben ("User Error"). Moderne Human-Factors-Ansätze betrachten Nutzerfehler jedoch zunächst als Symptom eines potenziellen Systemproblems. Weitere typische Schwächen sind die Verwechslung von Symptomen und Ursachen, der Fokus auf Einzelereignisse statt systemischer Faktoren, die fehlende Berücksichtigung des Nutzungskontexts, unzureichende Dokumentation der Herleitung sowie die Ableitung von Schulungsmaßnahmen, obwohl ein Designproblem vorliegt. Regulatorische Reviews hinterfragen zunehmend, ob die identifizierten Ursachen nachvollziehbar auf die gewählten Risikokontrollen zurückgeführt werden können.
Zusammenhang mit Nutzungsrisikoanalyse und Risikomanagement
Die Ursachenanalyse ist eng mit ISO 14971 und der nutzungsbezogenen Risikoanalyse verknüpft. Werden Ursachen identifiziert, die zu gefährlichen Situationen führen können, müssen diese in der Risikobetrachtung berücksichtigt werden. Die Analyse unterstützt außerdem die Bewertung der Wirksamkeit von Risikokontrollmaßnahmen und die Entscheidung, ob weitere Maßnahmen erforderlich sind. Dadurch entsteht eine nachvollziehbare Traceability zwischen beobachtetem Nutzerverhalten, Risikoanalyse und Designentscheidungen.
Regulatorischer Bezug
IEC 62366-1 fordert die Identifikation nutzungsbezogener Gefährdungen, gefährdungsbezogener Nutzungsszenarien sowie die Bewertung nutzungsbezogener Risiken; die Analyse von Anwendungsproblemen und deren Ursachen ist impliziter Bestandteil dieses Prozesses. IEC/TR 62366-2 beschreibt praxisnahe Verfahren zur Analyse von Nutzungsproblemen und zur Ableitung geeigneter Verbesserungsmaßnahmen, wobei die Ursachenanalyse als wichtiges Element zur Interpretation von Evaluationsergebnissen behandelt wird. Die FDA empfiehlt in ihrer Human-Factors-Guidance, beobachtete Use Errors und Nutzungsschwierigkeiten zu analysieren, ihre Ursachen zu bestimmen und Risiken durch geeignete Designmaßnahmen zu reduzieren. Das Risikomanagement nach ISO 14971 verlangt die Analyse von Gefährdungen, Gefährdungssituationen und deren Ursachen – Ursachenanalysen liefern wichtige Eingaben für Risikoidentifikation und Risikokontrolle.
Häufige Fragen (FAQ)
Muss für jeden beobachteten Use Error eine Ursachenanalyse durchgeführt werden?
Nicht zwingend in derselben Detailtiefe. Kritische Use Errors, wiederkehrende Nutzungsschwierigkeiten und unerwartete Ereignisse sollten jedoch systematisch analysiert werden, da sie Auswirkungen auf die Risikobewertung und die regulatorische Argumentation haben können.
Ist ein Use Error automatisch ein Hinweis auf schlechtes Design?
Nicht automatisch. Allerdings verlangen Human-Factors-Ansätze zunächst die Prüfung systemischer und designbezogener Ursachen, bevor menschliches Fehlverhalten als Hauptursache angenommen wird.
Reicht die Maßnahme „Schulung des Anwenders" als Ergebnis einer Ursachenanalyse aus?
In vielen Fällen nicht. Sowohl Human-Factors- als auch Risikomanagementprinzipien bevorzugen inhärent sichere Gestaltung und Designverbesserungen gegenüber rein administrativen Maßnahmen wie Schulungen oder Warnhinweisen.
Worin unterscheidet sich Ursachenanalyse von Nutzungsrisikoanalyse?
Die Nutzungsrisikoanalyse identifiziert und bewertet Risiken. Die Ursachenanalyse untersucht dagegen, warum ein konkretes Nutzungsproblem oder Risiko entsteht. Beide Verfahren ergänzen sich und sind eng miteinander verknüpft.
Ein Use Error ist ein Symptom, keine Diagnose. Erst die Ursachenanalyse – mit Methoden wie 5-Why, Ishikawa oder Fault Tree Analysis – zeigt, ob die eigentliche Ursache im Design, im Nutzungskontext oder in der Schulung liegt, und verhindert vorschnelle "User Error"-Zuschreibungen.
Sie möchten beobachtete Anwendungsfehler systematisch bis zur Grundursache analysieren und daraus belastbare Designmaßnahmen ableiten? Wir unterstützen Sie im gesamten Usability-Engineering-Prozess nach IEC 62366-1.
Mehr zu unserem Usability Engineering