Warum wir in der klinischen Brustkrebsforschung den gesamten Datenweg als Teil wissenschaftlicher Qualität betrachten.
In der klinischen Forschung wird Reproduzierbarkeit häufig am Ende des Datenwegs diskutiert.
Welcher statistische Test wurde verwendet? Welche Softwareversion? Welche Parameter? Wie wurde die Kohorte definiert? Ist das Analyseskript versioniert?
All das ist wichtig.
Aber die Statistik arbeitet nicht mit der klinischen Realität. Sie arbeitet mit einem Datensatz, der vorher erzeugt wurde.
Und genau dort liegt für uns ein wesentlicher Punkt:
Nicht nur die Analyse muss reproduzierbar sein. Auch die Erzeugung ihres Eingangsdatenbestandes ist Teil der wissenschaftlichen Methodik.
Diese Erkenntnis hat unseren Datenpfad in der klinischen Brustkrebsforschung wesentlich geprägt.
Klinische Daten entstehen nicht für die Statistik
Am Anfang steht die Patientin.
Im Verlauf einer klinischen Studie entstehen Informationen über Therapie, funktionellen Zustand, Patient Reported Outcomes, Laborwerte, Biomarker, unerwünschte Ereignisse und viele weitere klinische Beobachtungen.
Für die Studie werden diese Informationen strukturiert dokumentiert – beispielsweise über eCRFs, Visits, Therapieformulare oder die Safety-Dokumentation.
Medizin / Klinik Studiendokumentation
│ │
├── Patientin ├── eCRF / EDC
├── Therapie ├── Visits
├── ECOG ├── Queries
├── PRO / FACT-B ├── AE / SAE
├── Labor ├── Randomisierung
└── Biomarker └── Studienereignisse
\ /
\ /
operative StudiendatenDas Electronic Data Capture System erfüllt damit zunächst eine operative Aufgabe:
Es dokumentiert die Studie.
Die Struktur, die dafür sinnvoll ist, muss aber nicht der Struktur entsprechen, die später für wissenschaftliche Analysen benötigt wird.
Der entscheidende Teil passiert häufig vor der Statistik
In einem früheren Artikel habe ich das bewusst zugespitzt:
80 % der Arbeit passiert vor der Statistik.
Ein gutes Beispiel dafür sind klinische Ereignisse.
Ein relevantes Ereignis kann an mehreren Stellen der Studiendokumentation auftauchen. Ein Todesfall kann beispielsweise über unterschiedliche Formulare oder im Follow-up dokumentiert sein.
Bevor daraus eine Survival-Analyse entstehen kann, müssen zunächst fachliche Fragen beantwortet werden:
Welche Quelle ist maßgeblich? Welches Datum wird verwendet? Wie werden widersprüchliche Angaben behandelt? Welche Priorisierungsregeln gelten? Wann wird zensiert?
Erst danach entsteht das Ereignis, das die Statistik tatsächlich analysiert.
klinisches Ereignis
↓
Studiendokumentation
↓
mögliche Datenquellen
↓
fachliche Definitionen
↓
Datenintegration
↓
abgeleitetes Ereignis
↓
Kohorten- / Zensierungslogik
↓
statistische AnalyseDamit wird deutlich:
Die Statistik steht am Ende einer bereits langen methodischen Kette.
Datenintegration ist nicht nur technische Vorarbeit
Genau daraus entstand für uns die nächste Frage:
Wenn Datenbereinigung, Eventdefinition, Transformation und Kohortenbildung beeinflussen, welchen Datensatz die Statistik überhaupt zu sehen bekommt – warum sollte Reproduzierbarkeit erst beim Statistikskript beginnen?
Für uns lautet die Konsequenz:
Die wissenschaftliche Methodik beginnt nicht erst mit der Wahl des statistischen Verfahrens. Sie beginnt mit der kontrollierten Erzeugung des Datenbestandes, auf den dieses Verfahren angewendet wird.
Damit bekommt Datenintegration eine andere Bedeutung.
Sie ist nicht nur technische Vorarbeit.
Sie wird zu einem Bestandteil der wissenschaftlichen Qualitätskette:
Studiendokumentation
↓
kontrollierte Datenintegration
↓
definierter Datenbestand
↓
nachvollziehbare Kohortenbildung
↓
statistische Methodik
↓
wissenschaftliche AussageEine statistische Methode kann vollkommen korrekt implementiert sein.
Wenn aber nicht mehr nachvollziehbar ist, wie ihr Eingangsdatenbestand entstanden ist, bleibt ein wesentlicher Teil der Verarbeitung außerhalb der Reproduzierbarkeit.
Warum wir ein Clinical Data Warehouse einsetzen
Aus diesem Grund trennen wir operative Studiendokumentation und wissenschaftliche Informationsgewinnung bewusst voneinander.
Dazwischen steht ein Clinical Data Warehouse.
EDC / Studiendokumentation
↓
operative Studiendaten
↓
kontrollierte Integration
↓
Clinical Data Warehouse
↓
┌─────────┼─────────┐
↓ ↓ ↓
Monitoring Kohorten Statistik /
Data ScienceDas EDC dokumentiert.
Das Clinical Data Warehouse integriert.
Informationen aus unterschiedlichen Formularen, Domänen und Zeitpunkten können dort zu einer gemeinsamen longitudinalen Datenbasis zusammengeführt werden.
Das hat für uns einen wichtigen Vorteil:
Eine neue Forschungsfrage muss nicht automatisch eine neue Datenintegrationspipeline bedeuten.
Die kontrolliert integrierte Datenbasis kann für unterschiedliche wissenschaftliche und operative Fragestellungen verwendet werden.
Nähe zu den operativen Daten schafft analytische Freiheit – und Verantwortung
Für diese interne analytische Plattform arbeiten wir möglichst nah an den operativen Studiendaten.
Ein nativer Export aus dem EDC kann kontrolliert in die relationale Datenplattform übernommen werden.
Das Exportformat selbst ist dabei kein Qualitätsmerkmal. CSV beispielsweise ist zunächst lediglich ein Transportformat.
Entscheidend ist, was anschließend damit passiert.
EDC / secuTrial
↓
nativer Export
↓
kontrollierte Datenintegration
↓
Clinical Data WarehouseStandards der CDISC-Familie erfüllen wichtige Aufgaben bei Standardisierung und Austausch klinischer Daten.
Ein standardisiertes Austauschmodell und das interne analytische Informationsmodell eines Clinical Data Warehouse müssen jedoch nicht zwangsläufig identisch sein.
Für unsere interne Forschungsdatenplattform stehen zunächst drei Anforderungen im Vordergrund:
Nachvollziehbarkeit, kontrollierte Integration und analytische Flexibilität.
Die Nähe zu den operativen Daten erzeugt allerdings auch Verantwortung.
Denn:
CSV → Datenbankist noch keine reproduzierbare Forschungsdatenpipeline.
„Import erfolgreich“ reicht nicht
Ein Datenexport kann sich verändern.
Variablen können hinzukommen. Strukturen können sich ändern. Datentypen können abweichen. Ein Import kann technisch ohne Fehler durchlaufen und trotzdem nicht den Datenbestand erzeugt haben, den wir erwarten.
Deshalb reicht für uns die Frage
„Ist der Import durchgelaufen?“
nicht aus.
Wir wollen zusätzlich wissen:
Hat sich das Schema verändert? Wurden die erwarteten Daten übernommen? Sind Abweichungen sichtbar geworden? Welche Validierungen wurden durchgeführt? Welche Verarbeitungsversion wurde verwendet? Hat die Verarbeitung einen definierten Datenbankzustand hinterlassen?
Daraus ergibt sich ein kontrollierter Datenweg:
operativer Export
↓
Schema Governance
↓
Validation
↓
kontrollierter Load
↓
Reconciliation
↓
COMMIT / ROLLBACK
↓
Clinical Data WarehouseSchema Governance soll verhindern, dass Strukturänderungen unbemerkt übernommen werden.
Validation prüft definierte Erwartungen.
Reconciliation vergleicht Erwartungen mit dem tatsächlich importierten Datenbestand.
Transaktionen schützen den Datenbankzustand.
Damit verändert sich auch die Bedeutung von „erfolgreich“:
Ein erfolgreicher Import bedeutet nicht nur, dass keine Exception aufgetreten ist. Der resultierende Datenbestand muss den definierten Erwartungen entsprechen.
Warum eine Enterprise-Datenbank?
Auch die Entscheidung für eine zentrale relationale Enterprise-Datenbank folgt diesem Qualitätsanspruch.
Für eine einzelne explorative Analyse kann man Daten auf viele Arten verarbeiten.
Eine Forschungsdatenplattform, die über Jahre betrieben und für unterschiedliche Fragestellungen verwendet werden soll, stellt jedoch andere Anforderungen.
Wir benötigen einen persistenten und kontrollierten Datenbestand.
In unserer Architektur übernimmt SQL Server diese Rolle.
Transaktionen, Integritätsmechanismen, Berechtigungen, zentrale Administration sowie Backup- und Recovery-Mechanismen sind dabei keine nebensächlichen Komfortfunktionen.
Sie unterstützen die langfristige und kontrollierte Datenhaltung.
Enterprise-Datenbank
↓
┌─────────────┼─────────────┐
↓ ↓ ↓
Transaktionen Integrität Berechtigungen
\ │ /
└────────────┼────────────┘
↓
Backup / Recovery
↓
Clinical Data WarehouseDie Datenbank ist damit ein stabiler Anker zwischen operativer Studiendokumentation und wissenschaftlicher Auswertung.
Reproduzierbarkeit und Auditierbarkeit
Aus diesem Datenweg ergeben sich zwei eng miteinander verbundene Anforderungen.
Reproduzierbarkeit bedeutet für uns, nachvollziehen zu können, aus welchem Datenstand und mit welcher Verarbeitung ein analytischer Datenbestand entstanden ist.
Dazu gehören beispielsweise versionierter Code, versionierte SQL-Transformationen, definierte Datenstände und nachvollziehbare Kohortendefinitionen.
Auditierbarkeit stellt zusätzlich die Frage, ob nachträglich nachvollzogen werden kann, welche Verarbeitung tatsächlich stattgefunden hat und welche Kontrollen dabei durchgeführt wurden.
Dazu können Audit-Informationen, Logging, Validation, Reconciliation und der Status eines Verarbeitungslaufs beitragen.
Reproduzierbarkeit Auditierbarkeit
│ │
├── Codeversion ├── Audit-ID
├── SQL-Version ├── Logging
├── Transformation ├── Validation
├── Datenstand ├── Reconciliation
└── Kohortendefinition └── LaufstatusNatürlich bedeutet eine solche technische Architektur allein noch keine regulatorische Compliance.
SOPs, Systemvalidierung, Berechtigungskonzepte und organisatorisch kontrollierte Prozesse bleiben eigenständige Anforderungen.
Aber die Architektur kann eine wichtige Voraussetzung schaffen:
Nachvollziehbarkeit muss nicht nachträglich rekonstruiert werden, wenn sie bereits Bestandteil des Datenprozesses ist.
Eine Datenbasis für unterschiedliche Fragestellungen
Ist die Datenintegration kontrolliert erfolgt, kann dieselbe Datenbasis unterschiedliche Aufgaben erfüllen.
Clinical Data Warehouse
↓
┌─────────────┼─────────────┐
↓ ↓ ↓
Prozessanalyse Kohortenbildung Statistik /
Data Science
↓ ↓ ↓
Monitoring Forschungs- Analysen /
populationen HypothesenFür das Studienmanagement können longitudinale Studienverläufe und Prozesszustände betrachtet werden.
Für Forschungsfragen können Populationen anhand definierter klinischer und zeitlicher Kriterien gebildet werden.
Statistik und Data Science können anschließend auf diesen definierten Datenständen aufbauen.
Gerade die Kohortenbildung zeigt, warum der vorgelagerte Datenprozess wissenschaftlich relevant ist:
Clinical Data Warehouse
↓
definierter Datenstand
↓
Ein-/Ausschlusskriterien
↓
definierte Kohorte
↓
statistische AnalyseEine Kohorte ist nicht einfach eine Liste von Patientinnen.
Sie ist das Ergebnis von Definitionen, Datenständen, Transformationen sowie Ein- und Ausschlussregeln.
Deshalb sollte eine zentrale Frage beantwortbar bleiben:
Warum befinden sich genau diese Patientinnen in dieser Analyse?
Der vollständige Forschungsdatenpfad
Aus diesen Anforderungen ergibt sich für uns folgende Architektur:
KLINISCHE FORSCHUNG
│
┌─────────────┴─────────────┐
▼ ▼
Medizin / Klinik Studiendokumentation
│ │
├── Patientin ├── eCRF / secuTrial
├── Therapie ├── Visits
├── ECOG ├── Queries
├── PRO / FACT-B ├── AE / SAE
├── Labor ├── Randomisierung
└── Biomarker └── Studienereignisse
\ /
\ /
▼ ▼
operative Studiendaten
│
▼
kontrollierter Datenimport
│
Validation / Schema Governance
Reconciliation / Versionierung
Transaktionen / Audit-Information
│
▼
Enterprise-Datenbank
SQL Server
│
▼
Clinical Data Warehouse
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Prozessanalyse Kohortenbildung Statistik /
Data Science
│ │ │
▼ ▼ ▼
Monitoring Forschungs- Analysen /
populationen HypothesenReproduzierbarkeit als Qualitätsmerkmal wissenschaftlicher Arbeit
Damit schließt sich der Kreis zu der ursprünglichen Beobachtung:
Ein großer Teil der Arbeit passiert vor der Statistik.
Wenn dieser Teil bestimmt, welchen Datenbestand die Statistik später analysiert, dann darf er methodisch keine Blackbox sein.
Das bedeutet nicht, dass eine reproduzierbare Datenpipeline automatisch eine korrekte wissenschaftliche Aussage garantiert.
Studiendesign, Bias, Missing Data, Confounding, statistische Methodik und klinische Interpretation bleiben eigenständige Herausforderungen.
Aber eine kontrollierte Datenpipeline verbessert eine wesentliche Voraussetzung wissenschaftlicher Qualität:
Wir können nachvollziehen, auf welcher Datenbasis eine wissenschaftliche Aussage entstanden ist.
Und deshalb ist die zentrale Konsequenz für uns:
Wir wollen nicht nur reproduzieren können, wie eine statistische Methode auf einen Datensatz angewendet wurde. Wir wollen auch nachvollziehen können, wie dieser Datensatz entstanden ist.
Fazit
Wir haben diesen Datenpfad in der klinischen Brustkrebsforschung nicht gewählt, weil Java, SQL Server oder Data Warehousing an sich interessante Technologien sind.
Die Technologie folgt den Anforderungen.
Das EDC dokumentiert die Studie.
Die kontrollierte Datenintegration sichert den Übergang.
Die Enterprise-Datenbank stellt einen persistenten und kontrollierten Datenbestand bereit.
Das Clinical Data Warehouse integriert die unterschiedlichen Studiendomänen.
Darauf können Monitoring, Kohortenbildung, Statistik und Data Science aufbauen.
Der eigentliche Qualitätsanspruch liegt eine Ebene darüber:
Reproduzierbarkeit beginnt nicht mit dem Statistikskript. Sie beginnt mit dem Datenbestand, auf den dieses Skript angewendet wird – und mit dem nachvollziehbaren Weg, auf dem dieser Datenbestand entstanden ist.
Reproduzierbarkeit ist damit nicht nur eine Eigenschaft der Analyse. Sie ist ein Qualitätsmerkmal des gesamten wissenschaftlichen Datenpfades.