Der IEC TR 62366-2 ist ein „Technical Report“, den Medizinproduktehersteller als „Gebrauchsanweisung“ für die IEC 62366-1 nutzen können. Der Technical Report gibt konkrete Handlungsleitung beim Usability Engineering, um die Anforderungen der IEC 62366-1 zu erfüllen.
Dieser Artikel verschafft Ihnen einen Überblick über den mehr als hundertseitigen IEC TR 62366-2.
Ziele des IEC TR 62366-2
Regulatorische Anforderungen erfüllen
Medizinproduktehersteller müssen Risiken durch mangelnde Gebrauchstauglichkeit ihrer Produkte kennen und beherrschen. Das fordern einhellig die EU-Richtlinien (MDD, IVD), EU-Verordnungen (MDR, IVDR) sowie die FDA.
Um den Medizinprodukteherstellern bei der Umsetzung der regulatorischen Anforderungen Hilfestellungen zu geben, hat die EU Normen harmonisiert. Diese Normen beschreiben, wie Hersteller nach „State-of-the-art“ vorgehen sollen, um den Nachweis zu erbringen, dass die Anforderungen erfüllt sind. Im Fall des Usability Engineerings wurde die IEC 62366 harmonisiert, aber noch nicht deren Nachfolgerin, die IEC 62366-1. Dennoch können Sie die IEC 62366-1 jetzt schon anwenden.
Konkrete Handlungsleitung geben
Die IEC 62366-1 beschreibt allerdings nur die Aktivitäten, die ein Usability Engineering Prozess enthalten muss. Sie gibt weder einen konkreten Prozess vor, noch nennt sie Methoden, die bei den Aktivitäten angewendet werden können oder müssen. Beispielsweise fordert die IEC 62366-1 nur, dass der Plan zur formativen Evaluation die Methoden nennen müsse. Welche Methoden für eine solche formative Bewertung zur Verfügung stehen und welche sich unter welchen Umständen eignen, verrät die Norm nicht.
Genau hier springt der IEC TR 62366-2 in die Bresche. Er gibt den Herstellern Hintergrundinformationen an die Hand, nennt Methoden und Verfahren und gibt Beispiele für einen Projektplan und für die Dokumentation. Mit Recht ließe sich der Technical Report als „Lehrbuch“ zur Anwendung der IEC 62366-1 bezeichnen.
IEC 62366-2: Aufbau des „Technical Reports“
Der Technical Report enthält auf 106 Seiten 19 Hauptkapitel und 12 Anhänge. Auf die Anhänge entfällt über ein Drittel der Seiten (s. Abb. 1).
Die ersten sieben Kapitel beschreiben den Kontext und geben allgemeine Hinweise zum Aufsetzen eines Usability Engineering Prozesses.
Die Kapitel neun bis 17 orientieren sich an den Aktivitäten entlang des Entwicklungsprozesses: vom Identifizieren sicherheitsbezogener Charakteristiken der Benutzungsschnittstelle bis zu deren summativen Bewertung.
Die Kapitel 18 und 19 geben Hinweise zur Dokumentation und zur nachgelagerten Phase (s. Abb. 2).
Insgesamt zwölf Anhänge ergänzen den Technical Report
- Bibliographie (es gibt noch ein weiteres Literaturverzeichnis)
- Liste externer Ressourcen wie die Fehlerdatenbanken der Behörden
- Die kommerziellen Ziele des Usability Engineerings
- Usability Engineering Projekt (siehe auch Abbildung 3)
- Methoden des Usability Engineerings (einer der nützlichsten Anhänge)
- Usability Studien im klinischen Umfeld
- Benutzerprofile
- Benutzungsumgebung
- Anforderungen an Benutzungsschnittstellen
- Modellierung der Benutzungsschnittstelle
- Sample Size bei Usability Tests
- Identifikation eindeutiger Benutzergruppen
Methoden des Usability Engineerings
Der IEC TR 62366-2 stellt ein umfangreiches Portfolio an Methoden für das Usability Engineering vor. Gleichzeitig ordnet er diese Methoden den Aktivitäten im gebrauchstauglichkeitsorientierten Entwicklungsprozess zu.
Damit wissen Hersteller, welche Methoden sich eigenen, um die Anforderungen der einzelnen Kapitel der IEC 62366-1 zu erfüllen. Die folgende Tabelle verknüpft die Methoden mit den Aktivitäten und Kapiteln der IEC 62366-1 sowie des IEC TR 62366-2.
Aktivität Methoden |
Kapitel im IEC TR 62366-2 | Prepare Use Specification | Identify UI characteristics related to safety | Identify known or foreseeable hazards and hazardous situations | Identify and describe hazard related use scenarios | Design and implement UI | Perform formative evaluation | Perform summative evaluation |
Kapitel im IEC TR 62366-2 | 8 | 9 | 10 | 11 | 15 | 16 | 17 | |
Kapitel in der IEC 62366-1 | 5.1 | 5.2 | 5.3 | 5.4 | 5.8 | 5.8 | 5.9 | |
Contextual inquery | E5 | X | E | E | X | E | E | |
Observation | E12 | X | E | E | X | E | E | |
Interview and survey | E13, E18 | X | X | E | X | E | ||
Expert reviews | E7 | X | E | E | E | E | X | X |
Standard reviews | E17 | X | ||||||
Advisory panel reviews | E2 | X | E | E | E | E | E | |
Task analysis | E19 | E | X | E | X | E | E | E |
Function analysis | E10 | E | X | E | X | E | ||
Identify and analyse known problems e.g. literature | X | X | X | E | ||||
Brain storming | E3 | E | E | E | X | |||
Day in life analysis | E6 | E | E | X | ||||
FMEA, FTA | E8 | E | E | E | X | E | E | E |
Focus groups | E9 | E | E | E | X | E | E | |
Wireframe prototype | 15.3.4 | E | E | X | E | |||
High fidelity prototype | E | E | X | E | ||||
Usability tests | 16.2.4 | E | E | E | E | X | X | |
Cognitive walkthrough | 16.2.3, E4 | E | E | E | E | X | ||
Heuristic analysis | 16.2.4, E11 | E | E | E | X | |||
Participatory design | E14 | E | E | E | ||||
Simulation | E16 | E | E | E | E | |||
PCA Analysis | E15 | X | E | E | E | E | ||
Time and motion | E20 | E | E | E | E | |||
Workload assessment | E21 | E | E | E | E | E | E |
Tabelle 1: Der IEC TR 62366-2 schlägt im Text für die Aktivitäten die jeweils geeigneten Methoden vor (mit X markiert). Diese haben wir ergänzt (E). (Bitte im Browser vergrößern oder im Auditgarant herunterladen)
Anmerkung: Im Anhang (Tabelle E1) enthält der Technical Report ebenfalls eine Tabelle, die Aktivitäten und Methoden verknüpft. Allerdings hat diese Tabelle eine andere Struktur.
Usability Engineering Prozess und Projekt
Der Technical Report gibt ein hilfreiches Beispiel dafür, wie ein Usability Engineering Projekt gestaltet und damit ein Usability Engineering Plan formuliert werden kann.
Abb. 3: Beispiel für ein Usability Engineering Projekt (angelehnt an „Figure 1“ im IEC TR 62366-2) (zum Vergrößern klicken. Im Auditgarant gibt es die Datei als PDF zum Download)
Bewertung des IEC TR 62366-2
Möglicher Interessenskonflikt
Der Autor dieses Artikels ist Mitglied des Normenkomitees, das auch am IEC TR 62366-2 mitgewirkt hat.
Der IEC TR 62366-2 hat als Technical Report nicht den Anspruch, normativ verbindlich zu sein. Daher wurde er bewusst von der IEC 62366-1 getrennt. Vielmehr verschafft der Technical Report einen Überblick über die Methoden des Usability Engineerings.
Stärken
Man könnte einwenden, dass auch andere Lehrbücher die Methoden beschreiben. Der IEC TR 62366-2 hat aber trotzdem seine Berechtigung:
- Er verschafft den Medizinprodukteherstellern eine schnelle Übersicht über die Landschaft an Methoden und beschreibt sie in einer Länge, die ausreicht zu entscheiden, ob man die jeweilige Methode anwenden oder mehr darüber erfahren möchte.
- Der Technical Report verknüpft diese Methoden mit den Aktivitäten, die die IEC 62366-1 fordert. Das erleichtert den Herstellern die Umsetzung.
- Er nennt konkrete Beispiele, die über die in der Basisnorm genannten hinausgehen. So nennt der TR 62366-2 Aspekte um Benutzer und die Benutzungsumgebung zu charakterisieren, gibt Beispiele für typische Benutzungsfehler und nennt Datenquellen, die Hersteller auf bekannte Benutzungsprobleme hin untersuchen sollten.
- Auch für den Aufbau von Dokumenten wie einem Usability Test Plan (Protocol) und Usability Test Bericht (Report) unterbreitet der Technical Report konkrete Vorschläge.
- Die Verweise auf weitere länderspezifische Quellen wie die CIRS-Datenbanken sind hilfreich.
Schwächen
Fehlende Einbindung des Requirements Engineerings
Wie die IEC 62366-1 beschreibt der Technical Report nicht systematisch, wie Hersteller zu Benutzungsanforderungen, von dort zu Benutzungsszenarien und von dort zu UI Spezifikationen gelangen. Daher fällt in Kapitel 9 das User Interface der Medizinprodukte etwas vom Himmel, für die man Aufgaben und Funktionen analysieren soll.
Für völlig neue Medizinprodukte fehlt ein Zwischenschritt. Für Kategorien von Medizinprodukten, die es in ähnlicher Form schon gibt und die weiter zu entwickeln sind, erscheint dieser Ansatz hingegen als zielführend.
Ein Usability Engineering ohne ein adäquates Requirements Engineering wird effizient nur schwer gelingen. Dem wird der Technical Report nicht ganz gerecht.
Der Auditgarant zeigt Ihnen, wie Sie Nutzungsanforderungen systematisch ableiten. Er enthält auch einen umfassenden Satz an Templates für eine Gebrauchstauglichkeitsakte. Videotrainings ansehen
Konzept der User Interfaces Specification
Kapitel 13 widmet sich der User Interface Specification. Viele Leser dürften in diesem Kapitel Hinweise für die Spezifikation der Benutzungsschnittstelle erwarten. Doch der IEC TR 62366-2 versteht darunter eher die User Interface Requirements. Die eigentliche Spezifikation beschreibt er erst im Kapitel 15 „Design and implement the user interface and training“.
Die Beispiele für Anforderungen an die UI erscheinen willkürlich:
- Jeder Screen soll einen aussagekräftigen Titel haben.
- Wenn ein Nutzer mehr als drei Sekunden warten muss, bedarf es einer Fortschrittsanzeige
- Text soll mindestens 14 Punkt groß sein
Hier wäre zumindest ein Verweis auf die Familie der ISO 9241-Normen angebracht, die solche Anforderungen weit umfangreicher und spezifischer formuliert. Beispielsweise stellt die ISO 9241 eine Formel zur Verfügung, die die Textgröße abhängig vom Abstand des Betrachters berechnet.
Trainings- und Begleitmaterialien
Der IEC 62366-1:2015 fehlen im Vergleich zur Vorgängerversion die Kapitel zu den Trainings- und Begleitmaterialien, die aber weiterhin gefordert sind. Der IEC TR 62366-2 nimmt sich des Themas an und nennt Aspekte, die diese Materialien aufgreifen sollten. Allerdings erreicht der Technical Report nicht die gleiche Qualität an Handlungsleitung wie bei den anderen Aktivitäten wie z.B. dem Identifizieren von gefährdungsbezogenen Benutzungsszenarien. Ein direkter Verweis auf weitere Quellen wäre an dieser Stelle hilfreich. Weiterführende Informationen
Lesen Sie hier mehr zum Thema Gebrauchsanweisungen und Labeling.
Fazit
Der IEC TR 62366-2 ist eine sehr nützliche Informationsquelle für Hersteller, die die Gebrauchstauglichkeit ihrer Medizinprodukte gewährleisten und dies auch nachweisen müssen.
Der Technical Report stellt im Vergleich zur IEC 62366-1 keine zusätzlichen Anforderungen, sondern erklärt exemplarisch, wie deren Anforderungen effizient und effektiv umgesetzt werden können. Damit sei der IEC TR 62366-2 als eine Gebrauchsanleitung für die IEC 62366-1 wärmstens zum Kauf empfohlen.
Wir unterstützen Sie beim Usability Engineering: Vom Erheben der Anforderungen über das UI Design bis zum Usability Testing in unseren Labs in Frankfurt und Washington D.C.. Kontakt aufnehmen
INFORMATIV!
Danke! 🙂
Hallo liebes Johner-Team
Zur neuen EN 62366 habe ich einen Frage.
Rein inhaltlich hat sich doch gegenüber der Vorgängerversion nichts geändert, so meine Interpretation nach Analyse. Der 2 Teil ist lediglich eine Art GA, richtig?
Wenn also meine Dokumente nach der Vorgängerversion auditiert sind, besteht hier keine Notwendigkeit, das auf den Report (Teil 2) anzupassen.
Stimmt das so?
Vielen Dank und schöne Grüße
Christian Wulz
Sehr geehrter Herr Wulz,
danke für Ihre Frage! Bei der IEC 62366-1 gibt es nur eine Version, daher auch keine Änderung. Die Änderungen von der IEC 62366-1 zur IEC 62366 sind aber nennenswert.
Die IEC 62366-2 ist in der Tag eine „Art GA“ zur IEC 62366-1. Genau!
Beste Grüße, Christian Johner
Hallo,
wie ist
GEFÄHRDUNGSBEZOGENES USE SCENARIO
USE SCENARIO, das zu einer GEFÄHRDUNGSSITUATION oder zu einem SCHADEN führen kann
zu verstehen?
Alles was in der Risikoanalyse auftaucht?
Alles was einen Schwellwert überschreitet?
Die Frage ist, wenn ich in einer Software irgendwas implementiere, dann kann fast immer ein Schaden auftreten, und sei es eine „Zeitverzögerung“.
Daher war meine Interpretation immer, dass „Schaden“ analog zu Software-Klasse „B“ oder sogar nur „C“ zu sehen ist, jetzt habe ich aber eine andere Interpretation gehört, sobald ein Eintrag im Risikomanagement ist, muss es erledigt werden.
Gibt es dazu Meinungen?
viele Grüße
Christian
Sehr geehrter Herr Christian,
herzlichen Dank für Ihre Frage!
Sie haben bereits die Definition angeführt. Das ist sehr gut.
Wie Sie darin sehen, gibt es keine Schwellwerte für Schäden. Wenn ein Use Scenario zu einem Schaden führten kann, dann muss es auch in der Risikoanalyse betrachtet sein.
Ob eine Zeitverzögerung ein Schaden ist, hängt vom konkreten Anwendungsfall ab.
Eine Korrelation mit den Software-Klassen ist wenn überhaupt nur bei standalone Software sinnvoll. Die Antwort auf diese Frage ist allerdings auch davon abhängig, mit welcher Version der IEC 62304 Sie arbeiten. Die Definition der Sicherheitsklassen unterscheidet sich sehr. Zudem gilt es diese immer vor und nach Maßnahmen zu unterscheiden.
Die entscheidende Frage ist möglicherweise, was die Konsequenzen dieser Festlegung sind. Die IEC 62366 zwingt nicht, alle gefährdungsbezogenen Use Scenario in der summativen Bewertung zu analysieren.
Meine Faustregel würde aber der Ihren dahingehend folgen, dass ein Use Scenario, bei dem ein Nutzungsfehler zu einem auch nur kleinen körperlichen Schaden führen kann, als gefährdungsbezogen zu betrachten — und in die summative Bewertung einzubeziehen ist.
Viele Grüße, Christian Johner
Sehr geehrter Herr Johner,
danke, das hilft schon mal weiter …
ja, es geht um Stand-Alone-Software.
Vielen Dank
Christian