Stolpersteine der PDMS-Einführungen

Die Einführung eines PDMS ist ein seltener Anlass — Lebenszeiten von 10 oder 20 Jahren sind keine Seltenheit, wodurch viele IT-Teams in den Kliniken dieses Abenteuer nur ein einziges Mal bestreiten. Gegenübergestellt sind in der Regel die externen Projektleiter der Hersteller. Einerseits ein enormer Gewinn an Erfahrung, da diese das Produkt im besten Fall schon in vielen vergleichbaren Kliniken installiert haben, und in anderen Konstellationen eine Herausforderung.

Als Mitarbeiter des Herstellers ist man oft dazu veranlagt, primär dessen Interessen zu berücksichtigen. Das ist in den meisten Fällen weder dramatisch noch hinderlich, allerdings führt es dazu, dass Themen, die ausschließlich für die Klinik von hoher Bedeutung sind, ab und an in einen blinden Fleck rutschen.

Nach meinem Wechsel in die Arbeit als unabhängiges Consultingunternehmen wurden mir in dieser Hinsicht noch einmal deutlich die Augen geöffnet: dadurch, dass ich nicht mehr selbst die Mittagspause mit den Lieferanten und Dienstleistern verbrachte, wurde mir erst klar, wie Projekte durch implizites Wissen und ausbleibende Kommunikation undurchsichtig gemacht werden.

Diese Unsicherheit ist aus der Perspektive von mir und unseren Partnerkliniken an vier Stellen besonders kritisch.

Die Einführung eines PDMS ist ein teures Unterfangen — siebenstellige Beträge und langjährige Projekte diktieren einen klar strukturierten Ausschreibungsprozess. Setzt die Klinik dabei auf einen starken Partner, dann startet sie unter guten Voraussetzungen in das Projekt: ein Leistungsverzeichnis, das alle Bedürfnisse an das PDMS abbildet und die Grundlage für die Projektanforderungen bildet.

Daraus leiten sich in der Regel Preis, Projektlaufzeit und die Grundzüge des Managements ab. Das Zusammenstellen des Leistungsverzeichnisses ist ein ganz eigenes Thema. An dieser Stelle möchte ich nur dazu anhalten, angemessen viel Zeit in diese Phase der Beschaffung zu investieren und ein möglichst diversifiziertes Team aus Fachkollegen, Controllingmitarbeitern, der IT, Forschung und Medizintechnik zusammenzustellen, damit die kommende Software auf stabilen Beinen steht.

Nach Auftragserteilung und Projektbeginn begegnen wir zumeist der ersten, entscheidenden Stolperfalle: die Erstellung des Fachkonzepts auf Grundlage des Leistungsverzeichnisses. Handelt es sich beim Leistungsverzeichnis zumeist noch um eine trockene Auflistung von Muss-Kriterien, so geht es jetzt darum, ein Dokument zu schaffen, auf dessen Grundlage das PDMS entwickelt und ausgeliefert wird.

Zuerst einmal: für diese wichtige Phase ist eine kompetente und entscheidungsfähige Fachgruppe unabdingbar. In vergangenen Projekten hat sich eine Größe von 5-10 Personen für mich bewahrheitet.

Zusammengesetzt sollte sie aus Ärzten und Pflegern sein, die alle für das PDMS relevanten Fachbereiche vertreten können. Dazu kommen 1-2 Vertreter der IT, die das System später betreuen und konfigurieren, und 1-2 Kollegen aus dem Medizincontrolling, die lästige Fragen wie „Was genau brauchen wir, damit wir das Weaning abrechnen können?“ am besten beantworten können.

Man sollte sich auch sofort darauf einigen, ab welcher Teilnehmeranzahl die Fachgruppe entscheidungsfähig ist, da insbesondere Ärzte oft dazu neigen, für andere Themen abgezogen zu werden.

Hat man seine Fachgruppe beisammen, so geht es in die Diskussion mit dem Hersteller, um die Umsetzung zu diskutieren und zu skizzieren — hierbei ist der Hersteller in der Regel Schriftführer und legt damit am Ende der Abstimmungen das Dokument vor, auf dessen Grundlage das Customizing durchgeführt wird. Darauf folgen Unterschriften, Händedruck und das gemeinsame Einverständnis, dass das Fachkonzept das endgültige Lieferobjekt beschreibt.

Das führt einerseits dazu, dass der Hersteller alle relevanten Produktbestandteile von Anfang an einplanen kann, und sorgt andererseits dafür, dass keine Features vergessen werden. Die emotionale Aufregung bei der ersten Nachtschicht in der Einführungswoche mit einem Chefarzt darüber zu „diskutieren“, warum das Feature, das er explizit schriftlich angefordert hat, weder existiert noch existieren wird, möchte ich Ihnen gern ersparen.

Der medizinische Alltag ist komplex, viele Kliniken decken mit ihren Intensivstationen und Operationseinheiten 20+ Fachbereiche ab, und jeder Patient ist ein klein wenig anders. Umso absurder, dass eine Fachgruppe in einigen wenigen Terminen zu einem schriftlichen Konzept kommen soll, das diese Sachverhalte perfekt abbildet, ohne auch nur einmal mit dem erdachten Produkt gearbeitet zu haben.

Hat sie diese unter Punkt 1 aufgeführte Herausforderung allerdings gemeistert, dann ist fest davon auszugehen, dass viele Dinge noch nicht so recht funktionieren, zusammenpassen oder im Alltag wirklich verwendbar sind. Das ist auf Grund der Komplexität beinahe unvermeidbar, obwohl kompetente Fachberater der Hersteller und Fachmitarbeiter mit IT-Affinität die Abweichungen durchaus reduzieren können.

Daraus folgt, dass die Lieferart, die in vielen PDMS-Projekten angestrebt wird, oft nicht mit diesen Komplexitäten zusammenpasst: eine Gesamtlieferung der kompletten Konfiguration führt zu ausgesprochen viel Stress. Insbesondere dann, wenn sie wenige Wochen vor der Inbetriebnahme erfolgt und im Plan lediglich mit einem kurzen Review hinterlegt ist.

Zuerst einmal ist die Testung eines gesamten PDMS eine sehr zeitaufwändige Aufgabe — die Freistellung von Fachmitarbeitern über ganze Wochen hinweg gestaltet sich oft als schwierig, weshalb eine solche „Crunchtime“ oft ausgesprochen schwer mit dem Klinikalltag vereinbar ist.

Zusätzlich bleibt zu wenig Zeit, um zu reagieren — es ist völlig natürlich, dass nach dem ersten probehaften Arbeiten mit der umgesetzten Konfiguration noch einmal zahlreiche Wünsche und Verbesserungsvorschläge aufkommen.

Die Auswertung meiner eigenen Tickets für die Umsetzung in 7 Inbetriebnahmen ergab, dass rund 24 % aller Anpassungen in den Tagen nach der Auslieferung der Konfiguration und in den ersten Tagen des Produktivbetriebs passieren. Diese sind zeitlich oft nicht aufwändig, weil es sich mehr um das Umverteilen, Addieren und Subtrahieren von Informationen und sehr selten um die komplette Neuimplementierung vergessener Produktfeatures handelt, allerdings braucht die Fachgruppe natürlich dennoch Zeit, um diese Bedürfnisse zu erkennen und zu kommunizieren — genauso wie der Hersteller Kapazitäten benötigt, um darauf reagieren zu können.

Aus diesem Grund bestehe ich in meinen PDMS-Projekten immer auf Teillieferungen.

Dadurch hat die Fachgruppe über mehrere Monate hinweg eine gut planbare, konstante Arbeitslast, die Feedbackzyklen für den Hersteller bleiben kurz, und die Bedienbarkeit des Produkts verbessert sich spürbar. Wenn das nicht möglich ist, dann plane ich einige Monate zwischen der Erstlieferung und der Inbetriebnahme ein, damit realistisch Zeit für einige zusätzliche Iterationszyklen besteht.

Sind die Tage der Einführung geplant, dann würde ich mittlerweile meinen Weihnachtsbonus darauf verwetten, dass mir bei der Rückfrage nach der Schulung der Mitarbeiter die folgende Aussage vorgesetzt wird:

„Die Pflege hat sich gut organisiert, wir haben Schulungsleiter und Key User benannt, die Termine sind eingeplant und an die Kollegen kommuniziert. Bei den Ärzten … Tja, die bringen sich das gegenseitig bei, wenn sie zwischen zwei Anrufen Zeit haben. Es ist völlig utopisch, die Ärzte für so etwas zu verplanen.“

Auf Grund dieser — nennen wir es „dezentralisierten“ — Lernweise ist es unabdingbar, dass im Rahmen des Projekts sehr viel Wert auf die Erstellung von Schulungsunterlagen gelegt wird.

Wie diese genau aussehen, basiert stark auf der Klinik — von elektronischen Handbüchern über eLearning-Plattformen bis hin zu Videotutorials habe ich schon viele verschiedene Lösungswege kennengelernt. Und manche meiner Videos sind ohne mein Einverständnis auf YouTube gelandet — aber das ist ein anderes Thema.

Fakt ist, dass die Erstellung dieser Schulungsmöglichkeiten vor allem eines benötigt: Zeit. Dennoch taucht dieser Schritt nicht in vielen Projektplänen auf — in der Regel, weil der Hersteller oft nicht im Rahmen des Projekts dazu verpflichtet wurde, diese zu erstellen. Es ist also entweder notwendig, die Erstellung dieser Dokumente in das Angebot zu integrieren, oder aber klinikintern möglichst früh die Erstellung einer ausführlichen Schulungsoption zu priorisieren und einzutakten.

Besonders zu berücksichtigen ist dabei auch die Mitarbeitersituation der Klinik: umso höher die Fluktuation der Mitarbeiter oder der Anteil an Leasingkräften, umso wichtiger wird dieses Thema. Und umso schneller muss das Lernmaterial neue Kollegen arbeitsfähig machen.

Ein oft wenig diskutiertes Thema sind auch die Sprachen, in denen das Material erstellt wird — umso höher der Anteil der Mitarbeiter, die eine bestimmte Sprache sprechen, umso attraktiver kann es sein, Übersetzungen ebenfalls in die Erstellung einzuplanen.

Mein erster Entwurf beinhaltete lediglich drei Stolpersteine — die Zahl liest sich einfach besser und wird von der Literatur immer und immer wieder bevorzugt. Ich konnte es mir dennoch nicht nehmen lassen, einen vierten Musketier ins Boot zu holen.

Es gibt aus meiner Projektarbeit nämlich genau ein Thema, das für mindestens 87 % meiner grauen Haare verantwortlich ist: Medikationsstammdaten und deren Integration in das PDMS.

Im Folgenden nur einige der Stichpunkte, weshalb das Thema mit höchster Priorität und möglichst früh im Projekt betrachtet werden muss:

Aus meiner Erfahrung wird der Punkt der Medikamentenstammdaten in fast jedem Projektplan stiefmütterlich behandelt und führt damit oft zu Verzögerungen — bevor das Thema nicht geklärt ist, lassen sich Integrationstests, Entwicklungen und Vorbereitungen für die Inbetriebnahme kaum bis gar nicht durchführen.

Es gab bis jetzt noch keines unserer betreuten Häuser, in dem die Medikamente noch nicht zum Konfliktthema wurden — ganz gleich, ob man mit einem etablierten Katalog oder einer Hausliste startet, jedes PDMS hat andere Anforderungen an die Stammdaten, und die Darstellung ist in jedem System ein wenig anders, wodurch die Ärztebelegschaft oft Nachpflegebedarf identifiziert.

Zusätzlich sollten vor den ersten Gesprächen zu diesem Thema klare Ziele für alles formuliert werden, das mit Medikamenten zu tun hat. Wenn die Medikamente beispielsweise nur lokal im PDMS dargestellt werden, dann ist es völlig legitim, wenn die Stammdaten lediglich Wirkstoff abbilden.

Will man die Apotheke voll integrieren, dann entstehen plötzlich ganz andere Anforderungen an Schnittstellen und Datenkonstrukte.

Das Thema ist so komplex, dass unser Unternehmen in Kooperation mit einigen Kliniken an einer eigenen Komplettlösung für den Austausch von Medikamentenstammdaten, Verordnungsplänen und Gabeinformationen zwischen beliebigen KIS- und PDMS-Systemen arbeitet.

Dieser Artikel versteht sich nicht als erschöpfender Bericht aller Dinge, die in einem PDMS-Projekt schiefgehen können — er ist viel mehr eine Sammlung der Dinge, die mich beim Durchgehen der Dokumente eines neuen Projekts aufmerksam werden lassen.

Schwierig wurde es in der Vergangenheit immer dann, wenn ich erst relativ spät in die Projekte gekommen bin — allerdings habe ich in diesen herausfordernden Situationen auch gelernt, zahlreiche Probleme auf einmal zu bewältigen, zu priorisieren und das unberechenbare Chaos des Klinikalltags mit dem berechenbaren Chaos komplizierter Projekte zu vereinen.

Sollten Sie Fragen, Erfahrungsberichte oder emotionalen Zuspruch benötigen, dann scheuen Sie sich nicht, mich zu kontaktieren.

Herzlichst,