Usability Engineering für Medizinprodukte
Aufsetzen der Prozesse nach IEC 62366-1
Die Entwicklung von digitalen Healthcare Produkten ist strengen Regularien unterworfen. Das Design folgt dabei dem Usability-Engineering-Prozess gemäß der EN IEC 62366-1. Diese Norm legt fest, dass Hersteller von Medizinprodukten gefährdungsbezogene Use Scenarios ermitteln und beschreiben müssen, damit die Sicherheit, Wirksamkeit und Benutzerfreundlichkeit der Produkte gewährleistet und ein positives Nutzererlebnis geschaffen wird. In unserer vierteiligen Blogreihe berichten wir von unseren Erfahrungen, die wir mit dem Usability-Engineering-Prozess innerhalb eines Pilotprojektes gemacht haben.
Warum die IEC 62366-1 Norm
Im Rahmen unserer ISO-13485 Zertifizierung haben wir nicht nur eine Medical App für brainboost entwickelt, sondern auch unsere Prozesse angepasst, damit diese den Anforderungen für die Entwicklung von Medizinprodukten entsprechen. Hierfür ist die Einhaltung der gesetzlich vorgegebenen Medizinprodukteverordnung (Medical Devices Regulation MDR) einzuhalten. Sie regelt die Anforderungen an die Sicherheit und Leistungsfähigkeit von Medizinprodukten. Während für das Qualitätsmanagementsystem die ISO-13485 Vorgaben macht, wird die Gebrauchstauglichkeit und Usability in der Norm IEC 62366-1 reguliert und legt somit die Standards für ein Projekt fest. Dieser Prozess zielt darauf ab, Verfahrensanweisungen (SOP) zu entwickeln, die die effektive und effiziente Verwendung des Produktes unter Berücksichtigung der Bedürfnisse der Benutzergruppen als auch der Sicherheitsparameter sicherstellen.
Mit der Erstellung und Einhaltung der Verfahrensanweisung (SOP) nach IEC 62366-1 wird die Grundlage für die durch die MDR geforderte Gebrauchstauglichkeit von Medizinprodukten geschaffen.
Verstehen des Usability Engineering Prozesses
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.
Aufsetzen der Standard Operating Procedure (SOP)
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.
Fazit
Die intensive Auseinandersetzung mit der Norm und den Prozessen hat unser Bewusstsein für die Gebrauchstauglichkeit und für mögliche Risiken von Produkten deutlich geschärft, auch außerhalb von Gesundheitsanwendungen. Die Verfahrensanweisungen (SOP) helfen dabei, die Prozesse für alle Beteiligten zu standardisieren und dienen als “Quelle der Wahrheit“. Unsere bisherigen Vorgehensweisen in der Konzeption und Gestaltung von digitalen Produkten konnten wir dadurch ebenfalls formalisieren, was die Transparenz und Effektivität im Team fördert, wobei wir weiterhin nicht auf ein agiles Arbeiten verzichten.
Weitere Beiträge
Wie starten Sie Ihren UX-Prozess?
ION ONE macht Ihnen ein Angebote für Ihren individuellen Einstieg.
Barrierefreiheit Check
Erhalten Sie einen schnellen Überblick, wie zugänglich Ihre digitale Anwendung für Menschen mit Behinderung ist.
Kostenfreie UX-Sprechstunde
Schnell und unkompliziert die kleinen und großen Fragen des UX klären – regelmäßig, kostenfrei und angepasst an Ihren Bedarf.
UX für
E-Healthcare
Wir bieten Ihnen eine kostenfreie Beratung für Ihre benutzerfreundlichen und sicheren E-Health Anwendungen.
Unsere Referenzen tun es für uns.
Es braucht Mut, neu zu denken. Wir helfen Ihnen dabei.
Lassen Sie uns über Ihre Ideen reden.
Grant McGillivray
grant.mcgillivray@ionone.io
Telefon:
+49 30 24627-532