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 Human Factors Engineering wird ein beobachteter Anwendungsfehler nicht vorschnell als individuelles Versagen des Nutzers bewertet. Zunächst ist systematisch zu prüfen, ob Merkmale der Benutzungsschnittstelle, der Aufgabe, der Nutzungsumgebung oder anderer Rahmenbedingungen dazu beigetragen haben – nicht jeder Anwendungsfehler belegt damit automatisch ein 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 Ergebnisse können eine Aktualisierung der nutzungsbezogenen Risikoanalyse, der Wirksamkeitsbewertung bestehender Risikokontrollmaßnahmen sowie eine Neubewertung der Restrisiken erforderlich machen.
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 sicherheitsbezogener Merkmale der Benutzungsschnittstelle, potenzieller Benutzungsfehler, Gefährdungen, Gefährdungssituationen und gefahrbezogener Benutzungsszenarien; eine allgemein anzuwendende Root-Cause-Analysis-Methode schreibt die Norm jedoch nicht vor. 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. ISO 14971 verlangt die Identifikation von Gefährdungen, die Berücksichtigung vorhersehbarer Ereignisfolgen und Gefährdungssituationen sowie die Einschätzung, Bewertung und Kontrolle der Risiken – eine universelle Root Cause Analysis für jedes identifizierte Risiko schreibt die Norm jedoch nicht vor. Ursachenanalysen liefern dafür wichtige Eingaben.
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 beobachteter Use Error beschreibt zunächst, was passiert ist – noch nicht, warum es passiert ist. 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