2016 - 2019 · Softwareentwickler → Teamleiter → Engineering Manager
Epic Systems
Leitung zweier Entwicklungsteams bei Epic: Patient History während einer vollständigen Neuentwicklung sowie Provider/Nurse Scheduling, der zentrale klinische Einstiegspunkt in Epics Ambulatory-Produkt.
Ausgangslage
Epic-Software bildet einen großen Teil der Versorgung in US-Krankenhäusern ab. Ich begann 2016 als Entwickler im History-Team, übernahm fünfzehn Monate später die Teamleitung und verantwortete ab 2019 zusätzlich Provider/Nurse Scheduling, den zentralen klinischen Einstiegspunkt für Ambulatory-Anwender. Änderungen an dieser Stelle erreichen mit jeder Auslieferung Tausende Behandelnde. Eine Entscheidung im Datenmodell lässt sich nicht unbemerkt zurückrollen, wenn darin bereits Jahre an Patientendaten liegen.
Die eigentliche Herausforderung
Neuentwicklung eines laufenden klinischen Systems
Ich führte das Patient-History-Team durch eine vollständige Neuentwicklung. Die Schwierigkeit lag in diesem Umfeld nicht in der neuen Implementierung. Jeder Kunde verfügte über Jahre gewachsener Patientendaten im alten System, Tausende Behandelnde waren auf vertrautes Verhalten angewiesen, und es gab kein Wartungsfenster, in dem ein Krankenhaus die Versorgung einstellte. Die neue Version wurde mit kleineren Fehlern, aber ohne gravierende Brüche ausgeliefert. Für ein System an dieser Stelle ist das der einzige Maßstab, der zählt.
Gemeinsames Instanzmodell für kleinere Krankenhäuser
Epic war für kleine Einrichtungen wirtschaftlich kaum erreichbar. Gemeinsam mit dem Leiter von R&D sowie Kolleginnen und Kollegen aus Vertrieb, Recht, Technical Services und Implementierung trug ich dazu bei, ein Modell zu entwickeln, bei dem mehrere kleinere Kunden eine Instanz nutzen. Ein bestehendes Modell erlaubte es einem großen Krankenhaus, seine Instanz kleineren Einrichtungen in der Region bereitzustellen. Die gesamte IT- und Governance-Verantwortung lag dabei jedoch beim Host. Unser Ansatz behielt denselben grundlegenden Codepfad bei, verteilte die operative Verantwortung aber auf die Mitglieder. Damit wurde das Modell auch für Kunden tragfähig, die sich keinem bestehenden Host anschließen konnten.
Weitere Arbeit bei Epic
Identitätsdaten wirken im gesamten System
Epic überarbeitete im Rahmen einer umfassenderen Identitätsinitiative den Umgang mit bevorzugten Namen. Die Änderung führte zu Eskalationen. Der Name eines Patienten ist nicht nur ein Feld. Er erscheint in der Terminplanung, in Aktenköpfen, auf gedruckten Dokumenten, in der Patientenkommunikation und in Dutzenden nachgelagerter Integrationen. Gesundheitssysteme hatten zudem unterschiedliche klinische und rechtliche Anforderungen an die Darstellung. Ein einziger globaler Standard musste daher für einen Teil der Kunden falsch sein.
Ich koordinierte die Reaktion von R&D. Die Lösung war ein tief im System ansetzender Override, mit dem eine Organisation den amtlichen Namen im gesamten System sichtbar halten konnte, statt vor dem nächsten Upgrade in Eile mehr als 10.000 Konfigurationen prüfen zu müssen. Mehr als 30 % des Kundenstamms nutzten ihn, und das Thema löste keine weiteren Eskalationen mehr aus.
Teamleitung
Zwei Teams mit bis zu 7 Entwicklern. Den QA-Rückstand um 80 % reduziert. Gemeinsam mit der Produktleitung quartalsweise Personal- und Kapazitätsreviews für alle Ambulatory-Arbeitsgruppen nach einer festen Struktur durchgeführt: Qualität, Projektfortschritt sowie Arbeitszeit und Zufriedenheit im Team. Scrum im History-Team eingeführt. Entwicklungskandidaten für R&D interviewt.