07 · Patientendaten-Extraktion via FHIR und OMOP

Klinischer Aufhänger

Deine Arbeitsgruppe plant eine retrospektive Studie zu Laktatverläufen. Anstatt Excel-Listen manuell auszufüllen, willst du die Daten direkt aus der Patient:innenakte (KAS) extrahieren. Das KAS deines Klinikums bietet eine FHIR-Schnittstelle und speichert Forschungsdaten im OMOP-Format. Hier lernst du, wie du eine Abfrage schreibst, die Patient:innenstammdaten und Laborwerte automatisiert zusammenführt.

1 Das FHIR-Konzept

FHIR strukturiert medizinische Daten in Ressourcen. Jede Ressource repräsentiert eine klinische Entität:

• Patient: Demografische Daten (Alter, Geschlecht).
• Observation: Messwerte (Laborwerte wie Laktat, Vitalparameter wie Blutdruck).
• Encounter: Ein Aufenthalt (z. B. Notaufnahme, Intensivstation).

FHIR nutzt das REST-Prinzip: Daten werden über URLs abgerufen.

• GET https://fhir-server.de/fhir/Patient/123 liefert den/die Patient:in mit ID 123 als JSON oder XML.
• GET https://fhir-server.de/fhir/Observation?code=2524-7 liefert alle Laktat-Messwerte (LOINC-Code 2524-7).

import json
import urllib.request
import pandas as pd

# 1. Bundle laden (die https://schradern.github.io/data-science-coach/data/-URL liefert dasselbe JSON, das ein FHIR-Server
#    fuer GET .../Observation?code=... zurueckgeben wuerde). Wir nutzen urllib
#    aus der Standardbibliothek -- 'requests' ist nicht in der Kurs-Grundausstattung.
with urllib.request.urlopen("https://schradern.github.io/data-science-coach/data/fhir_bundle.json") as response:
    bundle = json.load(response)

# 2. Bundle in eine flache Tabelle entpacken: ein JSON-Objekt pro Ressource
flat = pd.json_normalize(bundle["entry"], sep="_")

# 3. Patient- und Observation-Ressourcen trennen
patients = (
    flat[flat["resource_resourceType"] == "Patient"]
    [["resource_id", "resource_gender", "resource_birthDate"]]
    .rename(columns={"resource_id": "patient_id", "resource_gender": "geschlecht",
                     "resource_birthDate": "geburtsdatum"})
)
print(patients)

library(jsonlite)

# 1. Bundle laden (lokale Datei oder URL)
bundle <- fromJSON("https://schradern.github.io/data-science-coach/data/fhir_bundle.json", simplifyVector = FALSE)

# 2. Patient-Ressourcen in eine Tabelle sammeln
patient_rows <- list()
for (entry in bundle$entry) {
  res <- entry$resource
  if (res$resourceType == "Patient") {
    patient_rows[[length(patient_rows) + 1]] <- data.frame(
      patient_id = res$id, geschlecht = res$gender, geburtsdatum = res$birthDate
    )
  }
}
patients <- do.call(rbind, patient_rows)
print(patients)

4 Das OMOP Common Data Model

Während FHIR für den Datenaustausch optimiert ist, dient das OMOP Common Data Model (CDM) der standardisierten Analyse. Krankenhäuser transformieren ihre lokalen Datenbanken in das OMOP-Format, damit derselbe Analysecode an Hunderten Kliniken weltweit laufen kann.

Kernelemente des OMOP-Modells:

• PERSON: Enthält eindeutige demografische Daten (Geschlecht, Geburtsjahr).
• MEASUREMENT: Enthält Messwerte und Laborergebnisse (verknüpft über Concept-IDs mit LOINC/SNOMED).

OMOP-SQL-Abfrage: Laktatwerte extrahieren

SELECT 
    p.person_id,
    p.year_of_birth,
    p.gender_concept_id,
    m.measurement_date,
    m.value_as_number,
    m.unit_source_value
FROM person p
JOIN measurement m ON p.person_id = m.person_id
WHERE m.measurement_concept_id = 3004327 -- Concept ID fuer Laktat (Beispiel)
ORDER BY m.measurement_date DESC;

Fallstricke und Merksätze

• FHIR-JSONs sind tief verschachtelt. Listen in Listen machen direktes Einlesen unmöglich. Du musst Daten explizit parsen oder Hilfsbibliotheken nutzen.
• Concepts statt Rohwerte. OMOP nutzt standardisierte Concept-IDs. Statt nach "Laktat" zu suchen, musst du nach der spezifischen ID (3004327) filtern.
• Datenschutz. FHIR-REST-APIs können sensible Patient:innendaten unverschlüsselt übertragen. Nutze im Kliniknetzwerk ausschließlich verschlüsselte HTTPS-Verbindungen.

Selbstcheck