Skip to content

Metadatenkatalog eines Datenmodells für die Post-COVID-Forschung. Das Datenmodell ermöglicht die Verknüpfung von medizinische Versorgungsdaten mit offenen Daten.

License

Notifications You must be signed in to change notification settings

technologiestiftung/post-covid-datenmodell

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

40 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Post-Covid Metadatenkatalog

All Contributors

Über dieses Projekt

Die Technologiestiftung Berlin entwickelt im Rahmen der Post-COVID-Challenge des Dateninstituts des Bundes ein Datenmodell zur Post-COVID-Forschung. Dieses ermöglicht es Medizinforschenden, Gesundheitsdaten mit offenen Daten zu kombinieren. Aktuell befinden wir uns in der zweiten von drei Challenge-Stufen. Ziel ist es, eine Datengrundlage für gesellschaftlich relevante Forschungsfragen zu schaffen, unterstützt durch Tools zur Verschneidung und Analyse medizinischer und offener Daten.

Inhalt

  1. Projekt-Struktur
  2. Quick-Start
  3. Benutzte Datenquellen
  4. Erstellen und Validieren von Metadaten: Vorgehen und Ergebnisse
  5. Geographisches Mapping
  6. Autoren, Mehr Informationen

Projekt-Struktur

Dieses GitHub-Repository benutzt synthetische MII-Daten (mehr dazu hier) und andere offenen Datenquellen, wie z.B. Wetterdaten, um Forscher:innen Informationen zu Patient:innen bereitzustellen.

Die synthetischen Daten der MII-Patient:innen sind in data/raw/ zu finden. Eine Übersicht zu benutzten (externen) Daten folgt in Tabelle 1.

Für die externen Datenquellen wurde jeweils ein Skript/eine Klasse erstellt, diese sind in src/download hinterlegt. Dort befindet sich auch ein Skript, um die Patient:innen aus den synthetischen Daten zu extrahieren src/download/patient.py.

Use-Cases für jede Abfrage der Daten können in Juypter-Notebooks in dem Ordner src/use_cases durchgeführt werden. Folgen Sie dafür dem Quick Start.

Quick Start

Dieses Projekt wurde mit Hilfe von poetry aufgesetzt. Poetry übernimmt das Management der benötigten Pakete/ Libraries für die Skripte in python. Bitte Stellen Sie sicher, dass Sie poetry installiert haben, bevor Sie das Projekt lokal ausführen. Siehe hier: Poetry Website / Installation.

Um das Projekt lokal aufzusetzen und alle dependencies zu installieren, führen Sie bitte folgende Terminal-Befehle innerhalb des Projekts aus. Siehe auch offizielle Poetry Dokumentation für mehr Informationen.

$ poetry install # installiert dependencies von der Datei 'pyproject.toml' und erstellt eine Datei 'poetry.lock'
$ poetry shell # Aktiviert das virtual environment (mit dependencies)

Das Projekt ist anhand von 'Use Cases' aufgebaut. Für jeden 'Use Case' und den darin verarbeiteten Datensatz gibt es ein Jupyter Notebook.

Für eine Auflistung der verfügbaren Skripte und abgedeckten Use Cases gibt es eine erweiterte Dokumentation: Tabelle 3: Auflistung abgedeckte Use Cases. Bitte stellen Sie sicher, dass Sie beim Ausführen der Skripte innerhalb des Poetry Enviroments sind.

Benutzte Datenquellen

Für das Projekt wurden mehrere (öffentliche) Datensätze benutzt, um weitere Informationen an die Patient:innen-Daten zu spielen.

Datensatz Kurzbeschreibung Link Metaden-Beschreibung
Luftdaten (Umweltbundesamt) Die API des Umweltbundesamt gibt für verschiedene Stationen in Deutschland Luftdaten an. Es gibt einen Luftindex (generelle Angabe zu der Luftqualität), sowie stündliche Werte für einzelne Schadstoffe (z.B. Feinstaub PM₁₀). https://www.umweltbundesamt.de/daten/luft/luftdaten/doc Frictionless Metadaten, DCAT Metadaten
Wetterdaten (Bright Sky) Die API für Wetterdaten sellt die Daten des Deutschen Wetterdienstes bereit. Wettereigenschaften wie Niederschlag, Sonnenstunden, Temperatur, können mit einem Standort (Breitengrad, Längengrad) stündlich abgefragt werden. https://brightsky.dev/ Frictionless Metadaten, DCAT Metadaten
Abwasserdaten (Viruslast im Wasser) - RKI Die Daten stammen aus dem Projekt Abwassersurveillance AMELAG vom Robert-Koch-Institut (RKI) und enthalten Daten über Infektionserreger im Wasser von Klärwerken in Deutschland. Der Datensatz wird während der Projektlaufzeit von AMELAG wöchentlich aktualisiert und ist über GitHub zugänglich. Auf Nachfrage bei dem RKI wurden auch die Standorte der Stationen angegeben, um ein besseres Matching von Patient:innen auf die relevante Station zu garantieren. https://github.com/robert-koch-institut/Abwassersurveillance_AMELAG/tree/main Frictionless Metadaten, DCAT Metadaten
Post-COVID Ambulanzen / Kliniken Die Daten für Post-COVID Ambulanzen stammen von der Initiative Long Covid des Bundesgesundheitsministeriums. Die Daten aus der dort aufgelisteten Tabelle wurden zuletzt am 02.12.2024 abgefragt und befinden sich in der folgenden Datei. https://www.bmg-longcovid.de/service/buergertelefon-und-regionale-kliniksuche
Post-COVID Reha Angebote Die Daten für Post-COVID Reha Angebote stammen von der Bundesarbeitsgemeinschaft für Rehabilitation (BAR). In der Suche wurden alle Reha Angebote ausgewählt und gescraped, die mit der Auswahl 'Rehabilitation bei Long/Post COVID' zu finden sind. Dabei sind stationäre und ambulante Reha Angebote enthalten. https://www.reha-einrichtungsverzeichnis.de/index.html
SARS-CoV-2-Infektionen in Deutschland Der Datensatz stammt vom RKI und enthält 'umfassende Informationen zu SARS-CoV-2-Infektionen in Deutschland, die gemäß dem Infektionsschutzgesetze (IfSG) von den Gesundheitsämtern an das Robert Koch-Institut (RKI) gemeldet wurden.' - GitHub Beschreibung des RKIs https://github.com/robert-koch-institut/SARS-CoV-2-Infektionen_in_Deutschland Frictionless Metadaten, DCAT Metadaten

Tabelle 1: Übersicht der benutzten Datenquellen

Erstellen und Validieren von Metadaten: Vorgehen und Ergebnisse

DCAT-AP.de

  1. Erstellung der DCAT-AP.de-Metadaten:
    Wir haben die zentralen Felder nach DCAT-AP.de-Standard definiert, um eine optimale Auffindbarkeit und klare Struktur sicherzustellen. Dabei haben wir:

    • Je nachdem ob ein Datensatz oder eine API (Datenservice) beschrieben wird, die entsprechenden Klassen (dcat:Dataset oder dcat:DataService) verwendet.
    • Titel (dct:title), Beschreibung (dct:description), und Herausgeber (dct:publisher) festgelegt, um die Identität und den Kontext des Datensatzes zu beschreiben.
    • Kontaktinformationen (dcat:contactPoint) sowie Lizenzdetails (dct:license) aufgenommen, um rechtliche und Support-Angaben einzubinden.
    • Schlagwörter (dcat:keyword) und Themenbereiche (dcat:theme) hinzugefügt, um die thematische Zuordnung und Suchbarkeit zu verbessern.
    • Unter Verteilung (dcat:distribution) Zugangs-URLs und Dateiformate beschrieben, um Nutzenden einen direkten Zugriff zu ermöglichen.
  2. Validierung:
    Die erstellten Metadaten haben wir im DCAT-AP.de Validator geprüft. Der Validator bestätigte die Konformität unserer Metadaten. Über den DCAT-AP.de-Validator können bei Bedarf auch SHACL-Shapes erstellt werden.

Frictionless Data

:::info Hinweis: Die frictionless data Metadaten wurden für den Piloten nur exemplarisch erstellt und validiert. Ob eine vollständige Integration in die bestehende Infrastruktur sinnvoll ist, sollte im Rahmen einer zukünftigen Entwicklung geprüft werden. :::

  1. Erstellung der Frictionless Data Metadaten:
    Zur Strukturierung haben wir eine datapackage.json erstellt und darin die relevanten Metadatenfelder aufgenommen:

    • Name, Titel und Beschreibung geben grundlegende Informationen zum Datensatz.
    • Lizenzen und Quellen bieten rechtliche Klarheit und Dokumentation der Datenherkunft.
    • Unter contributors wurden alle beteiligten Teams und Personen verzeichnet.
    • Im Abschnitt resources mit schema haben wir detaillierte Informationen zu allen Feldern, Datentypen und Beschreibungen jeder Datentabelle festgehalten.
  2. Validierung:
    Die Metadaten können mit der frictionless CLI oder der Python-Bibliothek validiert werden. Dazu haben wir die datapackage.json mit dem Befehl frictionless validate metadata/frictionless/datapackage.json --type package geprüft.

    Für eine zukünftige Entwicklung müsste festgelegt werden, wie genau frictionless Data in die bestehende Infrastruktur integriert werden soll. Dementsprechend müssten Anpassungen an den Metadaten vorgenommen werden (z.B. spezifische Abfragen der APIs) und eine Umstrukturierung der Daten als vollständige Data Packages.

Durch die strukturierte Erstellung und Validierung nach DCAT-AP.de- und Frictionless-Standards sind die Metadaten nun gut auffindbar und beschrieben. Dies erleichtert die Nutzung und Weiterverwendung der Daten für unterschiedliche Zwecke.

Geographisches Mapping

Die benutzten Datenquellen und die synthetischen MII-Daten arbeiten mit verschiedenen geographischen Angaben, wie Postleitzahl, Breitengrad/ Längengrad. Es wurden daher Skripte / Dokumente erstellt, die helfen zwischen den Angaben zu mappen. Skripte für geographisches Mapping sind unter address_transformation.py zu finden.

Datensatz / Quelle Kurzbeschreibung Beispiel
Mapping von Breitengrad (Lat) und Längengrad (Lng) zu einer Postleitzahl.
  • 2024-11-14_plz_geocoord.csv
  • Wurde hier aufgerufen: Geokoordinaten für Postleitzahlen und ursprünglich von der Google Cloud Geocoding API (in 2019) abgefragt. Wird benutzt um für unvollständige Postleitzahlen einen geschätzten Mittelpunkt zu finden (in Breitengrad / Längengrad)
    Mapping von Postleitzahl auf IdLandkreis
  • 2024-12-03_postleitzahlen_kreis_id.csv
  • 2024-12-03_berlin_plz_mapping.csv
  • Wird benutzt um bei den Covid-Daten von dem RKI die sogenannte IdLandkreis zu generieren. Basiert auf einer Veröffentlichung von Opendatasoft; BKG mit Angaben zu Land- und Kreiscode für Postleitzahlen in Deutschland. Für die Generierung des Mappings Postleitzahl -> IdLandkreis wurde Landcode und Kreiscode benutzt. für Berlin gelten vom RKI definierte Sonderregelungen (Anpassung der ID),diese wurde manuell erstellt und ist in 2024-12-03_berlin_plz_mapping.csv festgehalten. Manuell meint hier: Das RKI hat in seiner Dokumentation siehe GitHub Repo RKI festgehalten, welche Bezirke in Berlin welche ID bekommen. Es wurden dann manuell (per Google) die Postleitzahlen für diese Bezirke gesucht und den jeweiligen IDs zugeordnet. wird benutzt um bei der Abfrage der Covid-Daten die richtige ID in den Daten für die Postleitzahl der Patient:innen zu finden
    Bundesland-Abkürzungsverzeichnis
  • 2024-11-13_federal_state_mapper.xlsx
  • Wurde manuell erstellt. Enthält Bundesland Abkürzungen und die ausgeschriebenen Namen der Bundesländer Kann beispielsweise verwendet werden um Bundesländer-Abkürzungen in den Covid-Daten zu 'übersetzen' .

    Tabelle 2: Geographisches Mapping

    Utils / Hilfsfunktionen

    Für die verschiedenen Use Cases wurden Hilfsfunktionen, wie z.B. Berechnung des Alters der Patient:innen erstellt. Diese sind in dem Ordner src/utils zu finden. In dem Skript graph_configurations.py wurden für die verschiedenen Use Cases Funktionen für die Datenvisualisierung erstellt. So können einfache Timeline Plots erstellt werden. Das Skript time_age_calculation.py enthält Hilfsfunktion um beispielsweise die Altersgruppe der Patient:innen (benutzt für die Covid Cases) zu finden oder den Zeitraum X Monate vor- und nach einem Datum zu finden.

    Autoren, Mehr Informationen

    Weiterführende Informationen zum Projekt, sowie der Challenge zur Gründung des Dateninstitutes finden Sie auf der Seite der Technologiestiftung Berlin.

    Dieses Repository wurde in Kollaboration der Technologiestiftung Berlin und &effect erstellt.

    Contributors ✨

    Thanks goes to these wonderful people (emoji key):

    bauerfriederike
    bauerfriederike

    💻 📖
    ckeuss
    ckeuss

    📖 👀
    Max B. Eckert
    Max B. Eckert

    📆 📖
    jjmllr
    jjmllr

    💻 📖 📆

    This project follows the all-contributors specification. Contributions of any kind welcome!

    Credits



    In Zusammenarbeit mit:

    und:

    Im Auftrag des:

    About

    Metadatenkatalog eines Datenmodells für die Post-COVID-Forschung. Das Datenmodell ermöglicht die Verknüpfung von medizinische Versorgungsdaten mit offenen Daten.

    Resources

    License

    Stars

    Watchers

    Forks

    Releases

    No releases published

    Packages

    No packages published

    Contributors 3

    •  
    •  
    •