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.

Die Verarbeitung erfolgt in einer modularen, phasenbasierten Notebook-Struktur: (Phase 0) Setup, Download/Import und Rohdatenpersistenz (RAW_DB), (Phase A/B) Qualitätsprüfungen, Codesystem-Erkennung sowie Mapping-/Coverage-Auswertungen und Aufbau eines OMOP-nahen Data-Warehouse (DWH_DB), (Phase C) Ableitung standardisierter Exporte/Feature-Tabellen und optionaler ML-Auswertungen. Alle wesentlichen Outputs werden als Markdown-Reports je Phase abgespeichert; Provenance wird über ein run_manifest.json und Integrität über SHA-256-Checksums dokumentiert. Lizenzkritische und große externe Ressourcen (insbesondere OHDSI/Athena Vokabular-Dateien) werden nicht mitpubliziert, sondern in der Dokumentation als externe Abhängigkeit referenziert.