Fallstudie: 15 Jahre alte Medizinsoftware modernisieren, ohne den Betrieb zu stoppen

Das Patientenverwaltungssystem eines Krankenhausnetzwerks lief schon, bevor es Smartphones gab. Fünfzehn Jahre voller Patches, drei Entwicklergenerationen, die nie miteinander gesprochen hatten, und eine PHP-Version, die so alt war, dass die meiste Originaldokumentation nicht mehr online zu finden war. Das System übernahm Terminplanung, Abrechnung und Teile der klinischen Dokumentation für mehrere Hundert Mitarbeitende an mehreren Standorten, und es durfte nicht einmal ein Wochenende ausfallen, geschweige denn einen Monat. So sieht die Modernisierung von Medizinsoftware tatsächlich aus, wenn der „Patient" nicht nur ein Punkt in einer Folienpräsentation ist, sondern eine reale Einrichtung, die während der Arbeiten weiter Patienten versorgen muss.

Die Details unten sind auf Wunsch des Kunden anonymisiert, aber der Ablauf, die Fehler, die wir fast gemacht hätten, und der Zeitplan sind zutreffend. Wenn Sie vor einem ähnlich alten System im Gesundheits- oder Life-Sciences-Bereich stehen, wird Ihnen der Ablauf dieses Projekts wahrscheinlich bekannt vorkommen.

Warum dieses System nach 15 Jahren noch lief

Niemand nimmt sich absichtlich vor, Software dieses Alters im Produktivbetrieb zu halten. Es passiert, weil jeder Versuch, es zu ersetzen, auf Eis gelegt wurde. Der Anbieter, der das ursprüngliche System gebaut hatte, war zweimal übernommen worden und unterstützte die verwendete Version nicht mehr. Zwei frühere Modernisierungsversuche waren gescheitert, einer nach einem Jahr Planung, als der Umfang das Budget sprengte, ein anderer, nachdem ein Dienstleister eine unvollständige Neuentwicklung lieferte, die die Abrechnungs-Sonderfälle nicht abdeckte, die sich im alten System über ein Jahrzehnt still angesammelt hatten.

Als wir ins Spiel kamen, war die Haltung der Mitarbeitenden eher resigniert als hoffnungsvoll. Das System war langsam, die Oberfläche stammte aus einer Zeit anderer Bildschirmauflösungen, und jeder hatte für mindestens einen Fehler einen Workaround. Aber es funktionierte, in dem Sinne, dass Abrechnungen eingereicht und Patienten terminiert wurden, und im Gesundheitswesen schlägt „es funktioniert" meist „es ist elegant". Das eigentliche Risiko war nicht, dass die Software alt war. Es war, dass die wenigen Menschen, die sie verstanden, kurz vor der Rente standen, und das Wissen darüber, warum bestimmte Module sich so verhielten, wie sie sich verhielten, existierte nur in ihren Köpfen.

Modernisierung von Medizinsoftware beginnt mit dem Lesen des Systems, nicht mit dem Neuschreiben

Wir haben nicht mit Code angefangen. Wir haben angefangen, das System zu lesen und zuzusehen, wie die Menschen es jeden Tag nutzten.

Die erste Bewertung dauerte etwa fünf Wochen und ergab eine Übersicht des Systems, die es zuvor nirgendwo gab, nicht einmal in der Dokumentation des ursprünglichen Anbieters. Wir verfolgten jedes Modul, das Patientendaten, Abrechnungscodes oder Terminlogik berührte, und markierten, welche sicher anzufassen waren und welche versteckte Abhängigkeiten an anderer Stelle in der Codebase hatten. Eine scheinbar isolierte Änderung an der Terminplanung speiste, wie sich herausstellte, einen nächtlichen Batch-Job, der Compliance-Berichte für eine Aufsichtsbehörde erzeugte. Niemand im aktuellen Team hatte diese Integration geschrieben, und niemand hätte gewusst, dass sie getestet werden musste, ohne den Datenfluss direkt nachzuverfolgen.

Wir haben außerdem eine Woche mit dem Abrechnungsteam verbracht und beobachtet, wie sie die Software tatsächlich nutzten, statt wie das Handbuch vorsah, dass sie sie nutzen sollten. Drei ihrer täglichen Workarounds erwiesen sich als Ausgleich für Bugs, die seit einer frühen Version des Systems existierten, Bugs, die nie gemeldet worden waren, weil die Mitarbeitenden, die sie entdeckt hatten, längst das Unternehmen verlassen hatten und der Workaround einfach Teil der Einarbeitung für neue Kolleginnen und Kollegen geworden war.

Diese Phase war wichtiger als jede Zeile Code, die wir später schrieben. Ein System umzubauen oder zu refaktorieren, das man nicht vollständig versteht, ist genau der Weg, auf dem Modernisierungsprojekte zu jahrelangen Überschreitungen werden. Die ersten Ergebnisse, die wir dem Kunden übergaben, waren kein technisches Architekturdokument. Es war eine kurze Liste dessen, was das System tatsächlich tat, wer von welchem Teil abhing und wo das reale Risiko lag, falls etwas kaputtginge.

Was sich in den ersten Monaten änderte

Sobald die Übersicht existierte, folgte die Arbeit einem einfachen Prinzip: Nichts, was die aktive Patientenversorgung berührt, wird komplett ersetzt. Alles wird schrittweise herausgelöst, wobei altes und neues System parallel laufen, bis sich der neue Weg unter echter Last bewährt hat.

Wir begannen mit den Teilen, bei denen im Fehlerfall am wenigsten Schaden entstehen konnte: interne Berichte, dann die Terminplanungsoberfläche, dann die Abrechnung. Jeder Teil wurde auf einem aktuellen, unterstützten Stack neu aufgebaut und lief mehrere Wochen parallel zum alten Modul, bevor der alte Code abgeschaltet wurde. Das ist langsamer als eine komplette Neuentwicklung, und es ist auch der einzige Ansatz, der ein Krankenhaus nicht dazu zwingt, seinen Betrieb auf ein Umschalt-Wochenende zu verwetten.

Im vierten Monat war die Terminplanungsoberfläche vollständig ersetzt, die Mitarbeitenden wurden schneller eingearbeitet, weil die neue Oberfläche Mustern folgte, die sie bereits aus anderer Software kannten, und der nächtliche Compliance-Batch-Job, den wir im ersten Monat gefunden hatten, war mit ordentlichem Logging neu geschrieben worden, sodass ein Ausfall jetzt sofort sichtbar wäre, statt drei Wochen später als fehlende Meldung bei der Aufsichtsbehörde aufzufallen. Die Abrechnungsmigration dauerte länger, eher sieben Monate, genau wegen der Sonderfälle, die die Neuentwicklung des vorherigen Dienstleisters übersehen hatte. Wir ließen das alte Abrechnungsmodul nach dem Livegang des neuen noch zwei weitere Monate im reinen Lesemodus laufen, nur damit das Finanzteam die Zahlen gegen eine vertrauenswürdige Quelle abgleichen konnte, bevor vollständig umgestellt wurde.

Zu keinem Zeitpunkt hörte das Krankenhaus auf, Patienten zu sehen, abzurechnen oder Terminkapazität zu verlieren, wegen der Migration selbst. Das war von Tag eins der eigentliche Erfolgsmaßstab, nicht eine bestimmte ausgetauschte Technologie.

Was ein Projekt dieser Art von der Kundenseite üblicherweise verlangt

Die eigenen Mitarbeitenden des Kunden haben dieses Projekt genauso zum Erfolg gemacht wie wir. Eine Modernisierung dieser Art steht und fällt mit dem Zugang zu institutionellem Wissen, und die Menschen, die das alte System betrieben haben, sind die Einzigen, die dieses Wissen besitzen. Wir verließen uns stark auf zwei langjährige Mitarbeitende, die uns „Warum macht es das so" beantworten konnten, Fragen, die wir sonst mühsam aus dem Code selbst hätten rekonstruieren müssen, und das kostete echte Zeit aus ihrem regulären Arbeitspensum. Jede Organisation, die ein ähnliches Projekt erwägt, sollte diesen Zeitaufwand von vornherein einplanen, statt anzunehmen, dass das technische Team alles eigenständig herausfinden kann.

Die andere Anforderung ist Geduld mit einem Zeitplan, der im Vergleich zu dem, was eine Verkaufspräsentation verspricht, konservativ wirkt. Eine komplette Neuentwicklung wird oft als schneller verkauft, weil sie den Schritt überspringt, die Eigenheiten des alten Systems nachzuvollziehen. In der Praxis verschwinden diese Eigenheiten nicht. Sie tauchen nach dem Launch wieder auf, meist im Produktivbetrieb, meist im ungünstigsten Moment. Der schrittweise Ansatz kostet mehr Kalenderzeit im Voraus und deutlich weniger Risiko und Kosten später.

Wo das über das Gesundheitswesen hinaus gilt

Alte Patientenverwaltungssysteme haben viel gemeinsam mit anderer regulierter, geschäftskritischer Legacy-Software: Versicherungsabrechnungsplattformen, Fertigungssteuerungssysteme, alles, was Compliance-Pflichten unterliegt, die älter sind als das aktuelle Entwicklungsteam. Wenn Ihre Organisation speziell den deutschen Gesundheitsmarkt bedient, kommt mit der regulatorischen Ebene um DiGA und gematik eine weitere Dimension hinzu, die es verdient, getrennt von der technischen Migration geplant zu werden, etwas, das wir ausführlicher in unserem Leitfaden zur Healthtech-Softwareentwicklung für den deutschen Markt beschrieben haben.

Das Muster, das in diesem Projekt am wichtigsten war, und das wir jedem in einer ähnlichen Lage empfehlen würden, ist, dem Drang zu widerstehen, alles auf einmal neu zu bauen. Erst das System kartieren. Die Menschen finden, die sich erinnern, warum es so gebaut wurde, wie es gebaut wurde. Die risikoärmsten Teile zuerst ersetzen und den neuen Weg beweisen, bevor der alte abgeschaltet wird. Das ist eine weniger aufregende Verkaufsgeschichte als „wir bauen Ihre gesamte Plattform in sechs Monaten neu", und es ist auch die Variante, die nicht riskiert, dass ein Krankenhaus an einem Dienstag keine Patienten sehen kann.

Wenn Sie für ein System dieses Alters und dieser Kritikalität verantwortlich sind, sprechen wir gerne darüber, wie eine solche Bewertung für Ihre konkrete Situation aussehen würde. Melden Sie sich unter hello@wolf-tech.io, oder erfahren Sie mehr darüber, wie wir an die Legacy-Code-Optimierung herangehen.