7 Klinische Daten liegen in Silos. EHR-Plattformen, PACS-Bildarchive, Genomdatenbanken, Laborinformationssysteme und Echtzeit-Monitoring-Feeds sprechen alle unterschiedliche Formate, laufen auf getrennter Infrastruktur und unterliegen unterschiedlichen Compliance-Regelungen. Wer wirksame KI-Pipelines für klinische Daten aufbauen will, muss diese Quellen zusammenführen, ohne Daten zu verlieren, den Datenschutz von Patienten zu verletzen oder eine Speicherarchitektur zu schaffen, die unter den GPU-Workloads zusammenbricht, die Sie gleich ausführen werden. Dieser Leitfaden geht jede Phase einer KI-Pipeline für klinische Daten durch – von der Rohdatenaufnahme bis zur Langzeitarchivierung – mit praktischen Speicheranforderungen, regulatorischen Vorgaben und Designmustern für Teams, die eine Datenplattform in Krankenhäusern, Forschungseinrichtungen und Pharmaunternehmen verantworten. Was sind KI-Pipelines für klinische Daten? KI-Pipelines für klinische Daten sind durchgängige Data-Engineering-Systeme, die Patienten- und Forschungsdaten aus ihren Quellsystemen in eine Form bringen, die KI-Modelle verarbeiten können – und die Modellergebnisse anschließend zurück in klinische oder betriebliche Workflows leiten. Eine ausgereifte Pipeline umfasst sechs Phasen: Aufnahme – Abruf aus EHRs (HL7 FHIR, HL7 v2), DICOM-Bildarchiven, Ergebnissen der Genomsequenzierung, Wearable-Streams und Laborsystemen Normalisierung und Annotation – Standardisierung von Terminologien (SNOMED, ICD-10, LOINC), Umgang mit fehlenden Werten und De-Identifizierung Feature Engineering und Embedding – Umwandlung strukturierter und unstrukturierter Datensätze in Vektordarstellungen, tabellarische Features oder multimodale Tensoren Modelltraining und Checkpointing – Verteilung von Trainings-Workloads auf GPUs und häufiges Speichern von Checkpoints, um bei mehrtägigen Läufen keinen Fortschritt zu verlieren Inferenz und Bereitstellung – Ausführung trainierter Modelle auf aktuellen oder Batch-Daten aus der Klinik, um Vorhersagen, Risikowerte oder Empfehlungen zu erzeugen Archivierung und Aufbewahrung für Audits – Aufbewahrung sowohl der Rohdaten als auch der Modellartefakte gemäß regulatorischen Fristen (HIPAA, GxP, 21 CFR Part 11) Die zentrale Erkenntnis: Jede Phase hat grundlegend andere Speicheranforderungen. Eine Pipeline, die alle klinischen Daten gleich behandelt, zahlt entweder zu viel (kalte Genomarchive auf NVMe) oder kommt ins Stocken (Modelltraining auf langsam drehenden HDDs). Das Fragmentierungsproblem in der klinischen KI Die meisten Datenplattform-Teams in Krankenhäusern und Pharmaunternehmen verbringen 60–70 % der Zeit ihrer KI-Projekte mit Data Engineering – nicht mit der Modellentwicklung. Die Ursachen sind vorhersehbar: Heterogene Quellsysteme. Ein einziges Universitätsklinikum betreibt womöglich drei EHR-Systeme verschiedener Anbieter, ein altes PACS, einen modernen DICOM-Router, eine Pipeline für Next-Generation Sequencing und ein Dutzend Abteilungsdatenbanken. Jedes System exportiert Daten in anderen Schemata und nach anderen Zeitplänen. Inkompatible Formate. DICOM-Bilder, FASTA-Genomsequenzen, HL7-Nachrichtenströme, OMOP-CDM-Tabellen und klinische Freitextnotizen erfordern völlig unterschiedliche Strategien für Parsing, Normalisierung und Speicherung. Eine Pipeline, die das eine gut beherrscht, kommt mit dem anderen meist schlecht zurecht. Regulatorische Fragmentierung. Die De-Identifizierung nach HIPAA Safe Harbor muss erfolgen, bevor Daten bestimmte Grenzen überschreiten. GxP-Audit-Trails verlangen unveränderliche Protokolle bei jedem Transformationsschritt. Manche europäischen Forschungsdaten dürfen bestimmte Rechtsräume nicht verlassen. Diese Vorgaben wirken untereinander und mit der technischen Pipeline auf eine Weise zusammen, die erst offensichtlich wird, wenn etwas schiefgeht. Ungleiche Datenmengen. Eine einzelne Radiologieabteilung erzeugt pro Woche Terabytes an DICOM-Daten. Eine genomische Kohortenstudie kann in einem einzigen Sequenzierlauf Hunderte Terabyte erzeugen. Um ein multimodales Foundation Model mit beidem zu trainieren, braucht es eine Infrastruktur, die Aufnahmespitzen auffängt, ohne den Rest der Pipeline auszubremsen. Architektur der Pipeline-Phasen und Speicheranforderungen Die folgende Tabelle ordnet jeder Pipeline-Phase ihre Speichertemperatur, ihre Leistungsanforderungen und die Lebensdauer der Daten zu. Nutzen Sie sie als ersten Leitfaden für die Infrastruktur. Phase Speichertemperatur Typisches Leistungsziel Aufbewahrung / Lebenszyklus Puffer für Rohdatenaufnahme Heiß (NVMe / QLC-SSD) Schreibdurchsatz von mehreren GB/s Tage bis Wochen; Übergabe an die normalisierte Ebene Arbeitsbereich für Normalisierung Heiß (QLC/NL-SSD) Hohe IOPS, wahlfreies Lesen Tage; Löschen nach Validierung Feature Store / Embeddings Warm (NL-HDD oder dichte SSD) Hohe Lesebandbreite für das Training Monate; versionieren und Snapshots erstellen Trainings-Checkpoints Heiß während des Laufs; danach warm Schreiben mit geringer Latenz während des Trainings Projektdauer + regulatorische Aufbewahrung Inferenz-Cache (KV / RAG-Index) Heiß (NVMe / GPU-Direct) Latenz unter einer Millisekunde Sitzungsbezogen oder kurzlebig Modellartefakte Warm bis kalt Moderates Lesen bei der Bereitstellung Projektlaufzeit + Nachfrist für Audits Audit-Logs und Herkunftsnachweise Kalt (bandnah oder Cloud) Nur anhängendes Schreiben 7–10 Jahre (Minimum nach HIPAA/GxP) Langfristiges Genom- / Bildarchiv Kalt Nur Massenabruf 20–30 Jahre (in manchen Rechtsräumen) Aufnahmeebene Auf der Aufnahmeebene treffen Geschwindigkeit und Vielfalt der Daten aufeinander. DICOM-Router können fortlaufend Studien mit mehreren Gigabyte senden; HL7-Nachrichtenströme kommen stoßweise beim Schichtwechsel an; Ergebnisse von Genompipelines landen als große, sequenzielle Dateien. Speicheranforderung: Hoher Schreibdurchsatz mit Objektspeicher-Semantik. Mit S3-kompatiblen Endpunkten lassen sich Quellkonnektoren vereinheitlichen, ohne für jedes vorgelagerte System eigene Adapter zu benötigen. Prüfsummen beim Schreiben und unveränderliches Object Locking schützen vor Beschädigung während der Aufnahme. Normalisierung und Annotation De-Identifizierung, Terminologie-Mapping und Qualitätsfilterung laufen als Transformationsjobs – oft als verteilte Spark- oder Dask-Pipelines. Das Ergebnis ist ein normalisierter Datensatz, den nachgelagerte ML-Tools ohne Abhängigkeiten von den Quellsystemen nutzen können. Speicheranforderung: Hohe IOPS beim wahlfreien Lesen für Transformations-Worker, die Rohobjekte lesen, plus schnelles Schreiben für die bereinigte Ausgabe. Die Kennzeichnung mit Metadaten ist in dieser Phase entscheidend: Jeder normalisierte Datensatz sollte seine Herkunft (Quellsystem, Transformationsversion, Methode der De-Identifizierung) als Objektmetadaten oder in einem Sidecar-Manifest mitführen. Siehe Konformer S3-Speicher für regulierte Daten (auf Englisch) zu Mustern für die Durchsetzung von Zugriffskontrollen und Audit-Trails in dieser Phase. Feature Engineering und Embedding Feature Engineering wandelt normalisierte klinische Datensätze in Darstellungen um, mit denen Modelle trainieren können: tabellarische Feature-Vektoren, Text-Embeddings, Bildtensoren oder Graphdarstellungen für Wissensgraphen. Für Workflows mit Retrieval-Augmented Generation (RAG) erzeugt diese Phase zudem Vektor-Embeddings, die in einem Vektorindex gespeichert werden. Speicheranforderung: Hohe sequenzielle Lesebandbreite für Data Loader im Training plus effiziente Speicherung von Vektorindizes. Siehe Speicher für Vektordatenbanken und Speicher für multimodale KI-Daten für eine ausführlichere Betrachtung der Speicherung von Embeddings. Mehr zur RAG-Speicherarchitektur in KI-Workflows bietet der Beitrag Retrieval-Augmented Generation und Speicher für KI. Modelltraining und Checkpoints Verteilte Trainingsjobs – ob bei der Feinabstimmung eines klinischen NLP-Modells oder beim Training eines multimodalen Bildgebungsmodells – erzeugen häufig Checkpoint-Dateien. Ein Checkpoint eines Modells mit 70 Mrd. Parametern kann über 140 GB groß sein; Jobs, die tagelang laufen, erzeugen womöglich Dutzende Checkpoints. Speicheranforderung: GPU-Direct-Zugriff während aktiver Trainingsläufe (Latenz unter 50 µs von der GPU zum Speicher); warmer Objektspeicher für die Archivierung von Checkpoints. Einen Checkpoint bei einem 96-stündigen Trainingslauf zu verlieren, ist ein teurer Fehler – Checkpoint-Speicher muss haltbar und sofort zugänglich sein. Inferenz und Bereitstellung Die produktive Inferenz für klinische Entscheidungsunterstützung erfordert einen schnellen Abruf von Modellartefakten und bei RAG-basierten Systemen schnellen Zugriff auf Vektorindizes und Dokumentenspeicher. Der KV-Cache für die Inferenz großer Sprachmodelle muss sich am selben Ort wie die GPU-Rechenleistung befinden. Speicheranforderung: Speicher auf NVMe-Ebene mit S3-over-RDMA-Zugriff für den KV-Cache. Die Latenz wirkt sich hier direkt auf die Antwortzeit für Ärztinnen, Ärzte und nachgelagerte automatisierte Workflows aus. Archivierung und Aufbewahrung für Audits Jede Phase der Pipeline erzeugt Daten, die aus Compliance-Gründen aufbewahrt werden müssen: Quelldatensätze, Transformationsmanifeste, Modellversionen, Inferenzprotokolle und Audit-Trails. HIPAA schreibt für die meisten Unterlagen eine Mindestaufbewahrung von sechs Jahren vor; GxP nach 21 CFR Part 11 verlangt die Integrität der Audit-Trails über die gesamte Lebensdauer des Produkts. Für Genomdaten können je nach Rechtsraum Aufbewahrungspflichten von 20–30 Jahren gelten. Speicheranforderung: Kostengünstiger, bandnaher oder Cloud-Objektspeicher mit WORM-Durchsetzung (Write Once, Read Many) und Object Lock. Lesen Sie Richtlinie zur Datenaufbewahrung: Definition, Beispiele und Best Practices zu Designmustern für den Lebenszyklus. Automatisierte Übergänge zwischen Ebenen behandelt der Beitrag S3-Lebenszyklusrichtlinie. Regulatorische Vorgaben für klinische KI-Pipelines HIPAA und De-Identifizierung Die HIPAA Privacy Rule verlangt, dass geschützte Gesundheitsinformationen (PHI) de-identifiziert werden, bevor sie für die meisten Zwecke des KI-Trainings und der Forschung genutzt werden dürfen. Zwei Methoden sind anerkannt: Safe Harbor (Entfernen von 18 bestimmten Identifikatoren) und Expert Determination (statistischer Nachweis, dass das Re-Identifizierungsrisiko ausreichend gering ist). Folge für die Pipeline: Die De-Identifizierung muss ein dokumentierter, prüfbarer Transformationsschritt sein. Die identifizierten Rohdaten und die de-identifizierte Ausgabe müssen unter unterschiedlichen Zugriffskontrollen gespeichert und das Transformationsprotokoll muss aufbewahrt werden. ACLs auf Objektebene und unveränderliche Audit-Trails sind nicht optional – sie sind der Mechanismus der Compliance. Einen genaueren Blick auf die Architektur HIPAA-konformen Speichers bietet der Beitrag HIPAA-konformer Speicher. GxP und 21 CFR Part 11 KI-Pipelines in der Pharmaindustrie, die regulatorische Einreichungen speisen – Modelle zur Wirksamkeit von Arzneimitteln, Erkennung von Sicherheitssignalen, Analyse klinischer Studiendaten –, müssen GxP-Qualitätsstandards und bei elektronischen Aufzeichnungen 21 CFR Part 11 erfüllen. Das bedeutet: Elektronische Signaturen für Datensätze und Transformationsschritte Audit-Trails, die jeden Lese-, Schreib- und Änderungsvorgang mit Zeitstempel und Benutzeridentität erfassen Systemvalidierung mit Dokumentation für die Pipeline-Infrastruktur selbst Speicher, der kryptografisch überprüfbare Audit-Logs erzeugt und WORM-Semantik unterstützt, ist eine Compliance-Anforderung und kein Extra. Datensouveränität und grenzüberschreitende Vorgaben Klinische Studien in der EU unter der DSGVO, Daten der UK Biobank und manche nationalen Genomikprogramme schränken ein, wo Patientendaten verarbeitet und gespeichert werden dürfen. Eine Pipeline, die Daten ohne ausdrückliche Auftragsverarbeitungsvereinbarungen über eine Cloud-Region in den USA leitet, ist ein Compliance-Risiko. Folge für die Pipeline: On-Premises- oder Private-Cloud-Speicher mit klar definierten geografischen Grenzen. Sowohl die Steuerungsebene als auch die Datenebene der Pipeline müssen Souveränitätsvorgaben einhalten. Wie Scality ADI klinische KI-Pipelines unterstützt Scality ADI (Autonomous Data Infrastructure) ist genau für diese Art mehrstufiger, regulierter KI-Workloads konzipiert. Es unterstützt den gesamten KI-Datenfluss: Aufnahme → Aufbereitung → Multimodal Agentic RAG / VSS / Deep Research Agents / KV-Cache → Checkpoints → Embeddings → Logs → Langzeitaufbewahrung. Das temperaturübergreifende Design lässt sich direkt auf die oben beschriebenen Phasen der klinischen Pipeline abbilden: GPU-Direct-Ebene (TLC-Flash + S3 over RDMA, Latenz unter 50 µs): KV-Cache für die Inferenz, aktive Trainingsjobs, Embedding-Abfragen in Echtzeit Heiße Ebene (QLC/NL-SSD, Durchsatz von mehreren TB/s): Aufnahmepuffer, Arbeitsbereiche für die Normalisierung, aktive Feature Stores Warme Ebene (NL-HDD/HDD): Archive für Trainings-Checkpoints, versionierte Modellartefakte, Vektorindizes zwischen Trainingsläufen Kalte Ebene (bandnah, Cloud-nah): langfristige Genom- und Bildarchive, Audit-Logs, Compliance-Aufbewahrung nach HIPAA und GxP Für klinische und pharmazeutische Teams adressiert das CORE5-Framework von Scality ADI (Capacity, Operations, Resilience, Efficiency, Security) die Audit-Bereitschaft direkt. Unveränderliches Object Lock, kryptografische Audit-Trails und rollenbasierte Zugriffskontrollen sind in die Speicherebene integriert – nicht nachträglich angeflanscht. So lassen sich de-identifizierte Daten, Transformationsprotokolle und Herkunftsnachweise der Modelle in derselben konformen Infrastruktur aufbewahren, in der auch die klinischen Rohdaten liegen. Souveräne Kontrolle ist eine zentrale Fähigkeit. Scality ADI läuft vollständig On-Premises oder in einer Private-Cloud-Umgebung, sodass Patientendaten die von Ihnen kontrollierte Infrastruktur nie verlassen. Das ist wichtig für die Abdeckung durch HIPAA-BAAs, die Grenzen der GxP-Validierung und die Anforderungen an die grenzüberschreitende Datensouveränität in der klinischen Forschung in der EU und im Vereinigten Königreich. Mehrstufiger Speicher für KI: skalierbare Leistung und Kostenkontrolle behandelt das umfassendere Modell mehrstufigen Speichers hinter dem temperaturübergreifenden Design von Scality ADI. Häufig gestellte Fragen Was sind KI-Pipelines für klinische Daten? KI-Pipelines für klinische Daten sind durchgängige Data-Engineering-Systeme, die Patienten- und Forschungsdaten – aus EHRs, PACS, Genomiksystemen und Labordatenbanken – durch die Phasen Aufnahme, Normalisierung, Feature Engineering, Modelltraining, Inferenz und Archivierung führen, damit KI-Modelle mit klinischen Daten trainiert, validiert und eingesetzt werden können. Welche Speicheranforderungen haben klinische KI-Pipelines? Die Anforderungen unterscheiden sich je nach Phase stark. Aktive Trainingsläufe brauchen Speicher auf NVMe-Ebene mit GPU-Direct-Zugriff und Latenzen unter einer Millisekunde. Normalisierte Feature Stores und Checkpoints brauchen warmen Speicher mit hoher Bandbreite. Langzeitarchive für die Aufbewahrung nach HIPAA oder GxP brauchen kostengünstigen, WORM-fähigen Objektspeicher. Eine Speicherarchitektur mit nur einer Temperatur kann nicht alle Phasen effizient bedienen – mehrstufiger Speicher mit automatisierten Lebenszyklusrichtlinien ist der Standardansatz. Wie gilt HIPAA-Compliance für KI-Pipelines mit klinischen Daten? HIPAA verlangt, dass jede Pipeline, die geschützte Gesundheitsinformationen verarbeitet, eine dokumentierte De-Identifizierung, Audit-Trails für jeden Datenzugriff und jede Transformation, rollenbasierte Zugriffskontrollen und die Aufbewahrung von Compliance-Unterlagen für mindestens sechs Jahre umfasst. Die Speicherinfrastruktur muss unveränderliche Audit-Protokollierung, WORM-Object-Lock für die Aufbewahrung sowie Verschlüsselung ruhender und übertragener Daten unterstützen. De-identifizierte Trainingsdaten und identifizierte Quelldatensätze müssen unter getrennten Zugriffskontrollen gespeichert werden. Welche Rolle spielt mehrstufiger Speicher in der klinischen KI-Infrastruktur? Mehrstufiger Speicher ordnet Daten je nach Zugriffsmuster der passenden Leistungs- und Kostenebene zu. Heißer NVMe-Speicher bedient aktive Trainings- und Inferenz-Workloads, bei denen die Latenz zählt. Warme HDD-basierte Ebenen halten Feature Stores, Modellartefakte und Checkpoints, auf die häufig, aber nicht in Echtzeit zugegriffen wird. Kalte oder bandnahe Ebenen halten Langzeitarchive und Audit-Logs, die womöglich nur bei Compliance-Audits gelesen werden. Ohne mehrstufigen Speicher geben klinische KI-Teams entweder zu viel für teuren Flash für kalte Archive aus oder bremsen Trainingsjobs auf langsamen Festplatten aus. Siehe Hot Storage vs. Cold Storage für eine vollständige Übersicht. Weiterführende Lektüre HIPAA-konformer Speicher Konformer S3-Speicher für regulierte Daten (auf Englisch) Retrieval-Augmented Generation und Speicher für KI Mehrstufiger Speicher für KI: skalierbare Leistung und Kostenkontrolle KI-Datenspeicher ohne Hindernisse Richtlinie zur Datenaufbewahrung: Definition, Beispiele und Best Practices Ist Langlebigkeit für Gesundheitsdaten wichtig? (auf Englisch)
