In klinischen Studien betrachten wir Patienten häufig als Datensätze: Alter, Tumorcharakteristika, Laborwerte, Adverse Events oder Queries. Diese Informationen sind wichtig, beschreiben jedoch nur einen Teil der Realität.
Ein Patient durchläuft während einer Studie einen Prozess.
Die Patient Journey
Vereinfacht betrachtet besteht die Journey aus wenigen Zuständen:
SCREENING → THERAPY → FOLLOW_UP → STUDY_END
Für jeden Patienten stellen sich dabei mehrere Fragen:
- Wie lange verbleibt er in einem Zustand?
- Wohin wechselt er als Nächstes?
- Ist seine Verweildauer auffällig?
- Unterscheidet er sich vom Zentrum oder von anderen Patienten?
Genau hier beginnt Process Analytics.
Vom Event Log zur Journey
Grundlage ist ein Clinical Data Warehouse mit einer standardisierten Ereignistabelle:
- Patient
- Event
- Event Date
Beispiele für Ereignisse:
- Informed Consent
- Randomization
- Therapy Start
- Last Drug Administration
- Study End
Aus diesen Ereignissen lässt sich die individuelle Patient Journey rekonstruieren.
Zustandsübergänge statt Formulare
Anstatt einzelne CRFs oder Formulare isoliert zu analysieren, betrachten wir den Übergang zwischen Prozesszuständen:
- SCREENING → THERAPY
- SCREENING → STUDY_END
- SCREENING → PENDING
- THERAPY → FOLLOW_UP
- THERAPY → STUDY_END
- THERAPY → PENDING
- FOLLOW_UP → STUDY_END
- FOLLOW_UP → PENDING
Dabei bedeutet:
- SCREENING = Informed Consent bis Therapy Start
- THERAPY = Therapy Start bis Last Drug Administration
- FOLLOW_UP = Last Drug Administration bis Study End
- STUDY_END = dokumentiertes Studienende
- PENDING = Patient befindet sich aktuell noch in diesem Zustand
Weniger Zustände, mehr Aussagekraft
Während der Modellierung stellte sich eine wichtige Frage:
Sollten Ereignisse wie Screening Failure, Death, Withdrawal oder Lost To Follow Up als eigene Prozesszustände modelliert werden?
Der erste Impuls lautet häufig: Ja.
In der Praxis führt dies jedoch schnell zu einer Vielzahl von Sonderfällen und seltenen Zustandsübergängen. Das Prozessmodell wird komplexer, ohne dass zusätzliche Informationen gewonnen werden.
Deshalb wurde ein anderer Ansatz gewählt:
- SCREENING → STUDY_END (Reason = Screening Failure)
- THERAPY → STUDY_END (Reason = Death)
- FOLLOW_UP → STUDY_END (Reason = Withdrawal)
- FOLLOW_UP → STUDY_END (Reason = Lost To Follow Up)
Study End bleibt der eigentliche Endzustand. Die klinische Bedeutung wird über zusätzliche Attribute beschrieben.
Dadurch bleibt das Prozessmodell kompakt und verständlich, während gleichzeitig alle relevanten Informationen erhalten bleiben.
Diese Trennung zwischen Prozesszustand und klinischem Attribut erwies sich als einer der wichtigsten Schritte bei der Entwicklung des Modells.
Verweildauer als Prozessindikator
Für jeden Zustandsübergang berechnen wir die Verweildauer.
- Patient: 4711
- Transition: SCREENING → THERAPY
- Verweildauer: 8 Tage
Zusätzlich berechnen wir den Durchschnitt des jeweiligen Zentrums.
- Patient: 151 Tage in THERAPY
- Zentrum: 75 Tage Durchschnitt
Daraus ergibt sich ein Delay Factor:
- Delay Factor = 151 / 75 = 2.01
Der Patient benötigt also etwa doppelt so lange wie vergleichbare Patienten desselben Zentrums.
Die richtige Referenzgruppe
Eine wichtige Erkenntnis entstand erst während der Modellierung: Für aktive Patienten darf der Vergleich nicht gegen andere offene Patienten erfolgen.
Ein Patient mit:
- SCREENING → PENDING
sollte nicht mit anderen Patienten verglichen werden, die ebenfalls noch im Screening hängen.
Für das Monitoring ist die bessere Frage:
Wie lange dauert dieser Zustand normalerweise, wenn er regulär abgeschlossen wurde?
Daher wird der Referenzdurchschnitt nur aus abgeschlossenen Haupt-Transitionen berechnet:
- SCREENING → THERAPY
- THERAPY → FOLLOW_UP
- FOLLOW_UP → STUDY_END
Damit wird der Delay Factor fachlich deutlich aussagekräftiger:
- Aktueller Patient im Zustand
- geteilt durch durchschnittliche Dauer abgeschlossener Haupt-Transitionen
Beispiel:
- SCREENING → THERAPY: Durchschnitt 7 Tage
- Patient aktuell: SCREENING → PENDING
- Aktuelle Verweildauer: 21 Tage
- Delay Factor = 21 / 7 = 3.0
Der Monitor sieht dadurch sofort: Dieser Patient befindet sich dreimal länger im Screening als Patienten, die das Screening normalerweise verlassen.
Nutzen für das Studienmonitoring
Besonders interessant ist dieser Ansatz für Monitore und Studienmanager.
Klassische Reports zeigen häufig lediglich den aktuellen Status eines Patienten:
- Patient: 4711
- Status: SCREENING
Die entscheidende Frage bleibt dabei offen:
Ist dieser Zustand normal oder auffällig?
Durch die Kombination aus Patient Journey, Verweildauer und Referenzdurchschnitt entsteht zusätzlicher Kontext:
- Patient: 4711
- Status: SCREENING
- Verweildauer: 21 Tage
- Referenzdurchschnitt: 7 Tage
- Delay Factor: 3.0
- Bewertung: WATCH
Der Monitor erkennt sofort, dass dieser Patient deutlich länger im Screening verbleibt als vergleichbare Patienten, die den Zustand bereits regulär abgeschlossen haben.
Statt hunderte Patienten manuell zu prüfen, können auffällige Fälle gezielt identifiziert werden.
- Patienten mit ungewöhnlich langen Screening-Phasen
- Patienten mit verlängerten Therapiephasen
- Zentren mit systematisch längeren Prozesszeiten
- seltene oder unerwartete Zustandsübergänge
Damit entwickelt sich das Monitoring von einer rein dokumentierenden Tätigkeit hin zu einer datengetriebenen Prozessüberwachung.
Der Fokus verschiebt sich von der Frage:
Wo befindet sich der Patient?
zu:
Befindet sich der Patient noch im erwarteten Prozessverlauf?
Aktive Patienten statt historische Auffälligkeiten
Eine weitere wichtige Erkenntnis betrifft die Bewertung von Verzögerungen.
Ein Patient kann beispielsweise deutlich länger als der Durchschnitt im Screening verbracht haben und dennoch inzwischen erfolgreich randomisiert worden sein.
- Transition: SCREENING → THERAPY
- Screeningdauer: 21 Tage
- Referenzdurchschnitt: 7 Tage
Dies ist zwar eine interessante historische Beobachtung, erfordert jedoch kein aktives Eingreifen mehr.
Deshalb werden Monitoring-Flags ausschließlich für aktive Patienten vergeben:
- SCREENING → PENDING
- THERAPY → PENDING
- FOLLOW_UP → PENDING
Nur wenn sich ein Patient aktuell noch in einem Zustand befindet und gleichzeitig deutlich länger als der Referenzdurchschnitt verweilt, wird ein Monitoring-Hinweis erzeugt.
- Aktiver Patient
- Delay Factor erhöht
- Bewertung: WATCH
Dadurch konzentriert sich das Monitoring auf tatsächlich relevante Fälle und vermeidet unnötige Warnungen für bereits abgeschlossene Prozessschritte.
Übergangswahrscheinlichkeiten
Zusätzlich lässt sich aus den bisherigen Übergängen eine Übergangswahrscheinlichkeit berechnen.
Diese Wahrscheinlichkeit beschreibt, wie häufig Patienten eines Zentrums von einem Zustand in einen Folgezustand gewechselt sind.
- pij = Anzahl Patienten mit Übergang i → j / Anzahl Patienten im Zustand i
Beispiel:
- SCREENING → THERAPY = 90 %
- SCREENING → STUDY_END = 7 %
- SCREENING → PENDING = 3 %
Wichtig ist dabei: Eine niedrige Übergangswahrscheinlichkeit ist nicht automatisch schlecht. Sie bedeutet zunächst nur, dass dieser Übergang selten auftritt.
Deshalb eignet sich pij gut zur Beschreibung des Prozessverhaltens, aber nicht als einfache Rot-Gelb-Grün-Ampel für das Monitoring.
Für die Ampel ist der Monitoring-Status besser geeignet:
- Aktiver Patient
- erhöhter Delay Factor
- Monitoring Status: WATCH
Von KPIs zu Process Analytics
Klassische Berichte beantworten Fragen wie:
- Wie viele Patienten wurden eingeschlossen?
- Wie viele SAEs wurden dokumentiert?
- Wie viele Queries sind offen?
- Wie viele Zentren sind aktiv?
Process Analytics beantwortet andere Fragen:
- Wo befinden sich Patienten aktuell?
- Welche Übergänge treten am häufigsten auf?
- Welche Prozessschritte dauern ungewöhnlich lange?
- Welche Zentren weichen vom erwarteten Verlauf ab?
- Welche Patienten sollten vom Monitoring geprüft werden?
Der nächste Schritt: Journey Enrichment
Die aktuelle Journey beschreibt den Prozess.
Im nächsten Schritt können zusätzliche Informationen ergänzt werden:
- Anzahl der AEs innerhalb eines Zustands
- Anzahl der SAEs innerhalb eines Zustands
- Anzahl gestellter Queries innerhalb eines Zustands
- Anzahl beantworteter Queries innerhalb eines Zustands
- Anzahl geschlossener Queries innerhalb eines Zustands
- Protocol Deviations
- Tumorcharakteristika
- Demographie
Damit entsteht nicht nur eine Beschreibung des Prozesses, sondern ein kontextreicher Blick auf die individuelle Patient Journey.
Der Weg zum Clinical Process Twin
Die aktuelle Lösung ist deskriptiv:
Was ist passiert?
Sie ist zugleich diagnostisch:
Wo weicht der aktuelle Prozess vom erwarteten Verlauf ab?
Später können daraus prädiktive Analysen entstehen:
Was ist auf Basis bisheriger Übergänge der wahrscheinlichste nächste Prozessschritt?
Beispiel:
- Patient aktuell: State = THERAPY
- Days in State = 120
- THERAPY → FOLLOW_UP = 82 %
- THERAPY → STUDY_END = 12 %
- THERAPY → PENDING = 6 %
Daraus lassen sich zustands- und zentrumsbasierte Erwartungswerte ableiten. Diese Schätzung ist keine individuelle medizinische Prognose, sondern eine transparente Prozesswahrscheinlichkeit auf Basis bisheriger Übergänge.
Aus einem klassischen Clinical Data Warehouse entsteht damit schrittweise ein Clinical Process Twin – ein digitales Abbild des tatsächlichen Patientenverlaufs innerhalb einer klinischen Studie.
Fazit
Der spannendste Teil dieses Projekts war nicht die SQL-Implementierung, sondern die Modellierung.
Mehrere Erkenntnisse waren entscheidend:
- Der Patient wird als Prozess betrachtet, nicht nur als Datensatz.
- Screening Failure, Death, Withdrawal und Lost To Follow Up sind Attribute von STUDY_END.
- PENDING beschreibt aktive, noch nicht abgeschlossene Zustände.
- WATCH wird nur für aktive Patienten vergeben, nicht für abgeschlossene Übergänge.
- Der Delay Factor wird gegen abgeschlossene Haupt-Transitionen berechnet.
- pij beschreibt Prozesshäufigkeit, aber keinen automatischen Handlungsbedarf.
- AEs, SAEs und Queries können später zustandsbezogen angereichert werden.
Aus vielen einzelnen Ereignissen entstand dadurch ein einfaches, verständliches Prozessmodell:
SCREENING → THERAPY → FOLLOW_UP → STUDY_END
Gerade diese Reduktion auf das Wesentliche macht Process Analytics für klinische Studien interessant.
Statt isolierter Kennzahlen rückt die Patient Journey selbst in den Mittelpunkt der Analyse. Dadurch entstehen neue Möglichkeiten für Monitoring, Studiensteuerung und perspektivisch auch für prädiktive Modelle im Sinne eines Clinical Process Twin.
Hinweis: Inhalt selbst erstellt, Schreibkorrektur durch ChatGPT.