Sicherheit bei Medizinprodukten

Mit User Centered Design zu mehr Patienten-Sicherheit

23 Oktober 2018
| |

Bedienfehler können gerade bei Medizinprodukten gefährliche Konsequenzen haben. Umso wichtiger ist es, den Nutzer und seine Gewohnheiten bei der Entwicklung zu berücksichtigen. Unsere Erfahrungen bei Zühlke zeigen, dass ein methodisches User Centered Design nicht nur zu einer Verbesserung der Produktfunktionalität und Akzeptanz führt, sondern vor allem das Risiko sicherheitsrelevanter Bedienfehler minimiert. Doch das ist leichter gesagt als getan.

Als Entwickler entwerfen wir Systeme, konstruieren Geräte, entwickeln Software – aber all das immer nur im Büro oder Labor. Anders als bei einem Haushaltsgerät oder einem Entertainment-System fehlt dem Ingenieur bei Medizinprodukten in der Regel der direkte Zugang zum Systemkontext. Wie berücksichtigen wir das in unserem Projektalltag? Wie kriegen wir ein Gefühl für das Produkt, den Anwender und das Umfeld?

Was schief gehen kann, das geht auch schief

Eine gute Gelegenheit für eine ad-hoc-Feldstudie, die wichtige Kontextinformationen für Neu- und Weiterentwicklungen liefern kann, sind da beispielsweise Arzttermine. Ich erinnere mich noch gut an die irritierten Blicke des Pflegepersonals, als wir einen Kollegen nach einem Fahrrad-Unfall im Krankenhaus besuchten. Ich fürchte, wir haben dabei zum Teil den Eindruck erweckt, dass wir uns mehr für Bettgestänge, Rufanlage und Blutzuckermessgerät interessieren als für den Patienten.

Auch ich war vor kurzem bei einem Arztbesuch mit einem Fall von ungenügendem User Centered Design konfrontiert: Es stand die Behandlung mit einem Nd:YAG Laser auf dem Programm. Als das Gerät gestartet wurde, erschien nach einer Weile die Meldung: „FPGA Error“. Kein weiterer Hinweis auf dem ansonsten großen und bunten Display.

Für den Arzt war das offensichtlich auch ein noch unbekanntes Problem: er kontrollierte die Anschlüsse der Lichtleiter auf korrekten Sitz (ich zweifle an der Kausalität, aber vielleicht gibt es ein anderes häufiges Fehlerbild bei dem das schon hilft) und versuchte die Meldung wegzudrücken. Als letzten Ausweg wählte er schließlich den Power-Cycle. Danach startete die Maschine wieder. Bei mir im Hirn lief derweil eine Risiko-Bewertung über die Fortsetzung der Behandlung ab.

Der Anwender ist kein Techniker

In diesem Fall konnte der Anwender aus dem technischen Begriff „FPGA“ (der Abkürzung für Field Programmable Gate Array, einem programmierbaren hochintegrierten Elektronik-Bauteil) keine Schlüsse ziehen. Für einen Elektroniker, Software-Entwickler oder auch einen Service-Techniker wäre die Meldung vielleicht noch ein erster Anhaltspunkt für die Fehleranalyse gewesen, im Feldeinsatz war sie aber nur unverständlich und für den Bediener verunsichernd. Die Perspektive des technisch versierten Experten in der Entwicklung reicht hier einfach nicht aus für eine gute Verständlichkeit und Usability. Dafür noch zwei weitere Beispiele.

Das echte Leben: Den Anwendungskontext kennenlernen

Ein Gerät für den Heimeinsatz informiert und alarmiert den Patienten. Die Anzeige des Alarms erfolgt auf einem LCD. Für das LCD kann die Hintergrundbeleuchtung über einen Knopf kurz eingeschaltet werden, wenn das Display im Dunkeln abgelesen werden muss. Der Alarm wird ebenfalls über einen Knopfdruck quittiert. Also alles wie bei einem Wecker? Was passiert, wenn ein Patient nachts von einem Alarm geweckt wird? Was wird er dann als erstes tun? Natürlich die Beleuchtung einschalten.

Das Problem: Damit wird auch die Warnmeldung quittiert! Bei einem Wecker sieht der Benutzer danach immer noch die aktuelle Uhrzeit, bei dem Medizingerät ist die quittierte Warnmeldung weg! Wann denkt man an diese Situation, wenn man für das Design im hell-erleuchteten Büro sitzt? Bestimmt nicht zufällig, sie könnte aber aus dem Anwendungskontext und Anwenderprofilen hergeleitet werden.

Den Anwender kennen und richtig einschätzen

Das dritte Beispiel stammt aus einer Rückruf-Meldung eines Messgeräts für Blutwerte, über die im FDA-Newsletter informiert wurde. Solche und ähnliche Messgeräte haben einen kalibrierten Messbereich, in dem sie gültige Ergebnis liefern können. Wird der Messbereich überschritten oder unterschritten, sollte der Anwender darüber informiert werden um geeignete zusätzliche Maßnahmen ergreifen zu können.

Im beschriebenen Fall wurde das Überschreiten des Messbereichs mit der blinkenden Zeichenfolge „-0-“ angezeigt. Was lesen Sie daraus? Ein Kürzel für „Overflow“ oder den gültigen Messwert 0 (der aber physiologisch auch bedenklich wäre) oder ein Messergebnis irgendwo unterhalb des Messbereichs? Diese Fehlinterpretationen sind vorgekommen und haben zu erheblichem Therapieverzug geführt. Aber nicht nur Abkürzungen, auch Symbole, Farben, Gesten können je nach Alter, Ausbildung und Kulturkreis sehr unterschiedlich verstanden werden.

Mit User Centered Design zu mehr Patientensicherheit

User Centered Design beschreibt ein Vorgehensmodell und ein Methodenset, um in einem iterativen Prozess zu einer besonders guten User Experience für Ihr neues Produkt zu kommen (Lese-Tipp: Wie sich Produkte durch gute User Experience aus der Masse abheben können). Der Fokus liegt dabei auf den Nutzerbedürfnissen. In vier Schritten werden Lösungen für die Nutzerbedürfnisse entworfen und bewertet. Diese Schritte werden wiederholt durchlaufen, um zu besseren Lösungen zu kommen.

Der erste Schritt ist die Erhebung der Nutzerbedürfnisse gemeinsam mit den Nutzern. Dazu stehen unterschiedliche Methoden zur Verfügung, die je nach Reifegrad der Lösung eingesetzt werden können. Daran schließen die Aufarbeitung und Analyse sowie der Lösungsentwurf an. Im letzten Schritt werden die neuen oder veränderten Gestaltungslösungen wieder unter Einbeziehung der Nutzer erprobt und der Erfolg der Änderungen bewertet. Diese vier Schritte sind in der Grafik dargestellt.
Für die Aktivitäten in diesen vier Schritte gibt es eine Vielzahl bewährter Methoden, beispielsweise

  • Anwender-Beobachtung
  • Apprenticing
  • Persona-Beschreibung
  • User Story Mapping
  • Story-Boards
  • Wireframes
  • Interaktive Prototypen
  • User Walkthroughs
  • Usability-Tests

Die vier Schritte im User Centered Design werden mehrfach durchlaufen. Bei jeder Iteration werden die Szenarien verfeinert, werden die Fragestellungen präziser. Gleichermaßen liegen auch reifere Entwicklungsergebnisse vor, die in den Anwendertests und Befragungen eingesetzt werden können. Dabei ergeben sich sukzessive gut dokumentierte Inhalte, die wir im Rahmen der Medizingeräte-Entwicklung für das Usability Engineering File nach IEC 62366-1 verwenden können.

Das Usability Engineering für Medizinprodukte ist eng mit dem Risiko-Management verzahnt. Vor allem die Anwenderbeobachtung ist eine gute Methode, um zunächst Gefahren zu erkennen und später die Wirksamkeit von Maßnahmen zu bewerten. Beispielsweise gibt ein Zögern oder Überlegen des Probanden wichtige Hinweise, dass sich die Bedienung nicht intuitiv aus dem bisherigen Arbeitsablauf ergibt. Solche Momente in einem Ablauf sind Kandidaten für eine Fehlersituation (vor allem für einen Irrtum oder Aufmerksamkeitsfehler).

User Centered Design, ein agiles Entwicklungsvorgehen und die IEC 62366-1 passen also gut zusammen. Darüber spricht mein Kollegen Dr. Eric Fehse auch häufig auf Konferenzen. In den Slides zu einem seiner Vorträge finden sich weitere Details zu den vier Schritten und den von uns regelmäßig eingesetzten Methoden (Lese-Tipp: Agiles UE nach EN 62366).

Was erwartet die FDA?

Die FDA legt schon lange Wert auf die Beachtung der Gebrauchstauglichkeit von Medizinprodukten. Bereits 2000 erschien ein Guidance Document, um die sogenannten Human Factors im Risikomanagement-Prozess zu berücksichtigen. Das Guidance Document „Applying Human Factors and Usability Engineering to Medical Devices“ (UCM259760) von 2016 setzt diese Linie fort. Das Ziel der FDA ist dabei, die Sicherheit und Effektivität in der Anwendung zu erreichen. Zentrale Einflussgrößen sind die Ausbildung und Fähigkeiten der Anwender sowie die Anwendungsbedingungen. Genau diese Aspekte untersuchen und dokumentieren wir im User Centered Design, so dass sich das Usability Engineering File ganz automatisch füllt.

Wie verifiziert und validiert man?

Am Ende jeder Medizingeräte-Entwicklung steht die Validierung. Hier sind auch die Usability-Aspekte zu berücksichtigen. Durch sogenanntes summatives Usability Testing wird der Nachweis erbracht, dass ein Gerät oder eine Software unter den erwarteten Bedingungen von den vorgesehenen Anwendern erfolgreich bedient werden kann. Hier hilft es, wenn im Requirements Engineering bereits gute Use Cases aufgestellt wurden, aus denen sich die Testszenarien entwickeln lassen. Im Usability Test werden dann potenzielle Anwender dabei beobachtet, ob und wie sie unter realistischen Bedingungen die gestellten Aufgaben erledigen können. (Tipps, worauf man beim Usability Test achten sollte.)

Unsere Erfahrungen

In unseren Projekten setzen wir User Centered Design erfolgreich ein – von der ersten Anwenderbeobachtung bis zum Usability Engineering File. Und gerade bei der explorativen Bewertung von Lösungsalternativen finden wir immer wieder überraschende Erkenntnisse: Warum etwa ein Riegel in einer bestimmten Situation besser ist als ein Schraubverschluss, oder ein Drehknopf besser als ein Touchscreen.

Ein weiterer Vorteil von Usability-Tests ist übrigens: Sie helfen auch gegen Projektblindheit. Letzten Endes sollte immer der reale Anwender das Maß sein, nicht nur die internen Experten und Ideengeber.

Weitere Lese-Tipps:

 

Unsere Erfahrungen mit Usability:

Bessere Software mit Usability-Methoden
Usability Quick Check
Benutzerorientiertes Requirements Engineering
Bessere Medizinprodukte mit Usability

Kommentare (0)

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.