Patientenaufnahme immer und überall

Folgendes Szenario beschäftigte die Mitarbeiter der SRO Langenthal kürzlich. Aus der IT-Abteilung kam die Information, dass demnächst das SAP-System für ein bis zwei Tage ausfallen wird, da ein neues Release eingespielt werden muss. Kenner der Materie und Betroffene wissen, dass diese komplexen Arbeiten am System auch länger dauern können als ursprünglich geplant. Zudem kann es auch danach zu Störungen kommen oder gewohnte Funktionen stehen nicht uneingeschränkt zur Verfügung. Besonders unangenehm ist dies dann natürlich an vorderster Front, dort wo die Patienten aufgenommen werden. Während diese teilweise mit schmerzverzerrtem Gesicht vor einem stehen und mit Mühe und Not ihre Adressdaten aus dem bereits benebeltem Verstand hervorzukramen versuchen, kämpft der Mitarbeiter seinen eigenen Kampf mit dem System, welches gerade unvermittelt «offline» gegangen ist.

Mit Papyrus und Binsenstängel
Der erfahrene Mitarbeiter in der Patientenaufnahme greift dann natürlich sofort zu Stift und Papier und notiert in schönster Druckschrift so schnell wie möglich die Angaben, die dann unvermittelt aus dem Patienten in spe heraussprudeln. Beim nächsten Patienten verzichtet man dann gleich direkt auf die Wartezeit für die Meldung, dass das System nicht verfügbar ist und notiert die notwendigsten Informationen gleich auf einem neuen Zettel. Im schlimmsten Fall muss man diese handschriftliche Ansammlung dann an die nächste Schicht übergeben. Ist das System wieder verfügbar, werden die Aufzeichnungen Stück für Stück in das System übertragen. Das erinnerte mehr an das alte Ägypten als an ein digitalisiertes modernes Spital.

Zeit der Veränderung
Um diesen untragbaren Zustand zu beenden, wurde ein Projekt mit der Firma Consight ins Leben gerufen, welches keine geringere Aufgabe hatte als SAP zu ersetzen, wenn dieses kurz oder etwas länger nicht verfügbar ist. Es wurden also diverse Treffen mit allen Personen, für die dieses Thema relevant ist, abgehalten, und man begann, Ideen zu sammeln. Sehr schnell geriet man dann über die vielen neuen Möglichkeiten, die sich einem damit boten, ins Schwärmen und die Frage war nicht mehr, ob das Projekt tatsächlich umgesetzt werden sollte, sondern nur noch, in welchem Umfang. Genauer gesagt, wann was fertig sein sollte, um ein minimales funktionierendes System zu bekommen. Der Zeitplan wurde dabei hauptsächlich daran angepasst, wann die nächste geplante SAP-Ausfallzeit sein würde. Hochmotiviert machte sich jeder ans Werk. Die einen mit der Analyse des aktuellen Systemverhaltens, die anderen mit der Ausarbeitung des Designs für die verschiedenen Patientenkleber, Stammblätter und Datenschnittstellen. Diese sollten ja später auch ohne SAP zur Verfügung stehen, ohne dass man den Unterschied bemerken würde.

Logischer Entwicklungsprozess
Nach einer sportlichen Entwicklungszeit wurde die erste minimalste Version zum Testen bereitgestellt und dann wöchentlich um weitere Funktionen erweitert. Knapp einen Monat später hatte man ein System, welches zumindest im Online-Modus (SAP ist erreichbar) tat, was es sollte. Dabei wurde die Gültigkeitsprüfung der Daten noch komplett von SAP übernommen und der Anwender hatte die Möglichkeit, mithilfe der SAP-Meldungen die eingegebenen Daten sofort zu korrigieren und erneut an SAP zur Validierung zu übermitteln. Bei Erfolg wurden die Daten sowohl im SAP als auch im Ausfallsystem gespeichert, um sie dort dann für eine spätere Bearbeitung vorhalten zu können. Gleichzeitig wurden Daten, die ausschliesslich im SAP hinterlegt wurden, ins Ausfallsystem gespiegelt, um diese auch dort bearbeiten zu können.

Bisher hatte man also ein System geschaffen, das zumindest das Gleiche leistet wie SAP, wenn dieses denn im Hintergrund angeschlossen ist. Das ist zwar ganz nett, hat aber erst mal nur den Vorteil, dass auf dem Benutzerrechner keine SAP-Gui mehr laufen muss, da das neue System komplett über den Webbrowser zu bedienen ist. Als Nächstes galt es, die Validierung der eingegebenen Daten durch das Ausfallsystem durchführen zu lassen und alle medizinischen Geräte mit Daten zu versorgen. Ein selbstverständlich unerlässlicher Punkt, will man doch ein Ausfallsystem schaff en, welches Daten auch ohne SAP annimmt. Nachdem dies gelungen war, nahm man sich den letzten grossen Punkt vor: die Abkopplung von SAP. Dazu war es nötig, die Daten sowohl im Ausfallsystem zu speichern, als auch später dort verändern zu können, ohne jegliche SAP-Interaktion. Sobald das SAP-System dann wieder erreichbar war, sollten die neu eingegebenen Fälle und Patienten automatisch übertragen werden, ohne dass der Anwender überhaupt bemerkt, dass SAP gerade nicht verfügbar ist.

Ins kalte Wasser gesprungen
Trotz hinreichender Tests kam dann doch ein etwas mulmiges Gefühl auf, als das Ausfallsystem dann für den Ernstfall antreten sollte. Von Freitag bis Sonntag sollte SAP «gewartet» und somit durchgehend nicht erreichbar sein. Die Mitarbeiter in der Patientenaufnahme waren vorbereitet, sie hatt en das Ausfallsystem selbst ausgiebig getestet und waren gespannt, wie sich der tatsächliche Übergang zwischen «SAP verfügbar» und «SAP nicht erreichbar» darstellen würde. Ganz unspektakulär war SAP dann irgendwann nicht mehr erreichbar, ohne dass man im Ausfallsystem etwas davon gespürt hätte. Die nächsten zwei Tage verliefen auch problemlos. Patienten konnten aufgenommen und bearbeitet werden, ohne jegliche Einschränkungen, alles ohne SAP im Hintergrund. Spannend wurde es dann nochmal am Sonntagabend, als der geplante Neustart von SAP näher rückte. Als dann die ersten Fall- und Patientendaten ins SAP einliefen und dort auch noch bearbeitbar waren, fiel wohl nicht nur den Mitarbeitern aus der Patientenaufnahme ein grosser Stein vom Herzen. Letztendlich wurden knapp 1000 Vorgänge in den drei Tagen erfasst und erfolgreich ins SAP überspielt.

Das Ergebnis überzeugt
Schnell zeigte sich, dass Systemausfälle mit dem neue Ausfallsystem ihren Schrecken verloren haben. Steht das SAP-System geplant oder ungeplant nicht zur Verfügung, wechseln die Mitarbeiter in das Ausfallsystem oder haben ohnehin bereits in diesem System gearbeitet, da dies laufend verfügbar ist. Labor, Radiologie, OP, Pflegestationen und alle anderen Abteilungen erhalten uneingeschränkt alle notwendigen Daten, um die Patienten wie gewohnt zu behandeln. Die zeitraubenden Tätigkeiten nach Beendigung des Ausfalls entfallen vollständig.

Torsten Förster ist Geschäftsführer der Firma Consight Swiss GmbH. Im Projekt bei der SRO AG fungierte er als Projektleiter. Die Firma Consight entwickelt und betreibt innovative Softwaresysteme, welche die Digitalisierung des Spitals unterstützen.