Die Nutzungsrisikoanalyse (Use-related Risk Analysis, URRA) verknüpft Nutzeraufgaben, mögliche Anwendungsfehler, Gefährdungssituationen und potenzielle Schäden zu einer durchgängigen Kette. Sie ist die zentrale Brücke zwischen Usability Engineering und Risikomanagement – der Ort, an dem sich Gestaltungsentscheidung und Risikobewertung eines Medizinprodukts treffen.
Die Kette von der Aufgabe zum Schaden
Die URRA folgt einer festen Argumentationskette, die für jede in der Aufgabenanalyse identifizierte Nutzeraufgabe durchlaufen wird: Welche Anwendungsfehler sind bei dieser Aufgabe plausibel? Kann ein solcher Fehler zu einer Gefährdungssituation führen? Und welcher Schaden könnte daraus für Patient, Anwender oder Dritte entstehen?
Diese Kette ist bewusst so aufgebaut, dass jeder Schritt aus dem vorherigen begründet werden muss. Ein Schadenspotenzial ohne nachvollziehbaren Auslösemechanismus ist ebenso wenig belastbar wie ein Anwendungsfehler, dessen Konsequenz nie zu Ende gedacht wird. Erst die vollständige Kette macht sichtbar, welche Aufgaben tatsächlich sicherheitsrelevant sind – und welche, so unangenehm ein Fehler dort auch wäre, ohne Folgen für die Patientensicherheit bleiben.
Aufbau einer URRA in der Praxis
In der Praxis wird die URRA meist tabellarisch geführt, mit einer Zeile je identifiziertem Anwendungsfehler und Spalten für die beteiligte Aufgabe, die Fehlerbeschreibung, die resultierende Gefährdungssituation, die Schadensschwere, vorgesehene Risikokontrollmaßnahmen sowie den Verweis auf die Studie, in der die Wirksamkeit dieser Maßnahme überprüft wurde.
Diese Struktur ist kein Selbstzweck: Sie stellt sicher, dass jede Zeile der URRA am Ende auf einen konkreten Nachweis zurückgeführt werden kann – entweder auf eine konstruktive Maßnahme, deren Wirksamkeit in der summativen Evaluation geprüft wurde, oder auf eine begründete Bewertung, warum ein Restrisiko vertretbar ist. Eine URRA, die Fehler nur auflistet, ohne diese Rückführung zu leisten, erfüllt ihren eigentlichen Zweck nicht.
Zwei Quellen, die zusammengeführt werden müssen
Eine belastbare URRA stützt sich auf zwei komplementäre Quellen, die einzeln jeweils blinde Flecken haben. Die projektinterne Analyse – aufbauend auf Aufgabenanalyse, Workflow-Analyse und dem Modell Perception–Cognition–Action – liefert ein konkretes Interaktionsmodell, kann aber produktspezifische Fehlermuster übersehen, die dem Entwicklungsteam nicht bekannt sind.
Die externe Recherche – Erkenntnisse aus Marktbeobachtung, aus bekannten Gebrauchstauglichkeitsproblemen vergleichbarer Produkte und aus Vorkommnisdatenbanken – liefert reale Fehlermuster, führt aber ohne ein konkretes Interaktionsmodell häufig zu unscharfen, schwer testbaren Aussagen. Erst die Kombination beider Perspektiven macht die URRA belastbar: Die interne Analyse gibt der externen Erkenntnis einen konkreten Ort im Ablauf, die externe Erkenntnis schützt die interne Analyse vor blinden Flecken.
Eine ausführliche Praxisanleitung zur Ableitung gefährdungsbezogener Nutzungsszenarien aus beiden Quellen finden Sie im vertiefenden Artikel „Identifikation von Hazard-related Use Scenarios" auf unserer Wissensplattform.
Von der URRA zu den kritischen Aufgaben
Die URRA ist die Grundlage, aus der sich gefährdungsbezogene Nutzungsszenarien und kritische Aufgaben ableiten. Als kritisch gilt eine Aufgabe, bei der ein Anwendungsfehler zu ernsthaftem Schaden führen könnte, wenn keine Gegenmaßnahme greift – diese Einstufung ist keine separate Analyse, sondern das direkte Ergebnis der in der URRA dokumentierten Kette.
Diese Ableitung entscheidet über den Umfang der summativen Validierung: Kritische Aufgaben müssen dort zwingend getestet werden. Eine URRA, die eine sicherheitsrelevante Aufgabe nicht als kritisch identifiziert, hat damit eine unmittelbare Konsequenz – die Validierung prüft dann nicht das, was tatsächlich geprüft werden müsste, und ein reales Risiko bleibt unentdeckt.
Ein lebendes Dokument, kein Einmalprodukt
Ein häufiger Mangel in der Praxis: Die URRA wird früh im Projekt erstellt und danach nicht mehr aktualisiert, obwohl sich Design, Nutzungskontext oder Erkenntnisse aus Tests im Projektverlauf ändern. Jede Designänderung, jeder Befund aus einer formativen Evaluation und jede neue Erkenntnis aus der Marktbeobachtung von Vorgängerprodukten sollte in die URRA zurückfließen.
Ebenso wichtig ist die Rückkopplung nach der summativen Validierung: Beobachtete, bislang unbekannte Anwendungsfehler müssen in die URRA aufgenommen und bewertet werden – auch wenn das Produkt formal bereits die Validierung durchlaufen hat. Die URRA endet nicht mit der Zulassung, sondern wird über die Marktbeobachtung im gesamten Produktlebenszyklus fortgeführt.
Regulatorischer Bezug
Die URRA ist der methodische Kern dessen, was IEC 62366-1 als Analyse des Nutzungsrisikos fordert, und zugleich der Punkt, an dem der Usability-Engineering-Prozess mit dem Risikomanagement nach ISO 14971 verzahnt ist – Anwendungsfehler und ihre Folgen müssen konsistent in beiden Dokumentationen erscheinen.
Die FDA Human Factors Guidance erwartet die URRA typischerweise in tabellarischer Form als zentralen Bestandteil des Human-Factors-Prozesses und verlangt, dass sich die daraus abgeleiteten kritischen Aufgaben im Prüfplan der Human Factors Validation wiederfinden. Für die EU-Medizinprodukteverordnung (MDR) ist die URRA die Grundlage, um die in Anhang I geforderte Reduktion von Risiken durch Anwendungsfehler nachvollziehbar zu belegen.
Häufige Fragen (FAQ)
Was ist der Unterschied zwischen URRA und Risikomanagementakte nach ISO 14971?
Die URRA ist auf nutzungsbedingte Risiken fokussiert und liefert die anwendungsspezifische Perspektive; die Risikomanagementakte nach ISO 14971 betrachtet alle Risikoarten eines Produkts, technische wie nutzungsbedingte. Beide müssen konsistent aufeinander verweisen – Anwendungsfehler und ihre Folgen dürfen in beiden Dokumenten nicht widersprüchlich bewertet werden.
Woher kommen die in der URRA betrachteten Anwendungsfehler?
Aus zwei komplementären Quellen: der projektinternen Analyse anhand von Aufgabenanalyse und Interaktionsmodell sowie der externen Recherche zu bekannten Gebrauchstauglichkeitsproblemen und Vorkommnissen vergleichbarer Produkte. Beide Quellen zusammen liefern ein belastbareres Bild als jede für sich.
Muss die URRA nach der Zulassung weitergeführt werden?
Ja. Neue Erkenntnisse aus der Marktbeobachtung, etwa bislang unbekannte Anwendungsfehler, müssen in die URRA aufgenommen und bewertet werden. Sie ist ein lebendes Dokument über den gesamten Produktlebenszyklus, nicht ein einmalig erstelltes Freigabedokument.
Was passiert, wenn eine sicherheitsrelevante Aufgabe in der URRA übersehen wird?
Sie wird dann auch nicht als kritische Aufgabe eingestuft und fließt entsprechend nicht in den Prüfumfang der summativen Validierung ein. Ein reales Risiko bliebe damit unentdeckt – ein Grund, warum die Vollständigkeit der zugrunde liegenden Aufgabenanalyse für die URRA so wichtig ist.
Die Nutzungsrisikoanalyse verknüpft Aufgaben, Anwendungsfehler, Gefährdungssituationen und Schäden zu einer durchgängigen, nachvollziehbaren Kette – und ist damit die Brücke zwischen Usability Engineering und Risikomanagement.
Belastbar wird sie erst durch die Kombination aus projektinterner Analyse und externer Recherche, und wirksam bleibt sie nur, wenn sie über den gesamten Produktlebenszyklus aktuell gehalten wird.
Sie brauchen eine Nutzungsrisikoanalyse, die vor einer Benannten Stelle und der FDA gleichermaßen besteht? Wir verzahnen Usability Engineering und Risikomanagement für Sie durchgängig.
Mehr zu unserem Usability Engineering