Usability Engineering für Medizinprodukte

Luca Lattanzio

15/02/2021

Einleitung

Was zeichnet ein gutes Produkt aus? Ich persönlich dachte vor meiner Zeit im SW-Engineering immer, dass sich die Anforderungen an ein System im Wesentlichen auf die Funktionalität desselben konzentrieren würden. Tatsächlich ist es aber die Kombination aus Funktionalität und Gebrauchstauglichkeit, welche die Qualität eines Produktes aus der Sicht eines Anwenders bestimmen. In diesem Artikel soll es deshalb um die viel zu selten betrachtete Komponente Gebrauchstauglichkeit (engl. Usability) eines Systems gehen und darum, wie diese in der Welt der Medizinprodukte sicherzustellen ist.

Der Usability-Begriff

Die Norm DIN EN ISO 9241 Teil 11 definiert den Begriff Usability wie folgt:

Die Gebrauchstauglichkeit ist das Ausmaß, in dem ein System, ein Produkt oder eine Dienstleistung durch bestimmte Benutzer genutzt werden können, um in einem bestimmten Nutzungskontext bestimmte Ziele effektiv, effizient und zufriedenstellend zu erreichen.

Dem Usability-Begriff sind also folgende Komponenten zuzuordnen:

  • Benutzer: Der Anwender unseres Produktes
  • Werkzeug: Unser zu entwickelndes Produkt
  • Kontext: Die Umgebung, in der das Produkt eingesetzt wird
  • Aufgabe: Das Ziel, das mit der Benutzung unseres Produktes verfolgt wird

Die Sicherstellung von guter Usability erfolgt durch die Bewertung unseres Produktes nach folgenden Kriterien:

  • Effektivität: Erreichen die Nutzer mit der Benutzung unseres Produktes ihr Ziel?
  • Effizienz: Erreichen die Nutzer mit der Benutzung unseres Produktes ihr Ziel, ohne dabei unnötige Ressourcen zu verschwenden (Zeit, Energie, Motivation)?
  • Zufriedenstellung: Entspricht unser Produkt den Erwartungen der Nutzer?

Usability sollte demnach immer dort eine Rolle spielen, wo Nutzer mit einem Produkt interagieren. Das heißt also: Usability bezieht sich auf Benutzerschnittstellen. Diese können digitaler Natur sein, wie z.B. GUIs und NUIs (Natural User Interfaces, i.d.R. Touchscreens). Aber auch einfachere Benutzerschnittstellen, wie z.B. die Anordnung von Tastern und LEDs auf einem Gerät, sollten hinsichtlich guter Usability entwickelt werden.

Kennenlernen von Nutzungskontext und Aufgabe: Das Contextual Inquiry

Als außenstehender Entwicklungsingenieur ist es nicht immer einfach, das Umfeld, in dem mit einem Produkt gearbeitet wird, sofort zu durchdringen. Abhilfe schafft hier eine Methode mit dem Namen „Contextual Inquiry“, welche das Ziel verfolgt, Nutzer bei der Erledigung einer Aufgabe in ihrem gewohnten Umfeld zu beobachten und zu befragen. Diese Methode folgt einer dynamischen Vorgehensweise und soll eine Anzahl von Ergebnissen erzielen, welche in der Tabelle unten dargestellt sind. Für das bessere Verständnis habe ich als Beispiel die Neuentwicklung eines Ultraschallgerätes ausgewählt, für dessen kontextuelle Analyse ein Orthopäde bzw. eine Orthopädin bei der Arbeit beobachtet werden soll. Das Beispiel ist in seinem Umfang selbstverständlich stark reduziert. Ein echtes Contextual Inquiry würde in diesem Fall vermutlich viele weitere Ergebnisse liefern.

Ergebnis Analyseobjekt Kernattribute Beispiel
Kennenlernen der Aufgaben und Ziele Vorgehen und Handlungsstrategien Tätigkeiten Bänderrupturen diagnostizieren, Flüssigkeitseinlagerungen erkennen
Häufigkeiten Durchschnittlich 7 Benutzungen am Tag
Dauer 3-7 min
Intensität Gründliche Untersuchung bedingt intensive Nutzung
Spezialfälle Keine erkannt
Kommunikation und Rollenteilung Verantwortlichkeiten Feststellen eines Patientenbefunds, Unterweisung der Assistenz, Ablauf der Untersuchung
Kommunikationsinhalte Anweisungen an Assistenz, Mitteilung des Befunds
Kommunikationsmittel Sprachlich, schriftlich
Kommunikationszweck Praxisorganisation, Festlegung weiterer Schritte
Hintergrundinformationen Domänenwissen Begrifflichkeiten: Erstellung eines Glossars
Kennenlernen des Kontextes Physisch Räumlichkeiten Untersuchungsraum
Beleuchtung Normale bis helle Zimmerbeleuchtung
Temperatur Zimmertemperatur (ca. 21°C)
Einflüsse durch Schmutz oder andere Substanzen Ultraschallgel, ggf. Blut
Sozial, kulturell Verhaltensregeln Professionelles Auftreten, Benutzung verständlicher Sprache
Andere Personen Sprechstundenassistenz, Patient
Werte Wohlergehen des Patienten
Organisation Rollenteilung Orthopäde bzw. Orthopädin: leitende Person, primärer Benutzer bzw. primäre Benutzerin

Sprechstundenassistenz ist: sekundärer Benutzer bzw. sekundäre Benutzerin

Unterbrechungen Durch Notfall

Diese Tabelle soll als Anhaltspunkt für das Contextual Inquiry dienen und bietet demnach keine Garantie auf Vollständigkeit. Beim Contextual Inquiry existieren lediglich Richtlinien, von denen je nach Situation abgewichen werden kann bzw. muss.

Entwickeln von Essential Use Cases

Nachdem wir im Zuge des Contextual Inquiry nun unsere Aufgabe und deren Kontext kennengelernt haben, wollen wir daraus Anwendungsfälle für das zu entwickelnde Werkzeug ableiten. Davor ist allerdings zu erwähnen, dass ich in diesem Artikel aus Gründen der Übersichtlichkeit einen wesentlichen Schritt überspringe: die Identifikation von Nutzergruppen und das Ablegen dieser in sogenannten Personas, welche fiktive Personen mit echten Eigenschaften aus ihrer respektiven Nutzergruppe darstellen. Einen vertiefenden Einblick dazu bietet der Artikel „Personas“ auf der Seite für Usability Richtlinien des U.S. General Services Admission for Technology Transformation Services.

Nun aber zurück zu den Use Cases: Eine effektive Methode, Use Cases für die Entwicklung von innovativen Produkten aufzuschreiben, ist die Formulierung von sogenannten „Essential Use Cases“. Im Vergleich zu den Conventional Use Cases sind diese kompakter und beschreiben die Systemverantwortlichkeiten aus der Sicht eines Benutzers. Es wird deutlich, dass die Essential Use Cases dem Bereich der menschenzentrierten Softwareentwicklung entstammen.

Den Unterschied zwischen Essential Use Case und Conventional Use Case soll der folgende Vergleich deutlich machen. Das gewählte Beispiel ist der Vorgang  „Patientendaten einsehen“ bei einem Patientenverwaltungssystem.

Use Case ID: UC101
Use Case Name: „Patientendaten einsehen“
Involved Personas: Kathrin Musterfrau
Conventional Use Case Essential Use Case
User Action System Response User Intention System Responsibility
Open application Request login credentials To have secure access Verify identity
Enter Username and Password To view patient data Offer search possibilities,
Show search results
Press Enter Key Verify credentials,
Show menu
To logout Offer logout possibilities
Select „Search Patient Database“ Request patient name and DOB
Enter patient surname and DOB
Press Enter Key Parse database,
Show results
Press Logout Button Logout,
Show logout message

Zusammenfassend kann man also sagen, dass Essential Use Cases einerseits kompakter sind und andererseits den Freiheitsgrad bei der Ableitung der Requirements erhöhen, was die Innovation im Entwicklungsprozess beflügelt. Die Essential Use Cases können z.B. in Templates erfasst und in einem sogenannten Use Case Diagramm festgehalten werden. Was Use Case Diagramme sind und wie man sie modelliert, kann in unserem Artikel über Anwendungsfalldiagramme nachgelesen werden.

Nutzungsanforderungen (Usability Requirements)

Im nächsten Schritt des Prozesses werden wir uns den Anforderungen an unsere Nutzerschnittstelle widmen, welche die Grundlage für einen Prototypen bilden.  Die Nutzungsanforderungen leiten sich aus den Essential Use Cases ab, die wir zuvor, z.B. mithilfe von Templates, erfasst und niedergeschrieben haben. Beim Erstellen von Requirements gilt es laut dem Leitfaden für Usability des Deutschen Akkreditierungsdienst (DAkks) die Einhaltung der drei Gütekriterien zu beachten:

  • Objektivität: Eine Nutzungsanforderung muss so formuliert sein, dass Sie frei von Einflüssen der Stakeholder ist und einem tatsächlichen Erfordernis entspricht, das aus der Analyse des Nutzungskontextes hervorgegangen ist.
  • Widerspruchsfreiheit: Eine Nutzungsanforderung sollte anderen Nutzungsanforderungen nicht widersprechen. Sollte das trotzdem vorkommen, so ist dies auf die Existenz einer weiteren Benutzergruppe oder eines weiteren Nutzungskontextes zurückzuführen, für welche eigenständige Ist-Analysen (Kontext- und Nutzeranalysen) durchzuführen sind.
  • Validität: Eine Nutzungsanforderung muss auf Daten beruhen, die durch Personen, die in repräsentativen Positionen tätig sind, bestätigt wurden und ggf. korrigiert worden

Für die Formulierung von Nutzungsanforderungen wird an dieser Stelle folgende Syntax vorgeschlagen: „Ein Nutzer muss am System <Tätigkeit> können.“
Für <Tätigkeit> kann ein Prädikat zusammen mit einem Objekt eingesetzt werden.

Einige Beispiele, welche auf den Use Case Patientenverwaltung zurückgreifen, soll die Formulierung veranschaulichen:

  • „Ein Nutzer muss am System seine Identität bestätigen können“
  • „Ein Nutzer muss am System Patientendaten anzeigen können“
  • „Ein Nutzer muss sich vom System ausloggen können“

Prototyping

Im Prozessschritt Prototyping geht es um das Umsetzen der Nutzungsanforderungen im Zuge eines visuellen Gestaltungsprozesses, an dessen Ende ein testbarer Prototyp steht. Die Ausgestaltung kann toolbasiert erfolgen, wobei hier, je nach Oberflächentyp, verschiedene Tools zur Verfügung stehen. Abhängig von der erforderten Reife des Prototypen können aber auch schon eine einfache Skizze, welche mithilfe der sogenannten Wizard-of-Oz-Technik zum Leben erweckt wird, oder ein sogenannter Wireframe einen testbaren Prototypen bereitstellen. Die Vorteile dieser Arten von Prototyp liegen auf der Hand: Sie sind einerseits sehr günstig, andererseits sind sie meist innerhalb kürzester Zeit verfügbar und können damit als Diskussionsgrundlage für Akutsituationen genutzt werden. Für Benutzerschnittstellen, die sich nicht auf Bildschirmen, sondern beispielsweise auf Bedienpanels an einem Gerät befinden, muss in der Regel leider mehr Aufwand betrieben werden: Testbare Prototypen sind oft nur Hardware Mockups, welche unter Einbezug von Fertigungsverfahren entwickelt werden müssen (z.B. mithilfe von 3D-Druck). Nichtsdestotrotz habe ich aber auch schon von Firmen gehört, welche sich hinsichtlich der Hardware Mock-Ups z.B. mit Lego-Bausteinen oder Prototypen aus Pappe beholfen haben. Wie immer in der Entwicklungsarbeit, ist auch hier Kreativität gefragt.

Ein Wireframe für eine Sonografie GUI (sehr vereinfacht)

Usability Evaluation

Das Ziel einer Usability Evaluation ist das Testen eines Prototypens hinsichtlich der Usabilitymetriken Effektivität, Effizienz und Zufriedenheit. Hierzu bieten sich eine Palette an Verfahren an. Ich möchte an dieser Stelle speziell auf eine besondere nutzerorientierte Beobachtungsmethode eingehen, welche sich, wie der Name schon sagt, auf die Beobachtung von Nutzerinteraktionen mit dem Werkzeugprototypen stützt. Die genannte Methode wird als Usability Walkthrough bezeichnet.

Die Beobachtung findet dabei im echten Nutzungskontext statt, also beispielsweise in einer Praxis oder Klinik, in welcher der Teilnehmer, also in der Regel ein Arzt, arbeitet. Einem Teilnehmer, welcher zu einer unserer identifizierten Nutzergruppen gehören sollte, werden während der Beobachtung Aufgaben gestellt, die dieser ohne zusätzliche Hilfestellung durch den Evaluator zu lösen hat. Die Aufgaben sind dabei möglichst realitätsnah zu stellen. Eine passende Fragestellung wäre beispielsweise im Falle des Ultraschallgeräts: „Erstellen Sie mit dem Ultraschallgerät bitte ein Bild des rechten Außenbandes des Patienten“. Wichtig ist vor Allem, dass der Teilnehmer im Zuge der Aufgabenlösung laut denkt, sodass der Evaluator seine Gedankenschritte nachvollziehen und gegebenenfalls notieren kann. In manchen Fällen ist es sinnvoll, den Test in irgendeiner Form aufzuzeichnen, z.B. mit einem Video. Dabei sollten datenschutzrechtliche Aspekte aber im Vorhinein in jedem Falle abgeklärt werden. Um einen repräsentativen Eindruck der Usability eines Produktes zu bekommen, sollten so viele dieser Tests mit unterschiedlichen Teilnehmern wie möglich durchgeführt werden. Auffälligkeiten, sogenannte Usability Issues, sollten in die Entwicklung zurückgeleitet werden, um gegebenenfalls Anforderungen anzupassen oder neue zu verfassen.

Weitere, bei Medizinprodukten in Frage kommend, nutzerorientierte Methoden zur Evaluation von Usability:

  • Hallway Test
  • Pluralistic Walkthrough
  • Formaler Usabilitytest
  • Fragebogen

Fazit

Usability ist für die Produktentwicklung in der Medizintechnik ein sehr wichtiges Thema, da sich schlechte Usability in der vom Nutzer wahrgenommenen Qualität des Produktes bemerkbar macht. Usability Engineering sollte als zyklischer Prozess gesehen werden, der im Verlauf einer Neuentwicklung oder des Redesigns eines Produktes mehrfach durchlaufen wird. Usability Engineering muss möglichst mit dem Kick-off eines Projektes beginnen und sollte nicht hinten angestellt werden. Wichtig ist dafür der Aspekt des Prototypings, der dem noch nicht komplett ausgereiften Produkt eine Evaluation hinsichtlich seiner Usability ermöglicht.


Geschrieben von Luca Lattanzio

Luca ist studierter Elektrotechnik-Ingenieur und sammelte während seines Studiums sowie in der Zeit danach wertvolle berufliche Erfahrungen bei MEDtech. Obwohl er inzwischen für ein anderes Unternehmen tätig ist, bleibt er bei MEDtech als Autor erhalten und verfasst gelegentlich Beiträge, um seine Expertise und Leidenschaft für seinen Beruf zu teilen. Darüber hinaus zählt er weiterhin zu den engagierten Lesern des Blogs.


Weitere Beiträge

  • 30/06/2024
  • Allgemein, Hardware, Software, Technik, Tools, Usability

KI – Was ist das denn überhaupt? Künstliche Intelligenz ist zurzeit in aller Munde, doch die wenigsten Menschen beschäftigen sich mit der Funktionsweise von künstlicher Intelligenz oder damit, was ...

Weiterlesen
  • 30/01/2024
  • Allgemein, Security, Software, Usability

Wo ist denn jetzt wieder dieses Headset? Wer kennt es nicht, man möchte sein Smartphone mit einem Bluetooth-Gerät verbinden, startet den Suchvorgang und plötzlich sieht man den Wald vor ...

Weiterlesen
  • 04/07/2023
  • Allgemein, Hardware, Technik

Kennst du dich mit Batterien und Akkus aus? Der Livestream „Keysight: Live from the Lab“ gibt eine gute Einführung in die Thematik. In dieser Livestream-Reihe, die von Keysight gehostet ...

Weiterlesen
Cookie-Übersicht

Die Internetseiten der MEDtech Ingenieur GmbH verwenden Cookies. Cookies sind Textdateien, welche über einen Internetbrowser auf einem Computersystem abgelegt und gespeichert werden.

Zahlreiche Internetseiten und Server verwenden Cookies. Viele Cookies enthalten eine sogenannte Cookie-ID. Eine Cookie-ID ist eine eindeutige Kennung des Cookies. Sie besteht aus einer Zeichenfolge, durch welche Internetseiten und Server dem konkreten Internetbrowser zugeordnet werden können, in dem das Cookie gespeichert wurde. Dies ermöglicht es den besuchten Internetseiten und Servern, den individuellen Browser der betroffenen Person von anderen Internetbrowsern, die andere Cookies enthalten, zu unterscheiden. Ein bestimmter Internetbrowser kann über die eindeutige Cookie-ID wiedererkannt und identifiziert werden.

Durch den Einsatz von Cookies kann die MEDtech Ingenieur GmbH den Nutzern dieser Internetseite nutzerfreundlichere Services bereitstellen, die ohne die Cookie-Setzung nicht möglich wären.

Mittels eines Cookies können die Informationen und Angebote auf unserer Internetseite im Sinne des Benutzers optimiert werden. Cookies ermöglichen uns, wie bereits erwähnt, die Benutzer unserer Internetseite wiederzuerkennen. Zweck dieser Wiedererkennung ist es, den Nutzern die Verwendung unserer Internetseite zu erleichtern. Der Benutzer einer Internetseite, die Cookies verwendet, muss beispielsweise nicht bei jedem Besuch der Internetseite erneut seine Zugangsdaten eingeben, weil dies von der Internetseite und dem auf dem Computersystem des Benutzers abgelegten Cookie übernommen wird.

Die betroffene Person kann die Setzung von Cookies durch unsere Internetseite jederzeit mittels einer entsprechenden Einstellung des genutzten Internetbrowsers verhindern und damit der Setzung von Cookies dauerhaft widersprechen. Ferner können bereits gesetzte Cookies jederzeit über einen Internetbrowser oder andere Softwareprogramme gelöscht werden. Dies ist in allen gängigen Internetbrowsern möglich. Deaktiviert die betroffene Person die Setzung von Cookies in dem genutzten Internetbrowser, sind unter Umständen nicht alle Funktionen unserer Internetseite vollumfänglich nutzbar.

Weitere Informationen erhalten Sie in unserer Datenschutzerklärung.

Unbedingt notwendige Cookies

Dieses Cookie wird benötigt, um Ihre Cookie-Einstellungen zu merken und weitere Hauptfunktionen zur Verfügung zu stellen

Um Ihnen eine Auskunft über Ihre gespeicherten personenbezogenen Daten hier (https://medtech-ingenieur.de/gespeicherte-daten-2/) geben zu können, benötigen wir einen Cookie, um Sie bei der Datenabfrage identifizieren zu können. Dieser Cookie muss aus Sicherheitsgründen deshalb aktiviert sein. Ein weiterer Cookie wird gesetzt, um diesen Banner nicht erneut anzeigen zu müssen.

Cookie-Name Beschreibung
PHPSESSID Name: PHP session
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Wir benötigt, um Sie bei der Anfrage von personenbezogenen Daten identifizieren zu können. Das Cookie wird nur gesetzt, wenn Sie eine Anfrage hier (https://medtech-ingenieur.de/gespeicherte-daten-2/) stellen.
Laufzeit: Sitzungsende
Kategorie: Unbedingt notwendige Cookies
moove_gdpr_popup Name: Cookie-Box Einstellungen
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Wird benötigt, um Ihre Cookie-Einstellungen zu speichern, um den Cookie-Banner nicht erneut anzeigen zu müssen.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
comment_author_9c90e388e3e1be4a6c594fa6ac8a3eec
comment_author_email_9c90e388e3e1be4a6c594fa6ac8a3eec
comment_author_url_9c90e388e3e1be4a6c594fa6ac8a3eec
Name: Kommentar Einstellungen
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Cookie wird angelegt, wenn Sie ein Kommentar auf MEDtech Ingenieur veröffentlichen wollen, um Sie als Autor identifizieren und den aktuellen Status Ihres Kommentars anzeigen zu können. Das Cookie enthält den angegebenen Namen. Das Cookie wird erst gesetzt, wenn Sie der Speicherung Ihrer personenbezogenen Daten zustimmen.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
rmp-rate Name: RMP Rate
Anbieter: Eigentümer der Webseite (MEDtech Ingenieur)
Zweck: Cookie wird angelegt, wenn Sie eine Bewertung eines Blogbeitrags mithilfe des Sternebewertungssystems abgeben. Ihnen wird eine anonymisierte ID zugewiesen, um zu erkennen, ob Sie einen Artikel bereits bewertet haben oder nicht. Das Cookie wird nur verwendet, um zu verhindern, dass mehrfache Bewertung abgegeben werden und erst gesetzt, wenn Sie auf einen Stern klicken.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
medtech-download-page Name: Download Page
Anbieter: Eigentümer der Webseite (MEDtech Ingenieur)
Zweck: Cookie wird angelegt, wenn Sie den Landing-Page Prozess erfolgreich durchlaufen haben. Dies geschieht nur, wenn Sie einen Content-Download von unserer Website anstreben.
Laufzeit: 1/2 Jahr
Kategorie: Unbedingt notwendige Cookies