Blog

Schlagwort: IEC 62366-1

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

Hazard-related Use Scenarios

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

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

Februar 2026

Executive Summary

Kopie von auditive Visual Haptical Feedback 3

Hazard-related use scenarios gemäß IEC 62366-1 übersetzen Nutzung und Use Errors in eine strukturierte, testbare Form und sind damit ein Kernelement der Nutzungsbedingten Risikoanalyse (Use-related Risk Analysis).
Ausgangspunkt ist eine systematische Task Analysis, um User Interface-Merkmale mit Sicherheitsrelevanz und potenzielle Bedienfehler (Use Errors) zu identifizieren. Darauf aufbauend werden foreseeable und known hazardous situations zusammengeführt, um Risiken sowohl aus plausiblen Interaktionspfaden als auch aus bekannten Problemfeldern abzudecken. Hazard-related use scenarios beschreiben Ereignisketten einschließlich potenzieller Use Errors, die in hazardous situations münden können. Methodisch entscheidend sind der ausreichende Detailgrad in der Darstellung und die saubere Ableitung aus den identifizierten Use Scenarios. Für die Summative Evaluation ist eine begründete, risikobasierte Auswahl der relevanten Szenarien erforderlich.

Die Basis: Identifikation von foreseeable und known hazardous situations

Nutzungsrisikoanalyse (Use-related Risk Analysis) stellt die Verbindung zwischen der Benutzerschnittstelle (User Interface) und dem Risikomanagement her.  Dabei sollte sie zwei Quellen systematisch integrieren:

  • Foreseeable hazardous situations: Situationen, die plausibel aus potenziellen Use Errors entstehen können.
  • Known hazardous situations: Situationen, die aus vorhandenen Daten (z. B. Literatur, Datenbanken, Post-Market-Informationen) bekannt sind.

Die Kombination beider Perspektiven ist wichtig: Die rein projektinterne Analyse kann typische Fehlmuster übersehen, während reine Recherche ohne Interaktionsmodell häufig zu unscharfen, schwer testbaren Aussagen führt.

Methodisch sinnvoll ist, beide Quellen frühzeitig gegeneinander zu spiegeln: Known hazardous situations können als „Reality Check“ dienen (treffen typische Patterns aus dem Feld auf ähnliche UI- oder Workflow-Strukturen?), während foreseeable hazardous situations helfen, bekannte Risiken in produktspezifische, überprüfbare Ketten zu übersetzen. Entscheidend ist dabei, hazardous situations nicht als abstrakte Schlagworte zu führen, sondern als konkrete Situation, in der ein Hazard wirksam wird, z. B. durch falsche Parameterkombination, falschen Patientenbezug, fehlende Monitoring-Reaktion oder verzögerte Alarmwahrnehmung.

Identifikation potenzieller use Errors: Interaktion als Risikotreiber systematisch beschreiben

Während die Identifikation von known hazardous situations eher einer Fleißaufgabe ähnelt, ist eine methodische Vorgehensweise bei der Erarbeitung der foreseeable hazardous situations entscheidend. Hierbei gilt es zunächst potenzielle Use Errors zu identifizieren, die zu hazardous situations führen können, und diese systematisch zu bewerten sowie durch geeignete Maßnahmen zu kontrollieren. Methodisch ist dabei entscheidend, dass Risiken nicht abstrakt formuliert werden, sondern über konkrete Interaktionssequenzen und Nutzungskontexte nachvollziehbar werden.

Ausgangspunkt ist daher eine systematische Beschreibung der Nutzung als Risikotreiber: 

Welche Nutzergruppen führen welche Aufgaben mit welchen Zielen aus, unter welchen Rahmenbedingungen, mit welchen Informationsgrundlagen und mit welchen zeitlichen oder organisatorischen Zwängen

Risk Analysis

Erst wenn diese Nutzungssituation konkret beschrieben ist, lassen sich relevante Fehlhandlungen belastbar ableiten. Dazu gehört nicht nur „was“ getan wird, sondern „wie“ die Interaktion abläuft: 

Welche Anzeigen werden gelesen, welche Bedienelemente werden betätigt, welche Entscheidungen werden getroffen, welche Rückmeldungen werden erwartet und welche Systemzustände sind dabei kritisch. Interaktionsschritte, die im Normalfall trivial erscheinen, können unter realistischen Bedingungen (z. B. Stress, Unterbrechung, Handschuhe, eingeschränkte Sicht, Lärm, Zeitdruck oder Parallelaufgaben) zu systematischen Fehlbedienungen führen.

Task Analysis als Basis der use scenarios

Ein strukturierter Einstieg erfolgt über eine Task Analysis auf Basis erwarteter Aufgaben (anticipated tasks). Dabei wird die Mensch-Produkt-Interaktion schrittweise analysiert, um danach sicherheitsrelevante UI-Merkmale und potenzielle Nutzungsfehler (Use Errors) zu identifizieren. Eine belastbare Task Analysis betrachtet nicht nur „was“ getan wird, sondern auch „unter welchen Bedingungen“ und „mit welchen kognitiven Anforderungen“.

Für die Ableitung sicherheitsrelevanter Aussagen ist es hilfreich, Aufgaben in eine konsistente Struktur zu überführen. Dadurch werden Stellen sichtbar, an denen Nutzer auf kritische Informationen angewiesen sind (z. B. Statusanzeigen, Grenzwerte, Warnhinweise), an denen Werte eingegeben oder bestätigt werden, oder an denen ähnliche Optionen verwechselt werden können. Typische Risikotreiber entstehen besonders dort, wo 

  • mehrere Informationen integriert werden müssen,
  • Handlungen irreversibel sind,
  • Zeitdruck oder Unterbrechungen auftreten, oder
  • die User Interfaces mehrere Zustände ohne eindeutige Zustandsklarheit erlauben.

Eine gute Task Analysis integriert deshalb explizit bestehende Nutzungsumgebungseinflüsse (Use Environment Conditions) und kognitive Anforderungen. Dies wird beispielsweise durch den Einsatz der PCA (Perception, Cognition, Action)-Methodik ermöglicht. 

Stellen Sie sich bei der Erstellung die folgenden Fragen:

  • Welche Arbeitsschritte werden durchgeführt und bedingen welche Handlungen,
  • welche Aufmerksamkeit ist erforderlich (z. B. Monitoring parallel zu einer Intervention), 
  • welche Gedächtnislast entsteht (z. B. Parameterwerte merken, bevor sie eingegeben werden), 
  • welche Interpretationsleistung ist nötig (z. B. Trendkurven vs. Einzelwerte), 
  • welche Wahrnehmungsbedingungen gelten (z. B. Blendung, eingeschränkte Sicht, Handschuhe), und 
  • welche Team- oder Übergabesituationen sind typisch (z. B. Schichtwechsel, Übergabe im OP)? 
  • Zusätzlich sollten Abweichungen systematisch als „kalkulierte“ Variationen betrachtet werden: Welche Schritte werden erfahrungsgemäß abgekürzt, welche Workarounds sind plausibel, welche Routinen entstehen bei erfahrenen Nutzern – und welche Risiken werden dadurch begünstigt?

hazard-related use scenarios formulieren

Die Ableitung von Hazard-related Use Scenarios dient dazu, Nutzungsrisiken in eine überprüfbare Form zu überführen.

Ein Use Scenario beschreibt die Interaktion eines Nutzers mit dem Medizinprodukt, um in einer spezifischen Nutzungsumgebung (Use Environment) ein Ergebnis zu erreichen.

Ein Hazard-related Use Scenario erweitert diese Darstellung um eine Ereignissequenz einschließlich potenzieller Use Errors, die in eine hazardous situation münden kann, kurz gesagt:

Eine Hazard-related Use Scenario gemäß IEC 62366-1 ist ein Use Scenario, das zu einer Hazardous Situation führen kann, insbesondere infolge eines Use Error oder eines Reasonably Foreseeable Misuse (gemäß ISO 14971).

 

Wesentliche Qualitätskriterien sind:

  • Perspektive: Formulierung aus Sicht des Nutzers und des Nutzungskontextes.

  • Detailgrad: Ausreichend detailliert, um Ursachenketten und Interaktionsanforderungen nachvollziehen zu können.

  • Methodische Reihenfolge: Zunächst korrekte Use Scenarios definieren, anschließend daraus hazard-related use scenarios ableiten. Dadurch wird klar, an welcher Stelle der Abweichungspfad entsteht und welche UI-Merkmale oder Kontextfaktoren beitragend sind.

Ein Hazard-related Use Scenario sollte so aufgebaut sein, dass es direkt in Testdesign und Risikodokumentation überführbar ist. Praktisch bedeutet das: 

klare Startbedingungen (Systemzustand, Nutzerrolle),
erwartete korrekte Interaktion,
zugrunde liegende Use Errors und in Relation stehende UI-Merkmale,
Resultierende Hazardous situation, Hazards sowie Harms
die Einschätzung des Schadenschweregrads (Severity Level) in Rücksprache mit dem Riskmanagement
bestehende und zusätzlich zu definierende Risikokontrollmaßnahmen (Risk Control Measures)

Dadurch entsteht ein Szenarioformat, das sowohl argumentierbar (für ISO 14971) als auch testbar (für IEC 62366-1) ist.

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

Nicht jedes hazard-related use scenario muss zwingend Gegenstand der summativen Evaluation sein. Entscheidend ist ein transparentes, risikobasiertes Auswahlverfahren mit dokumentierter Begründung. Die Auswahl muss zeigen, dass jene Szenarien adressiert wurden, die für die Sicherheit der Nutzung maßgeblich sind. IEC 62366-1 führt drei zulässige Auswahlwege an:

Es werden alle Hazard-related Use Scenarios für die summativen Tests ausgewählt.
Es wird eine Teilmenge von Hazard-related Use Scenarios auf Basis des Schweregrads (Severity Level) des zu erwartenden Schadens (Harm) ausgewählt.
Es wird eine Teilmenge von Hazard-related Use Scenarios auf Basis des Schweregrads (Severity Level) und weiterer, für das Medizinprodukt und den Hersteller spezifischen Umständen ausgewählt.

Die Bedeutung der Schadensschwere wird deutlich. Die Einstufung dieser erfolgt gemäß ISO 14971. Die Normenverfasser haben in der neuesten Überarbeitung viel Spielraum für weitreichende Begründungen ermöglicht. Ein belastbares Auswahlverfahren macht explizit, warum ein Szenario in die Summative Evaluation aufgenommen wird. Entscheidend ist, dass die Auswahl nachvollziehbar dokumentiert ist und klar zeigt, dass die sicherheitskritischen Nutzungsszenarien in der summativen Prüfung abgedeckt wurden und somit im Einklang des Usability Engineering Prozesses für Medizinprodukte steht.

Disclaimer

Die in diesem Fachartikel dargestellten Informationen zu Normen und Richtlinien wurden nach bestem und fundiertem Expertenwissen dargelegt. Sie spiegeln hierbei rein die Meinung des Autors wider. Es kann keine Gewähr für die Vollständigkeit, Aktualität und Richtigkeit der Angaben übernommen werden. Normen und Richtlinien unterliegen regelmäßigen Überarbeitungen und Änderungen, die hier nicht immer unmittelbar berücksichtigt werden können. Dieser Artikel stellt keine verbindliche Beratung dar und ersetzt keine Prüfung der jeweils gültigen Normen und Richtlinien durch qualifizierte Fachpersonen oder offizielle Stellen. Für die Anwendung der Normen und Richtlinien und deren Auslegung sind stets die aktuell gültigen Originaldokumente sowie die zuständigen Organisationen maßgeblich.

Benedikt Janny

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

Der USE-Ing. Kompass

Bleiben Sie auf dem richtigen Kurs mit unserem Newsletter

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

Usability Engineering Prozess

Effektives Anpassen des Usability Engineering Prozesses nach IEC 62366-1

Wie viel Aufwand ist wirklich erforderlich?

August 2025

Executive Summary

Kopie von auditive Visual Haptical Feedback 3

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. 

Usability Engineering Prozess

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.

Bild 1 Vergleich Medizinprodukte 2

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

  1. Das Erstellen einer Use Specification
  2. 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.

Relevante Aktivitaeten zum Tailoring 1 scaled 1

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.

Benedikt Janny

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

Der USE-Ing. Kompass

Bleiben Sie auf dem richtigen Kurs mit unserem Newsletter