Elektronische Patientenakten: Akzeptanz bringt den Glanz

Sowohl Behandler als auch Patienten werden eine einrichtungsübergreifende Elektronische Patientenakte nur dann akzeptieren, wenn diese übersichtlich, einfach und unaufwändig bedienbar ist, konstatiert Prof. Peter Haas, Medizininformatiker an der Fachhochschule Dortmund, in einer von uns beauftragten Expertise zu eEPA. Warum Akzeptanz ein wesentlicher Erfolgsfaktor für die Einführung einer IT-Lösung – in diesem speziellen Fall: Elektronischer Patientenakten – ist und wie sie erreicht werden kann, beschreibt Haas pointiert in diesem Gastbeitrag.

Akzeptanz ist nicht die Nutzung alternativloser Lösungen

Akzeptanz (aus dem lat. „accipere“ für gutheißen, annehmen, billigen)

Heute bin ich wieder einmal in Ohnmacht gefallen. Nach Minuten des Geklickes durch die Windows-Ordnerbäume habe ich mich einfach in den Untiefen der Hierarchien auf der Suche nach einer Datei verirrt und den Verstand verloren und bin vom Stuhl gekippt.* Nun bin ich wieder wach und denke darüber nach, ob ich Masochist bin, weil ich diese Bäume trotzdem tagtäglich nutze. Aber habe ich Alternativen? Schließlich tun alle es. Also ist das wohl eine akzeptierte Sache, hat also Akzeptanz gefunden. Wirklich? Akzeptanz? Gibt es da nicht für die Dateiverwaltung dem menschlichen Gehirn wahrhaftig gerecht werdende Lösungsansätze? Aber jetzt sind wir so konditioniert und halten das für den Gold-Standard: Ordner in Ordner in Ordner. Und es gibt sogar elektronische Patientenaktensysteme, die so und nur so funktionieren. Und mein Arzt fällt hoffentlich nicht vor lauter Geklicke um, wenn er mehrere verschiedene Befunde von mir in den Untiefen seines Krankenhaussystems suchen muss, obwohl er daraus nur 4 Informationen in Summe braucht.

(*Suche nach Suchwort hat nicht funktioniert, da ich das passende Wort, das den gewünschten Treffer erbracht hätte, nicht wusste.)

Einerseits also: Es findet Software vordergründig Akzeptanz, die alternativlos ist und die wir faktisch oder qua Gesetz trotzdem halt „as it is“ benutzen müssen. Wir nehmen sie an – auch wenn wir sie nicht gutheißen. Wie wahrscheinlich z.B. den auf der eGK gespeicherten Medikationsplan oder Notfalldatensatz, denn wenn man einen davon oder beide haben will, man immer mit der Karte rumrennen muss (Oh – mein Leben hängt im Notfall davon ab!). Und zum Angucken braucht man Zuhause ein Karten-Lesegerät. Es gibt sogar Ideen bei den Entwicklern im fernen Preußen, dass man ein solches Lesegerät auch an sein Handy anschließen kann, um mobil auf die eigenen Daten schauen zu können. Ggf. müsste aber – wegen des Zwei-Schlüssel-Prinzips – irgendwie auch der Arzt noch seine Karte zeitgleich einstecken können. Vielleicht ja via VPN aus der Ferne. Da alternativlos, findet das eventuell sogar gewisse Akzeptanz und wird zumindest genutzt – was dann als Akzeptanz interpretiert wird. Aber: Massenweise Nutzung alternativloser Lösungen ist nicht gleich echter Akzeptanz!

Und so verhält es sich auch immer noch mit einer Reihe betrieblicher Anwendungen, welche die Menschen nutzen müssen. Massenweise (eigentlich unnötige) Klicks und Mäusekilometer, Verirrungen in Verzweigungsstrukturen und Untermasken sind die neuen Folterinstrumente. Schlechte Software z.B. am Arbeitsplatz ist wie ein unbequemer Bürostuhl oder ein ewig missgelaunter Kollege – täglich muss man wenn es so ist beides aushalten. Privat löscht man schlechte Software einfach vom Handy oder seinem PC. Übrigens ein Geschäftsmodell im eHealth-App-Bereich: Realisiere schnell eine gutklingende Health-App und verkaufe diese so rasch wie möglich via Store 1 Million mal für 1 Euro. Gehe zurück auf „Los“ und mache das nochmal. Und nochmal. Das ist dann eine Erfolgsschleife.

Nehmen wir abschließend Krankenhaussoftware für Ärzte: Der Entwickler denkt sich aus, was der Arzt wohl denkt wenn er denkt und was er braucht wenn er denkt und baut dann etwas, das nicht der Denkwelt des Arztes entspricht, sondern seiner Imagination davon. Der Arzt muss dann Kraft der Entscheidung seiner Krankenhausverwaltung diese „Imaginations-Software“ täglich nutzen. So zeigte eine Umfrage von Kollegin Anke Simon publiziert im Jahr 2017(!): „34 Prozent der Ärzte sind mit der Benutzerfreundlichkeit ihres klinischen Arbeitsplatz-Systems nicht zufrieden, und knapp die Hälfte hält ihr IT-System in der Handhabung, wenn nicht für ungenügend, dann nur für „ausreichend“. „Good enough“ eben, wie Dueck das nennt (Dueck: Die stille Good-Enough-Revolution. Informatik Spektrum_37_4_2014, S. 348 – 351), gerade eben noch gut genug. Mit Blick auf die Endbenutzer steht die Digitalisierung im Gesundheitswesen eigentlich noch am Anfang.

Andererseits aber: Wirkliche und von Herzen kommende Akzeptanz erwächst aus der Freude. Freude, etwas Tolles nutzen zu können, das mir Nutzen bringt und gut und schön zu nutzen ist. Dabei sind beide Kriterien in gewissem Rahmen gegenseitig deckungsfähig: Bei supertollem Nutzen bediene ich auch mal die nicht so optimale Softwareoberfläche. Und: Der Siegeszug von E-Mail und Whats-App sind solche Beispiele: Hoher Nutzen! Oder übertragen auf das Gesundheitswesen die gerade steile Nutzerkurve bei Open Notes mit schon über 20 Millionen Nutzern in den Staaten. Der trockene ISO-Begriff, der im Grunde die Aspekte Nutzen und Nutzbarkeit vereint, ist „Aufgabenangemessenheit“. Oder, wie mein früherer Weggefährte Prof. Pretschner oft sagte: „Software muss sexy sein“. Ja genau – aber eben auch funktional gewinnbringend. Manche Menschen verbringen mehr Zeit des Tages mit einer bestimmten Software, als mit Ihrem Lebenspartner oder anderen Menschen. Schön wenn wir sagen könn(t)en: „Software, ich nehme dich von vollem Herzen an und will mit dir meinen Alltag teilen, weil du mir hilfst und gut zu mir bist.“ Können Sie das von einer Software sagen, die sie täglich nutzen? Ja? Das ist schön für Sie.

Also für von Herzen kommende Akzeptanz müss(t)en die Entwickler wissen,

  1. was für den Nutzer Nutzen bringt und
  2. was für den Nutzer „gut nutzbar“ heißt.

Nutzerpartizipative Software-Entwicklung zahlt sich langfristig aus

Schon Arbeiten in den frühen 90er Jahren und verstärkt um die 2000 sprechen hier vom „wahrgenommenen Nutzen“ und der „wahrgenommenen Einfachheit der Benutzung“ (siehe z.B. Technology Acceptance Model). Dies zeigt und ist natürlich klar, dass Nutzen und Nutzbarkeit auch in gewisser Weise subjektiv sind. Trotzdem kann aber für bestimmte Arbeits-/Lebenssituationen mit einer definierbaren Bandbreite beides gefixt werden. Auf eHealth angewandt: Indikation und Krankheitsstatus determinieren Anforderungen an die Funktionalitäten und den möglichen Nutzen z.B. von Anwendungen für Patienten, allgemeine und individuelle Aspekte determinieren die Benutzbarkeit. Weniger eine Determinante sollte die Erfahrung des Benutzers mit IT-Anwendungen sein. Hier könnte man sich zurückerinnern an Ansätze in den 80ern: Software hatte zur Bedienung verschiedene Modi, vom Laienmodus bis zum Expertenmodus, jeder kann damit umgehen.

Warum aber trifft man immer wieder und immer noch oft bei Messevorführungen auf Lösungen, bei denen man unweigerlich Gänsehaut bekommt – oder im Bekanntenkreis auf Menschen, die sagen: „Oooohhh unsere neue Software … die neue eAkte, das vermiest mir den halben Arbeitstag.“ Weil eben Nutzen und Nutzbarkeit für den konkreten Benutzer immer noch nicht ausreichend mit im Entwicklungsfokus stehen. Vielleicht steht eben nur der Nutzen für das einsetzende Unternehmen, für die Optimierung der Vorgänge darin im Vordergrund. Das zielt aber zu kurz, denn Nutzbarkeit ist auch ein Wirtschaftsfaktor: Wenn Ärzte in Krankenhäusern pro Tag 1 Stunde Zeit durch umständliche System-Nutzung, Abstürze etc. verlieren (so in einem Workshop von Teilnehmern geschätzt), dann müsste das eigentlich auch ein Thema für die Geschäftsführung sein. Man bräuchte das nur einmal in Vollzeitstellen umrechnen. Ist es aber nicht, auch nicht in anderen Branchen, weil dieser Overhead ja ein Problem des Beschäftigten ist, er muss so oder so die anstehende Arbeit bewältigen.

So ist es nicht verwunderlich, dass oftmals vor allem Lösungen, die Betroffene mit erarbeitet haben, viel Akzeptanz und Verbreitung finden (ich denke da z.B. an einen Diabetes-Lösungsansatz mitentwickelt von einem Diabetiker-Kreis, oder eine Palliativakte initial entwickelt von Palliativmedizinern und anderen an der Palliativversorgung beteiligten Berufsgruppenmitgliedern).

Daher gilt es im Bereich eHealth mehr denn je, im Entwicklungsprozess die Partizipation der späteren Benutzer in geeigneter Weise mit einzuweben, am besten in mindestens 3 Feedback-Schleifen. Das ist anstrengend und kostet Geld und Zeit (evtl. eben auch „time to market“) – und hier scheint dann auch der Hase im Pfeffer zu liegen: Nutzerpartizipative Software-Entwicklung – Anfang der 90er-Jahre in vielen Fachartikeln diskutiert und vorgestellt – ist teuer, vielleicht zwei Mal so teuer wie imaginative Entwicklung. Zumal es ja nicht reicht, nur einen Nutzer einzubeziehen: Es sollte schon eine repräsentative Gruppe – z.B. eine Fokus-Gruppe – sein. Und dann müssten auch sauber qualitative Methoden der Sozialforschung zum Einsatz kommen.

Spätere Endnutzer müssen früh in Entwicklungsprozesse eingebunden werden

Wie machen das viele Unternehmen in der Lebensmittelindustrie? Produkte werden dort oftmals mit einer Gruppe von sensorisch begabten Verbrauchern entwickelt und getestet (Konsumenten-Panels). Je nach Vorgehen (ggf. gab es davor schon ein deskriptives Panel) wird das Produkt nach jeder Testrunde entsprechend der Ergebnisse des Sensoriktests modifiziert und wieder getestet, bis man dann ein Ergebnis hat, das im Mittel dem zielgruppenspezifischen Durchschnittsverbraucher schmeckt. Übrigens: Die Panelteilnehmer sind in der Regel fest „gebucht“ und bekommen auch eine kleine Bezahlung für ihren Zeitaufwand und ihre Mitarbeit. Haben Sie das schon einmal in der Software-Industrie erlebt?

Es ist daher für eine flächendeckende akzeptierte Anwendung von gesundheitstelematischen Lösungen unabdingbar, dass schon bei der Spezifikation der Rahmenbedingungen und Leitplanken von Lösungen als auch konkreter Lösungen spätere Endbenutzer einbezogen werden und nicht nur die Imagination Vater und Mutter des Endergebnisses sind. Hier ist die berechtigte Frage angebracht, mit wie vielen Patienten und im Praxisalltag stehenden Ärzten aus Praxen und Krankenhäusern, mit wie vielen Pflegekräften etc. die gematik in den vergangenen 12 Jahre geordnet und wiederholend ihre Planungen besprochen und reflektiert hat.

Zielgruppenorientierte und in diesem Sinne im Gesundheitswesen allgemeine und indikationsspezifische Fokusgruppen müssen zukünftig also für Start-Ups, etablierte Software-Unternehmen, gematik und andere Software-Produzenten im Gesundheitswesen als natürlicher Partner des Entwicklungsteams angesehen und in geeigneter Weise etabliert werden. Sie geben nicht nur wichtige Hinweise auf Nutzenpotentiale und Benutzungsaspekte, sondern können auch helfen, neue von Entwicklern noch nicht gesehene Potenziale aufzudecken.

Gerade vor dem Hintergrund der vielfältigen neuen Interaktionsmöglichkeiten, die von Spracherkennung über Gestensteuerung, Sensorintegration bis hin zu virtual und augmented reality reichen, ist es auch notwendig, die Forschungsbemühungen zu erhöhen, um zu patientengerechten Informatiklösungen für bestimmte indikationsspezifische Ziel- und Altersgruppen zu kommen. Hierfür wäre es auch wertvoll, entsprechende Forschungsprogramme aufzulegen.

Natürlich gibt es noch weitere Aspekte der Akzeptanz (dazugehören, Statussymbol, Vorerfahrung usw.), die aber nicht eine so große Rolle spielen wie Nutzen und Nutzbarkeit, und deren Erörterung den Rahmen dieses Blogbeitrages sprengen würde.

Abschließend sollen 2 Aspekte herausgestellt werden:

  1. Informatiker gestalten nicht nur Technik, sondern sozio-technische Systeme, in denen der Mensch wesentlicher Teil ist. Damit gestalten sie aber auch die Lebensrealität der Menschen um – manchmal sogar in erheblichem Maße. „Sichtwechsel – Informatik als Gestaltungswissenschaft“, so betitelte Arno Rolf einen Buchbeitrag bereits 1992. Wenn wir schon also diese Lebensrealität umgestalten, dann sollte das vor allem im Bereich eHealth zu einer besseren neuen Situation für Betroffene führen, also Nutzen stiften und benutzbar sein. Dies ist eine Verantwortung der Informatiker und aller Entwickler von informatischen Artefakten für Menschen und umso mehr bei der Entwicklung von Lösungen für den Patienten.
  2. Akzeptanz ist der entscheidende Faktor auch und vor allem für eHealth-Lösungen. Akzeptanz bringt den Glanz nicht nur in die leuchtenden Augen der Benutzer, sondern auch in den Geldbeutel der Entwickler oder Anbieter. Die vielbeschworene Digitalisierung des Gesundheitswesens, die ja in Deutschland erst am Anfang steht, ist unausweichlich mit der Akzeptanz bei Heilberuflern und Patienten verknüpft. Dazu bedarf es aber nicht nur nutzbringender Lösungen oder nur schick aussehender und schön zu bedienender Lösungen, sondern beide Aspekte müssen maximal vereint sein, damit etwas zum „Selbstläufer“ wird und somit auch zum flächendeckenden Teil einer modernen Gesundheitsversorgung. Und dazu wiederum bedarf es nicht nur sogenannter „nutzerzentrierter“ Anwendungen, die sich ein Informatiker für bestimmte Nutzer bzw. Nutzergruppen ausdenkt, sondern nutzer-partizipativer Entwicklungsmodelle in den einschlägigen Firmen, in der gematik und wo auch immer Software für Menschen hergestellt wird. Für eHealth-Lösungen könnte also auf der Checkliste der Entwickler vor Projektstart stehen:

„Zu Nutzen und Nutzbarkeit fragen Sie Ihren Arzt, Apotheker und betroffene Patienten“.


Hinweis: Zum Thema siehe auch Kapitel 8 der Expertise zu Elektronischen Patientenakten. Thesen für eEPA dort u.a.:

  • Kernaussage 69: Sowohl Behandler als auch Patienten werden eEPA-Systeme nur dann akzeptieren, wenn diese übersichtlich, einfach und unaufwändig bedienbar sind.
  • Kernaussage 70: Benutzeroberflächen von eEPA-Systemen müssen den Besonderheiten in der Medizin gerecht werden. Dies betrifft sowohl das konzeptuelle Modell der Domäne als Ausgangspunkt für ein Interaktionsdesign als auch die aufgabenspezifischen Informationsbedürfnisse und Aktionen der verschiedenen Benutzergruppen.
  • Kernaussage 71: Repräsentative Vertreter von praktisch tätigen Ärzten, Pflegekräften und Patienten verschiedener Indikations- und Altersgruppen müssen in die Gestaltung der Interaktionsschnittstelle von eEPA-Systemen einbezogen werden. Dabei werden auch spezifische Informationsbedarfe aufgedeckt.
  • Kernaussage 72: Die aufgabenangemessene und effektive Synchronisation der Informationen zwischen iEPA-Systemen und eEPA-Systemen ist ein erfolgskritischer Faktor für die akzeptable und breite Nutzung von eEPA-Systemen.
  • Im Kapitel 9 werden Nutzerpartizipation in Form von Fokusgruppen und thematischen Boards im Rahmen der entwickelten Governance prominent berücksichtigt.

Sie möchten keinen Beitrag verpassen?
Abonnieren Sie hier unseren Newsletter:


Kommentar verfassen