Don't blame the User: Gebrauchstauglichkeit bei Medizinprodukten

Wir alle kennen die Situation: Man möchte eine Herdplatte anmachen, steht jedoch vor vier Knöpfen. Welcher passt zu welcher Herdplatte? Auch nach mehreren Jahren Gebrauch kann es passieren, dass die falsche Platte angeschaltet wird. Hier bleibt das ohne ernsthafte Konsequenzen - man sieht, dass die falsche Herdplatte aufleuchtet und bemerkt den Bedienungsfehler. Was aber, wenn es es nicht um die Herdplatte, sondern um eine Herzpumpe geht?Ein Fallbeispiel: Eine Krankenschwester wollte das Alarmsignal einer Insulinpumpe kurzfristig abschalten, schaltete es stattdessen aber komplett aus. Die nachfolgende Untersuchung zeigte: Der Unterschied zwischen den beiden Schaltern - einmalige versus dauerhafte Abschaltung - war für den Benutzer nicht erkennbar. Und: Der Hinweis, dass der Alarm ausgeschaltet ist, war in einer Ecke des Bildschirms als kleines Symbol versteckt und in der Informationsflut für den Benutzer schlicht untergegangen.Die Food and Drug Administration (FDA) erhält im Jahr circa hunderttausend Incident Reports über medizintechnische Geräte. Über ein Drittel davon sind auf Benutzerfehler (user errors) zurückzuführen (Quelle: Invetech)Wie die IEC 62366 einen Entwicklungsprozess für Gebrauchstauglichkeit beschreibtEs ist leicht, in solchen Fällen die Schuld beim Benutzer zu suchen. Und, sicherlich: Mit einer adäquaten Schulung, einer ausführlichen Einarbeitung und einer weniger hektischen Arbeitsatmosphäre ließen sich viele Fehler im Gebrauch vermeiden. Das aber ist Verantwortung von Krankenhäusern, Praxen und Laboren. Für den Hersteller gilt: Baue ein Produkt, das Benutzerfehler so gut es geht ausschließt.Die Norm IEC 62366 befasst sich mit der Gebrauchstauglichkeit von medizinischen Produkten. Sie beschreibt einen Entwicklungsprozess, der die Gebrauchstauglichkeit von der Erhebung der Anforderungen bis zum Testen im Blick hat. Dazu gehören folgende Schritte:

  • Die Benutzerrollen des Produktes identifizieren.
  • Festlegen, wie das Produkt bestimmungsgemäß gebraucht wird.
  • Nutzungsszenarien beschreiben.
  • Benutzerschnittstellen spezifizieren.
  • Prototypen entwerfen und prüfen.
  • Validierung des Gebrauchstauglichkeit.

Scrum bietet mit seinem Fokus auf den User verschiedene Möglichkeiten, die Gebrauchstauglichkeit im Entwicklungsprozess zu berücksichtigen. Hier seien zwei zentrale Elemente vorgestellt:

  1. Der Einsatz von so genannten Personas ist eine gute Möglichkeit, Benutzerrollen zu identifizieren. Einer unserer Kunden, der Geräte zur Laborautomatisierung herstellt, hat als eine von mehreren Personas eine 25-jährige Lab-Operator mit dem Namen María Morales. Sie nimmt die Laborproben entgegen, packt sie aus und transportiert sie ins Labor. Sie hat mittelmäßige Englisch-Kenntnisse, liest keine Benutzerhandbücher, und verlässt sich stark auf ihre Intuition. María Morales gibt es nicht wirklich, aber ihr Alter, ihre Bildung und Arbeitsweise sind repräsentativ für viele Lab-Operators. Wer solche Personas bei der Produktentwicklung im Blick hat, kann von Anfang an auf ihre Bedürfnisse eingehen und braucht erst gar nicht darauf zu hoffen, dass der Benutzer in kritischen Situationen das Handbuch zu Rate ziehen wird.
  2. Mit dem Review-Meeting am Ende jeden Sprints können die funktionalen Produktinkremente vom Benutzer validiert werden. Fallbeispiel: Ein Kunde entwickelt eine neue Schublade zur Aufnahme von Schalen mit Plastikspitzen, die zum Aliquotieren von Urin- oder Blutproben verwendet werden. Indem eine pharmazeutisch-technische Assistentin (PTA) zum Review der ersten Prototypen eingeladen wird, kann sie bereits die Schublade in Betrieb nehmen und mögliche Bedienungsfehler (z.B. Öffnen der Schubladen im laufenden Betrieb oder Einklemmen der Plastikspitzen) sichtbar machen.

Weitere Möglichkeiten der Validierung über das Review hinaus hat Roman Pichler hier beschrieben.Literatur:Christian Johner u.a. (2011): Basiswissen Medizinische Software. dpunkt.verlagJamie Hartford: Human Factors: Identifying the Root causes of Use Errors

Agile Prinzipien
Kundenfokus
Agile Toolbox
Scrum
bgloger-redakteur
June 10, 2014

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

KI als Teammitglied - Wie Scrum Master von generativer KI profitieren können
BG

KI als Teammitglied - Wie Scrum Master von generativer KI profitieren können

Die Bildungskrise und warum einfache Antworten nicht reichen – auch Scrum4Schools ist da nur ein Tropfen auf den heißen Stein
BG

Die Bildungskrise und warum einfache Antworten nicht reichen – auch Scrum4Schools ist da nur ein Tropfen auf den heißen Stein

Ist KI der neue Kollege von Scrum Master, Agile Coach und Co?
BG

Ist KI der neue Kollege von Scrum Master, Agile Coach und Co?

Scrum Beyond IT: Agile Methoden in HR, Marketing und Produktion
BG

Scrum Beyond IT: Agile Methoden in HR, Marketing und Produktion

Design Thinking - Wirkung auf Organisationen und Menschen neu gedacht
BG

Design Thinking - Wirkung auf Organisationen und Menschen neu gedacht

DeepWork für Autoren – Wie du dein Buch effizient schreibst
BG

DeepWork für Autoren – Wie du dein Buch effizient schreibst

Scrum ist tot, es lebe Scrum!
BG

Scrum ist tot, es lebe Scrum!

Agile Leadership ist nicht gleich agile Leadership
BG

Agile Leadership ist nicht gleich agile Leadership

Seth Godin über Strategie als Denkweise
BG

Seth Godin über Strategie als Denkweise

Die Essenz einer Erfolgreichen Geschäftsstrategie – Einsichten von Seth Godin 
BG

Die Essenz einer Erfolgreichen Geschäftsstrategie – Einsichten von Seth Godin 

Agiles Management – Warum es zur wichtigsten Errungenschaft der Moderne wurde
BG

Agiles Management – Warum es zur wichtigsten Errungenschaft der Moderne wurde

Scrum Beyond IT: Agile Methoden in HR, Marketing und Produktion
BG

Scrum Beyond IT: Agile Methoden in HR, Marketing und Produktion