Das im Jahr 2018 entwickelte Vorhersagemodell für die Aufenthaltsdauer im Spital, brachte uns auf die Idee noch weitere Prognosemodelle zu berechnen. Die konkrete Umsetzung begann Ende 2019. Zentrale Fragestellung war, ob sich gewisse ungewollte, während des Spitalaufenthaltes auftretende Komplikationen vorhersagen lassen. Wir versuchten herauszufinden welche Komplikationen im Zuge einer Behandlung im Krankenhaus auftreten können und welche (präventiven) Massnahmen es gibt um solche zu verhindern oder zu behandeln. Ereignisse wie Lungenembolie, akutes Nierenversagen, Reoperation, Delir und Sturz waren relativ schnell gefunden. Es begannen ausführliche Recherchen; mögliche Risikofaktoren, Symptome und Behandlungen wurden ergänzt und detailliert geschildert. Zu jedem Szenario wurde ein genauer Beschrieb erstellt, wobei die Identifizierung via ICD Codes eine zentrale Rolle spielte. Da die Prognosen schlussendlich zur Anwendung kommen sollten, war es wichtig Szenarien zu wählen, bei welchen es von Nutzen ist, die Gefahr möglichst früh zu erkennen. Das heisst, Szenarien bei denen man eher wenig bis gar nichts vorbeugen oder behandeln kann, wurden als weniger interessant eingestuft.
In der Entwicklung einigte man sich darauf, zwei Szenarien auszuwählen und für diese möglichst rasch ein erstes Vorhersagemodell zu erstellen. Dieses sollte anschliessend ausgearbeitet, optimiert und mit weiteren Szenarien ergänzt werden können. Als Basis verwendeten wir Modelle, welche in ähnlicher Form auch in unserer Software Casematch zum Einsatz kommt. Ohne zu detailliert auf die technischen Aspekte einzugehen, wollen wir im Folgenden eine Übersicht über die Entwicklung unserer Modelle geben.
Die stationären Patientenfälle bilden unsere Datengrundlage, mit welcher wir das Modell füttern und trainieren. Darin enthalten sind demographische Daten wie beispielsweise Alter, Geschlecht, Aufnahme- und Entlassdatum sowie alle behandlungsspezifischen Informationen wie Diagnosen, Prozeduren, Aufenthaltsdauer und Beatmungsstunden. Bevor wir diese Fälle ins Modell einspeisen können, braucht es einiges an Vorarbeit, das sogenannte Data Preprocessing. Ein wichtiger Schritt dabei ist das Data Labeling. In unserem Fall bezeichnet dies das Markieren der Fälle bei denen ein entsprechendes Szenario aufgetreten ist. Betrachten wir beispielsweise das Szenario Dekubitus, so markieren wir alle Fälle mit einem ICD Code aus dem Bereich L89 (Dekubitalgeschwür und Druckzone).
Während bei manchen Szenarien die Identifikation des Szenarios relativ simpel ist, kann es in einigen Fällen auch etwas komplizierter werden. Eine Sepsis darf beispielsweise nur kodiert werden, wenn zusätzlich eine Organkomplikation vorliegt. Oder die Diagnose Sturz, welche als solche im ICD Katalog nicht direkt existiert. haben wird über den Code X59.9 (Sonstiger und nicht näher bezeichneter Unfall) und weitere Kriterien, wie Anzahl Nebendiagnosen oder Alter, identifiziert. Sobald das Preprocessing abgeschlossen war, konnten wir das Modell mit den Daten füttern und trainieren. Dieses kann durch komplexe, mathematische Operationen lernen, eine verlässliche Prognose zu erstellen. Die Kunst der Entwickler besteht darin, die Modellstruktur geschickt zu wählen, optimieren oder gegebenenfalls abändern, bis das Modell eine zufriedenstellende Genauigkeit erlangt.
Da es sich bei unseren Daten um abgeschlossene Fälle handelt, die Prognose der Szenarien jedoch nicht nur retrospektiv sondern bei Krankenhauseintritt oder fallbegleitend genutzt werden soll, mussten wir einige Tricks anwenden. Zusätzlich zum abgeschlossenen Fall wollten wir eine Vorkodierung (alles was vor, bzw. bei Eintritt bekannt ist) und eine fallbegleitende Kodierung simulieren. Um das zu erreichen mussten wir die Prozeduren, Diagnosen, Beatmungsstunden und Aufenthaltsdauer entsprechend löschen oder abändern. Durch die zufällige Generierung eines Prognosezeitpunkts zwischen Aufnahme- und Entlassdatum augmentierten wir die Aufenthaltsdauer und Beatmungsstunden. Die Prozeduren waren ebenfalls einfach zu augmentieren, da das Datum des jeweiligen Eingriffes in den Patientcases angegeben ist. Für die Diagnosen ist dies nicht der Fall. Um dieses Problem zu lösen, ist es wichtig Codes zu erkennen, welche während der Behandlung im Krankenhaus verursacht wurden. Sobald wir diese Codes herausfiltern konnten, war es auch möglich sie zu augmentieren. Nebst fachkundiger Hilfe unseres externen Beraters Prof. Dr. med. Hans Hoppeler waren uns dabei die SHAP Values von grosser Hilfe. Diese geben an, welche Codes in welchem Masse an der Vorhersage beteiligt sind. Wir trainierten unser Modell in einem ersten Schritt also ohne die Diagnosen zu augmentieren und erstellten eine Liste dieser Werte. Damit konnten wir Codes erkennen, die grossen Einfluss auf die Prognose hatten. Durch weitere Recherchen und gemeinsame Diskussionen entschieden wir anschliessend, welche der Codes augmentiert werden mussten und welche nicht.
Nachdem wir nun also einen funktionierenden Prototypen hatten, ging es darum dessen Genauigkeit zu messen und zu verbessern. Dabei mussten wir die Ungleichverteilung unserer Daten berücksichtigen. Durch die Erstellung des Groundtruths werden die Daten in zwei Klassen aufgeteilt; entweder der Patientcase enthält die Komplikation oder nicht. Ist diese Aufteilung unausgeglichen, spricht man von einer Data Imbalance. Einer solchen Rechnung zu tragen ist insofern wichtig, als dass sie unsere Sicht auf die Genauigkeit des Modells verzerren kann. Stellen wir uns vor, wir haben einen Datensatz von 10’000 Patientcases von denen nur 100 die Komplikation enthalten, d.h. als positiv gelabelt sind, die wir vorhersagen möchten. Würden wir ein Modell definieren, welches immer ein negatives Ergebnis, also keine Komplikation vorhersagt, so würde dieses Modell in 9900 Fällen das richtige Ergebnis vorhersagen. Dies entspräche einer Genauigkeit von 99%. Das Modell wäre jedoch komplett nutzlos, da es nie in der Lage sein würde eine tatsächliche Komplikation vorherzusagen. In imbalanced Datasets müssen wir deshalb unseren Begriff der Genauigkeit anders definieren als durch das Verhältnis von richtigen zu allen beobachteten Ereignissen. Wir haben uns deshalb bei der Wahl einer Metrik auf den sogenannten Precision-Recall Score geeinigt. Dieser Score konzentriert sich vorwiegend auf die Genauigkeit der Vorhersagen der positiv gelabelten Daten, statt auf den gesamten Datensatz.
Eine Precision-Recall Kurve wird folgendermassen erstellt: Für unterschiedliche Schwellenwerte zwischen 0 und 1 berechnet man die Precision (das Verhältnis von richtig positiven Vorhersagen zu gesamt positiven Vorhersagen) und den Recall (das Verhältnis von richtig positiven Vorhersagen zu tatsächlich positiven Beobachtungen). Diese Schwellenwerte bezeichnen die Grenzen, ab welchen das Modell eine positive Vorhersage macht. Wählen wir beispielsweise den Wert 0., so führen alle Modellergebnisse die höher ausfallen zu einer positiven Vorhersage. Anschliessend können diese Punkte durch eine Kurve verbunden werden. Die drei Grafiken zeigen die Precision-Recall-Kurven für die Vorkodierung (blau), die fallbegleitende Kodierung (orange) und die abgeschlossene Kodierung (grün). Die schwarz gestrichelte Linie stellt ein Modell dar, welches rein zufällig entscheidet ob das Szenario eintrifft oder nicht. Die obere, rechte Ecke bezeichnet den Punkt, an dem ein Precision- sowie Recall-Wert von eins erreicht wird. In anderen Worten bedeutet dies, dass das Modell weder falsch negative, noch falsch positive Vorhersagen macht. Deshalb gilt, je mehr sich die Kurve gegen die obere, rechte Ecke beugt, desto besser ist das Modell.
Betrachten wir beispielsweise den Punkt P(0.5, 0.6) auf der blauen Kurve des Sturz-Szenarios (“fall”). Wählen wir für unser Modell den Schwellenwert dieses Punktes, so hätten wir eine Precision von 60%. Wir müssten somit mit 40% Fehlalarmen bei Identifikation von 50% der Stürze (Recall) rechnen. Nun kann man nun den Schwellenwert so wählen wie dies in der praktischen Anwendung am sinnvollsten ist.
Die Kurven für das Sturz-Szenario sehen sehr gut aus. Man erkennt eine klare Beugung gegen die obere rechte Ecke. Auch die Kurven für das Sepsis-Szenario (“sepsirs”) scheinen vielversprechend. Zwar sind sie etwas weniger stark gebeugt, jedoch immer noch deutlich besser als das Zufallsmodell. Wenig überzeugend ist dagegen unser Modell für das Dekubitus (“dec”) Szenario.
Nachdem nun also das Data Preprocessing, die Modellstruktur und die Messmetrik definiert waren, konnten wir weitere Szenarien hinzufügen. Insgesamt hatten wir bald über Zehn Szenarien ausgewählt und mit einem Entwicklungsdatensatz trainiert. Nach der Auswertung entschieden wir uns im Endeffekt für die fünf Szenarien Sturz, akutes Nierenversagen, Harnwegsinfektion, Embolie und Sepsis. Die Szenarien Reoperation, Delirium und Tod wurden vorläufig zurückgestellt, Pneumonie, Pneumothorax und Dekubitus aufgrund unbefriedigender Resultate gar ganz verworfen.
Mehr Informationen zur Verweildauerprognose finden Sie auch in unserem Blogbeitrag zum Thema.