Synthea→OMOP DWH + Feature Engineering + ML (Pre-) Diabetes Prediction (Notebook Release V13)

Dieses Deposit enthält eine reproduzierbare Projektpipeline zur Verarbeitung synthetischer Gesundheitsdaten auf Basis von Synthea in Richtung eines OMOP Common Data Model (OMOP CDM)-nahen Data-Warehouse-Workflows. Der Fokus liegt auf einer nachvollziehbaren Datenkette von Rohdaten über Qualitätsprüfungen und Mapping-/Coverage-Auswertungen bis hin zu abgeleiteten Feature-Tabellen und (optional) Machine-Learning-Auswertungen. Die Abläufe sind in einem Notebook-basierten Workflow umgesetzt und in Phasen dokumentiert (Phase 0/A/B/C), sodass einzelne Schritte isoliert überprüft und wiederholt werden können.

Inhalt und Struktur

Das Deposit wird als Release-Paket bereitgestellt (Dissemination/Access Copy) und enthält insbesondere:

• Dokumentation (u. a. README.md) mit Projektstruktur, Ausführungslogik und Reproduktionshinweisen

• Phase-Reports als Markdown-Dateien (docs/phase_reports/phase0_report.md, phaseA_report.md, phaseB_report.md, phaseC_report.md) mit den wichtigsten Outputs und Kennzahlen pro Phase

• Run-Metadaten / Provenance: run_manifest.json mit Laufkontext (Notebook-Version, Zeitstempel, Pfade, Konfiguration/Parameter)

• Fixity / Integrität: checksums.sha256 sowie sip_manifest.json (Dateiliste inkl. Größe/Hash), um spätere Integritätsprüfungen zu ermöglichen

• Ausgewählte Ergebnisartefakte (z. B. Quality-/Coverage-Tabellen, Feature-Exporte, Modellmetriken), soweit im Paket enthalten und im Report referenziert

Die Archivlogik orientiert sich an einem OAIS-nahen Minimalmodell:

• SIP (Submission Information Package): kuratiertes Arbeits-/Abgabepaket (Doku, Reports, Metadaten, ausgewählte Outputs)

• AIP/DIP: Verpackungen zur stabilen Langzeitablage bzw. zum Teilen/Publizieren (z. B. AIP als tar.gz, DIP als zip)

Datenbasis und Einschränkungen (Lizenz/Größe)

Das Projekt verwendet synthetische Daten aus Synthea. Bestimmte große oder lizenzkritische Abhängigkeiten werden nicht im Deposit mitpubliziert, insbesondere:

• OHDSI/Athena OMOP Vocabulary-Dateien (typischerweise ausgeschlossen aus Lizenz-/Terms-of-Use-Gründen sowie wegen Größe)
  Stattdessen wird der Bezug dieser Ressourcen über die Dokumentation beschrieben und die verwendete Vokabular-Version (soweit möglich) im Projekt dokumentiert.

Ebenfalls üblicherweise ausgeschlossen sind große, reproduzierbare Zwischenstände (z. B. Cache-Verzeichnisse oder entpackte Roh-CSV-Bestände), sofern diese nicht zwingend zur Bewertung/Validierung benötigt werden.

Reproduzierbarkeit

Die Reproduzierbarkeit wird durch mehrere Ebenen unterstützt:

• Klare Phasenstruktur (0/A/B/C) mit zugehörigen Reports und Artefakten

• Run-Manifest (run_manifest.json) als Provenance- und Konfigurationsquelle (Version, Laufzeit, Parameter, relevante Pfade)

• Fixity-Checks über checksums.sha256 und sip_manifest.json (Hash-basierte Integritätsprüfung der Paketdateien)

Die Reproduktionsschritte sind in README.md beschrieben (u. a. Abhängigkeiten, erwartete Verzeichnisstruktur und Hinweise zu extern zu beschaffenden Vokabular-Dateien).

Zweck und Zielgruppe

Das Paket dient als nachvollziehbares Beispiel für:

• ETL-orientierte Verarbeitung synthetischer Gesundheitsdaten

• Qualitäts- und Coverage-Auswertungen (Data Quality Checks, Mapping Coverage)

• Ableitung von Feature-Tabellen für analytische Auswertungen/ML

• Archivierungs- und Publikationsfähigkeit (FAIR-orientierte Dokumentation, Provenance, Fixity)

Zielgruppe sind Studierende/Lehrende sowie Reviewer mit Grundkenntnissen in Python, SQLite und OMOP-naher Datenmodellierung, die eine reproduzierbare Pipeline prüfen oder als Vorlage adaptieren möchten.

Zitation und Versionierung

Dieses Deposit entspricht einer bestimmten Notebook-/Release-Version (z. B. V13) und einem eindeutigen Laufzeitstempel. Bei späteren Änderungen werden neue Versionen als separate Releases publiziert; die Provenance wird über run_manifest.json fortgeführt.