USABILITY ENGINEERING FÜR MEDIZINPRODUKTE

Aus der IEC 62366-1 leiten sich fünf wesentliche Schritte für den Usability Engineering Prozess ab:

• Use Specification: In diesem Schritt werden bspw. Verwendungszweck, Nutzungsumgebung sowie Nutzergruppe/Patientengruppe definiert.

• Gefährdungsbezogene Use Scenarios identifizieren: Diese Analyse dient dazu, Anwendungsfehler und nutzungsbedingte Gefahren zu identifizieren und Nutzungsanforderungen festzulegen.

• User Interface Specification festlegen: Gefordert durch die IEC 62366-1 Norm sind sie ein wesentlicher Teil der Software Development Norm (IEC 62304. Auf Basis der Stakeholder Requirements werden Konzepte als Prototyp in bspw. Figma erstellt. 

• Formative und summative Evaluation planen, durchführen und auswerten:
  a.) Formative Evaluationen finden während des Gestaltungsprozesses statt und fördern eine iterative, nutzerzentrierte Produktentwicklung
  b.) Summative Evaluation (Pflicht, sobald Risiken ermittelt wurden) → Die Einbindung des Nutzers ist in diesem Fall obligatorisch. Getestet, in der Regel durch einen Usability Test, wird das technisch entwickelte Produkt in der realen Nutzungsumgebung mit Patienten, um sicherzustellen, ob das Medizinprodukt für den vorgesehenen Verwendungszweck und in der vorgesehenen Nutzungsumgebung sicher und effektiv genutzt werden kann.

• Summary Report schreiben: Am Ende aller Usability-Aktivitäten verfasst Neofonie einen Usability Evaluation Summary Report, um die Ergebnisse aller Usability-Aktivitäten zusammenzufassen und abzuschließen. 

Wesentliche Voraussetzung für den Usability-Engineering-Prozess ist die Entwicklung einer Verfahrensanweisung der sog. Standard Operating Procedure (SOP). Die Erstellung der SOP findet auf Basis der IEC 62366-1 statt und bildet einen Standard für den Entwicklungsprozess eines SaMD (Software as a Medical Device) ab. Sie dienen als “Regelwerk” für die normgerechte Durchführung des Usability-Engineering-Processes und als Schulungsmaterial, an das sich alle im Projektteam halten müssen. Unterstützt wurde der Vorgang durch das Johner Institut, gemeinsam wurde sichergestellt, dass alle notwendigen Anforderungen an den normierten Prozess berücksichtigt werden. Ändern sich Prozesse, werden diese Änderungen in der SOP angepasst.

Für die Erstellung der SOP mussten wir uns zunächst intensiv mit der Norm auseinandersetzen und die Unterschiede zu unseren bisherigen UX-Prozessen verstehen. 

Wie wir feststellen mussten, haben Begriffe, die wir aus dem UX-Prozess kennen, zum Teil andere Bedeutungen. In der Usability spricht man bspw. im Allgemeinen von User Error, wenn Nutzer bspw. während eines Tests Fehler machen, woraus sich ergibt, dass der Nutzer nur so gut sein kann, wie das System. Im Rahmen der IEC 62366-1 wird der Begriff Use Error verwendet und meint alles, was ein Nutzer falsch wahrnehmen, denken oder tun kann. Grundsätzlich ist es etwas, was der Nutzer tut und sich von außen beobachten lässt, bspw. falsche Werte eingeben oder eine falsche Auswahl treffen. Die Use Errors werden durch den Hersteller und Neofonie vor der Evaluation mit Benutzern sowie später auch durch Methoden wie Experten-Reviews und Usability Tests identifiziert. Das Formulieren von potentiellen Use Errors ist daher ein wesentlicher Bestandteil des Usability-Engineering-Processes und fließt in das Risikomanagement ein.

So unterscheiden sich auch die Begriffe Use Scenario und User Story. 

Das Use Szenario entspricht einer “bestimmten Abfolge von Aufgaben, ausgeführt von einem bestimmten Nutzer in einer bestimmten Nutzungsumgebung und jegliche resultierende Reaktion des Medizinprodukts“ (DIN EN 62366-1:2021-08, Kapitel 3.22) 

Hierfür sind Kern- und Teilaufgaben zu ermitteln. Die brainboost App soll bei der Diagnose und Therapie von depressiven Störungen unterstützen. Sie enthält u.a. ein therapiebegleitendes Tagebuch zur Dokumentation der Symptome. In unserem Fall besteht demnach die Kernaufgabe in der Dokumentation in einem digitalen Tagebuch, während das Öffnen des Tagebuches, das Vornehmen von Einträgen, die Ergänzung als auch das Speichern von Einträgen zu den Teilaufgaben zu zählen sind.

Die User Story wird dagegen bspw. nach Satzschablone formuliert: “Als [Rolle] kann ich mit einer [Tätigkeit] einen [Zweck] erfüllen.” Also an unserem Beispiel betrachtet, kann ein Patient [Rolle] das Tagebuch nutzen [Tätigkeit], damit er mit seinem Arzt darüber sprechen kann [Zweck].

Das vermischt verschiedene Konzepte der Anforderungen, die ein Medizinproduktehersteller erfassen muss.

• Die Rolle ist die Charakterisierung der Anwender, diese steht in der Zweckbestimmung.

• Die Tätigkeit beschreibt, was der Nutzer am System können muss, das entspricht den Stakeholder Requirements.

• Der Zweck beinhaltet die Absicht der Aktion, auch dieser Punkt wird in der Zweckbestimmung formuliert.

Die Regularien verlangen Nachvollziehbarkeit (Traceability) zwischen Zweckbestimmung und Stakeholder Requirements. Das gelingt jedoch nicht, wenn die Themen vermischt werden. Daher ist ein systematisches Ableiten der Anforderungen mit User Stories nicht zu empfehlen.