„Die Teams nehmen die neue Lösung nicht an“ ist eine bequeme Erklärung. Bevor ich sie akzeptiere, möchte ich wissen, ob die Lösung eine Aufgabe tatsächlich erleichtert. Vielleicht wurde ein zusätzlicher Klick eingeführt, während die bisherige Liste weitergeführt werden muss. Vielleicht fehlen Informationen, die im Nachtdienst gebraucht werden. Vielleicht hat niemand mit den Menschen gesprochen, die später mit den Ausnahmen leben müssen.
Ich komme aus der Kinderkrankenpflege, habe Medizinpädagogik studiert und später an der Schnittstelle zwischen klinischer Praxis und IT gearbeitet. Daher ist für mich klar: Menschen früh einzubinden ist kein freundlicher Zusatz zu einem Digitalprojekt. Es ist eine Möglichkeit, den tatsächlichen Prozess zu verstehen.
Eine Schulung kann ein falsches Konzept nicht reparieren
Stellen wir uns vor, eine Klinik führt eine neue digitale Dokumentation ein. Die Oberfläche ist verständlich und die Schulung gut besucht. Trotzdem dauert eine Übergabe länger, weil Informationen an zwei Stellen erfasst werden und eine wichtige Ausnahme nicht abgebildet ist. Dann hilft eine weitere Erklärung der Buttons wenig. Das Beispiel ist hypothetisch, die Frage dahinter sehr real: Unterstützt das Werkzeug die Arbeit, die tatsächlich stattfindet?
Eine Schulung ist wichtig. Sie kommt aber zu spät, um eine ungeklärte Zuständigkeit oder einen unpassenden Ablauf zu lösen. Wer Akzeptanz will, muss vor der Einführung zuhören und nach der Einführung Änderungen ermöglichen.
Wer gehört an den Tisch?
„Die Pflege wurde beteiligt“ sagt noch nicht, wer beteiligt war. Eine Stationsleitung kennt andere Fragen als jemand im Spätdienst. Eine Ärztin in der Planung sieht andere Engpässe als ein Arzt in der Aufnahme. Hinzu kommen IT, Verwaltung und je nach Thema weitere Berufsgruppen sowie die Perspektive der Patientinnen und Patienten.
Es müssen nicht alle ständig in jeder Sitzung sitzen. Aber ein Projekt sollte benennen, welche Tätigkeiten und Ausnahmen es verändert, und Menschen aus diesen Arbeitsbereichen rechtzeitig einbeziehen. Dabei geht es nicht darum, jeden persönlichen Wunsch umzusetzen. Es geht darum, Folgen einer Entscheidung sichtbar zu machen, bevor sie im Alltag teuer werden.
Vier Schritte, mit denen Beteiligung konkret wird
1. Das Problem gemeinsam beschreiben. Was klappt heute nicht, bei wem und wann? Eine Beobachtung im Arbeitsablauf liefert oft andere Antworten als eine Besprechung, in der nur der Sollprozess gezeigt wird.
2. Die Ausnahmefälle testen. Was passiert bei fehlenden Angaben, wechselnden Zuständigkeiten oder wenn ein System ausfällt? Ein guter Standardfall ist ein Anfang. Die Belastung im Alltag entsteht oft dort, wo der Standard nicht greift.
3. Rückmeldung mit einer Entscheidung verbinden. Wer sammelt Hinweise aus den Teams? Wer entscheidet, was angepasst wird? Und wann erfahren die Beteiligten, warum etwas geändert wurde oder bewusst bleibt? Eine Feedbackrunde ohne Rückweg schafft keine Beteiligung.
4. Aufwand und Nutzen im Dienst prüfen. Nicht nur die Nutzung des neuen Werkzeugs zählt. Entscheidend ist auch, ob doppelte Eingaben, Rückfragen oder Wartezeiten abnehmen und ob der Ablauf für Patientinnen und Patienten verständlicher wird. Dafür braucht es eine Ausgangslage und einen erneuten Blick nach dem Start.
Veränderung braucht klare Verantwortung
Ein Projektteam kann die Einführung organisieren. Es kann aber nicht allein festlegen, wie klinische Verantwortung, IT-Betrieb und tägliche Zusammenarbeit ineinandergreifen. Wenn Rückmeldungen aus der Pflege bei der IT landen, fachliche Entscheidungen aber woanders getroffen werden, braucht es einen klaren Weg zwischen beiden. Sonst wird aus jedem Problem ein Ticket ohne erkennbare Antwort.
Meine Erfahrung aus Pflege und Pädagogik prägt dabei meinen Blick: Menschen wollen verstehen, warum sich eine Arbeit ändert, und erkennen, dass ihre Hinweise ernst genommen werden. Das ist keine Garantie, dass jede Umstellung leicht wird. Es ist die Voraussetzung dafür, Probleme früh zu erkennen und gemeinsam besser zu lösen.
Meine Position: Ein Digitalprojekt ist nicht erfolgreich, weil die Software freigeschaltet wurde. Es ist erfolgreich, wenn die beteiligten Menschen ihre Aufgabe damit verlässlich erfüllen können und eine konkrete Verbesserung im Versorgungsalltag erkennbar ist.
Zum Hintergrund: Das WHO-Handbuch zur digitalen Transformation beschreibt für die Primärversorgung unter anderem Prozessanalyse, Anforderungen und die frühe Beteiligung von Fachkräften. Die SAFER-Empfehlungen zur Einführung von Gesundheits-IT betonen die Zusammenarbeit mit praktizierenden Klinikerinnen und Klinikern sowie die Einbindung in sichere Arbeitsabläufe. Das Dokumentationsbeispiel ist hypothetisch; die vier Schritte sind meine Einordnung für Krankenhausprojekte.
Über den Autor: Lars Drüke-Thiele ist ausgebildeter Kinderkrankenpfleger und studierter Medizinpädagoge. Er begleitete die Einführung von Krankenhaus-IT und analysierte als Clinical Process Engineer klinische Abläufe. Heute verbindet er diese Erfahrung mit digitalen Lösungen und Fachgesprächen über Veränderung im Krankenhaus.
