Vom klinischen Data Warehouse zum Process Twin

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:

S  → T

S  → SE

S  → PENDING



T  → FU

T  → SE

T  → PENDING



FU → SE

FU → PENDING

Dabei bedeutet:

• S = Screening (Informed Consent bis Therapy Start)
• T = Therapy (Therapy Start bis Last Drug Administration)
• FU = Follow Up (Last Drug Administration bis Study End)
• SE = Study End
• 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:

• S → SE (Reason = Screening Failure)
• T → SE (Reason = Death)
• FU → SE (Reason = Withdrawal)
• FU → SE (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


S → T


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.

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 Zentrumsbenchmark entsteht zusätzlicher Kontext:

Patient 4711


Status: Screening


Verweildauer: 151 Tage



Zentrumsdurchschnitt:

7 Tage



Delay Factor:

21,6



Bewertung:

WATCH

Der Monitor erkennt sofort, dass dieser Patient deutlich länger im Screening verbleibt als vergleichbare Patienten desselben Zentrums.

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.

S → T

Screeningdauer: 21 Tage

Zentrumsdurchschnitt: 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:

S  → PENDING 

T  → PENDING 

FU → PENDING

Nur wenn sich ein Patient aktuell noch in einem Zustand befindet und gleichzeitig deutlich länger als vergleichbare Patienten des Zentrums verweilt, wird ein Monitoring-Hinweis erzeugt.

Delay Factor > 2
→ WATCH

Dadurch konzentriert sich das Monitoring auf tatsächlich relevante Fälle und vermeidet unnötige Warnungen für bereits abgeschlossene Prozessschritte.

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?

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 SAEs innerhalb eines Zustands
• Anzahl der 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?

Später können daraus diagnostische und prädiktive Analysen entstehen:

Warum ist es passiert?

und:

Was wird wahrscheinlich als Nächstes passieren?

Patient aktuell:

State = Therapy

Days in State = 120 



Historische Übergänge:


Therapy → Follow Up = 82 %

Therapy → Study End = 12 %

Therapy → Pending = 6 %

Daraus lassen sich Wahrscheinlichkeiten für den nächsten Prozessschritt ableiten.

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.

Aus vielen einzelnen Ereignissen entstand 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.