5 Die Architektur für Patientendaten mit KI ist der Teil eines klinischen Systems, der entscheidet, ob die Akte eines Patienten sicher und sinnvoll in einen KI-Workload eingespeist werden kann – und ob sie anschließend für den Rest des Lebens dieses Patienten prüfbar aufbewahrt wird. Sie liegt zwischen der elektronischen Patientenakte (EHR), dem Bildarchiv, dem Genomikspeicher und dem Modell. Funktioniert sie, erhalten Ärztinnen und Ärzte eine Entscheidungsunterstützung, die den ganzen Patienten abbildet. Funktioniert sie nicht, gerät das KI-Programm bei Einwilligung, Datenresidenz oder De-Identifizierung ins Stocken, lange bevor ein Modell live geht. Dieser Leitfaden richtet sich an CIOs, CMIOs und Infrastrukturverantwortliche, die bei der Einführung klinischer KI Entscheidungen zur Architektur der Patientendaten treffen. Er behandelt EHR-Integration, Längsschnittakten, die Durchsetzung von Einwilligungen, De-Identifizierung nach HIPAA-Niveau und das Speicherfundament, das geschützte Gesundheitsinformationen über Jahrzehnte unveränderlich und souverän vorhalten muss. Was ist eine Architektur für Patientendaten mit KI? Eine Architektur für Patientendaten mit KI ist die Gesamtheit aus Diensten, Verträgen und Speicherebenen, die die klinische Akte eines einzelnen Patienten in eine Darstellung verwandelt, mit der ein KI-Modell trainiert, die es abfragen und die es aufbewahren kann – ohne die Eigenschaften zu Datenschutz, Einwilligung, Residenz und Nachvollziehbarkeit zu verlieren, die das Vorhalten der Akte rechtmäßig machen. Sie ist enger gefasst als ein Überblick über die KI-Architektur im Gesundheitswesen (auf Englisch), der den gesamten Stack von den Quellen bis zur Inferenz umfasst, und enger als ein medizinisches KI-Datensystem (auf Englisch), das die betrieblichen Komponenten beschreibt. Die Architektur für Patientendaten ist die Sicht mit der Patientenakte im Mittelpunkt: wie die Längsschnittakte zusammengesetzt wird, wie die Einwilligung mit ihr wandert, wie Kennungen maskiert oder wiederhergestellt werden und wo die Akte während ihrer jahrzehntelangen Aufbewahrungsfrist physisch liegt. Drei Eigenschaften kennzeichnen eine funktionierende Datenarchitektur für Patientendaten: Die Akte ist longitudinal, nicht an einzelne Sitzungen gebunden. Jeder Patient hat eine Akte, die Behandlungsfälle, Modalitäten und Zeiträume umfasst, mit stabiler Identität über alle Quellsysteme hinweg. Einwilligung und Klassifizierung wandern mit den Daten. Jede Akte, jede Ableitung und jedes Modellartefakt trägt den Einwilligungsumfang und die Datenklassifizierung, die ihre Nutzung regeln. Der Identifikationsstatus ist bei jedem Lesevorgang explizit. Ob ein Workload identifizierte geschützte Gesundheitsinformationen (PHI), eine pseudonymisierte Akte oder einen de-identifizierten Datensatz liest, ist eine Eigenschaft der Anfrage und keine ungeschriebene Konvention. Warum Patientendaten der schwierige Teil klinischer KI sind Die meisten klinischen KI-Projekte stellen irgendwann um den zweiten Sprint herum fest, dass das Modell der einfache Teil ist. Die Patientendaten sind es, die den Zeitplan aufzehren. Dafür gibt es vier Gründe, die sich in Klinikverbünden, Netzwerken aus Kostenträgern und Leistungserbringern sowie in Forschungsumgebungen der Pharmaindustrie zeigen. Die Identität der Patienten ist über Quellsysteme verstreut. Ein einzelner Patient kann im EHR, im Radiologie-PACS, im Laborsystem, im Genomsequenzierer und auf der Wearable-Plattform unter unterschiedlichen Kennungen existieren. Diese Identitäten zusammenzuführen, ist ein Stammdatenproblem, das der KI-Workload erbt – und kein Problem, das er beim Training lösen kann. Die Längsschnittsicht verleiht KI ihren klinischen Wert. Ein Modell, das nur einen Behandlungsfall sieht – die Bildgebungsstudie, das Laborpanel, den Entlassungsbericht –, verpasst den tatsächlichen Verlauf des Patienten. Nützliche klinische KI braucht fast immer die Längsschnittakte: frühere Erkrankungen, frühere Medikamente, frühere Bildgebung, frühere Laborwerte, frühere Ergebnisse. Diese Sicht zusammenzusetzen, ist ein Architekturproblem. Einwilligungen sind dynamisch, granular und widerruflich. Ein Patient willigt womöglich in die Forschungsnutzung seiner de-identifizierten Akte ein, aber nicht in kommerzielles KI-Training. Er kann seine Einwilligung widerrufen. Er willigt vielleicht in eine bestimmte Studie ein, aber nicht in das allgemeine Forschungsprogramm der Einrichtung. Die Architektur muss das pro Akte bei jedem Lesezugriff durchsetzen. Aufbewahrungsfristen werden in Jahrzehnten gemessen. Für PHI gilt nach HIPAA eine regulatorische Mindestfrist von sechs Jahren, doch in der klinischen Praxis werden Akten häufig für die Lebensdauer des Patienten zuzüglich gesetzlicher Nachfristen aufbewahrt. Genomdaten und Akten aus der Pädiatrie können längere Pflichten mit sich bringen. Das Fundament, das die Patientenakte hält, überdauert die meisten Systeme, die darauf geschrieben haben. Die zentralen Ebenen einer Architektur für Patientendaten mit KI Die folgende Architektur zeigt die Sicht mit der Patientenakte im Mittelpunkt. Andere Leitfäden behandeln die Phasen der klinischen Datenpipeline und die übergeordneten Systemkomponenten; hier geht es darum, was speziell mit der Akte des Patienten geschieht. 1. EHR-Integration und Anbindung der Quellen Ausgangspunkt ist der strukturierte Zugriff auf die elektronische Patientenakte. In aktuellen Bereitstellungen ist der Vertrag FHIR – Patient-, Encounter-, Condition-, Medication- und Observation-Ressourcen –, meist bereitgestellt von Epic, Cerner/Oracle Health, Meditech oder einem herstellerneutralen FHIR-Gateway vor mehreren Backends. Bilddaten werden über DICOMweb an ein PACS oder ein herstellerneutrales Archiv angebunden. Labordaten kommen über HL7-v2-Feeds, normalisiert auf LOINC. Genomdaten landen als Objekte aus Sequenzierungspipelines. Auf dieser Ebene zählen zwei Designentscheidungen. Erstens sollten Rohextrakte aus jeder Quelle als unveränderliche Objekte im Speicherfundament landen, bevor eine Transformation läuft, damit die maßgebliche Akte unabhängig von nachgelagerten Pipelines prüfbar ist. Zweitens sollte der Identitätsabgleich – das Zusammenführen der Patientenkennungen über Quellen hinweg – ein Dienst der Architektur sein und kein Problem, das jeder nachgelagerte Nutzer neu entdeckt. 2. Master Patient Index und Aufbau der Längsschnittakte Hinter der EHR-Integration steht der Master Patient Index – der Dienst, der mehrere Quellkennungen in eine stabile Patientenidentität überführt. Die Längsschnittakte ist die zusammengesetzte Sicht: jeder Behandlungsfall, jede Beobachtung, jedes Bild und jedes Laborergebnis, das dieser Patientenidentität zugeordnet ist, zeitlich geordnet, auf eine gemeinsame Terminologie normalisiert (SNOMED, ICD-10, LOINC, RxNorm) und als versionierte Objektmenge gespeichert. Für KI-Workloads ist die Längsschnittakte die Einheit des Feature Engineering. Ein klinisches Vorhersagemodell wird auf Kohorten von Längsschnittakten trainiert; ein klinischer Assistent mit Retrieval-Augmented Generation stützt seine Antworten zur Abfragezeit auf die relevante Längsschnittakte. Die Architektur muss diese Akte reproduzierbar, versionsstabil und bis zu ihren Quelldatensätzen rückverfolgbar machen. 3. Einwilligung und Klassifizierung Die Einwilligung ist eine Eigenschaft jedes Datensatzes in der Längsschnittsicht. Die Architektur muss den Umfang der Einwilligung erfassen (klinische Versorgung, Forschung, Qualitätsverbesserung, kommerzielles KI-Training, konkrete Studienkennungen), ihre zeitliche Gültigkeit und das Widerrufsrecht des Patienten. Die Klassifizierung – identifizierte PHI, Limited Data Set, pseudonymisiert, de-identifiziert nach Safe Harbor oder Expert Determination – ist eine parallele Eigenschaft, die regelt, welche Workloads die Akte lesen dürfen. Die Architekturentscheidung lautet hier, ob Einwilligung und Klassifizierung Sidecar-Dienste oder Eigenschaften des Speicherfundaments sind. Sidecar-Dienste driften auseinander, und ein abgedrifteter Einwilligungsdienst wird zu einem Audit-Befund. Klassifizierung und Durchsetzung von Richtlinien im Speicher überstehen Plattformwechsel. Das Design, das im großen Maßstab trägt, bettet Klassifizierungsmetadaten in den Objektdatensatz selbst ein und setzt sie auf der Zugriffsebene durch. 4. De-Identifizierung, Pseudonymisierung und der PHI-Tresor Identifizierte PHI sind die Klasse von Patientendaten, auf die Aufsichtsbehörden am empfindlichsten reagieren. Die De-Identifizierungsebene ist der Dienst, der identifizierte Akten in sicherere Darstellungen für die Nutzung durch KI umwandelt – De-Identifizierung nach Safe Harbor (Entfernung der 18 HIPAA-Identifikatoren), Expert Determination (statistisch nachgewiesenes geringes Re-Identifizierungsrisiko) oder Pseudonymisierung (Ersetzen von Kennungen durch stabile Token in einem Tresor). Eine funktionierende De-Identifizierungsarchitektur unterscheidet drei Zustände explizit. Identifizierte PHI unterliegen den strengsten Zugriffskontrollen und werden nur von Workloads gelesen, die eine Identifizierung rechtmäßig benötigen – klinische Versorgung, Meldung unerwünschter Ereignisse, Kontaktaufnahme zur Nachsorge. Pseudonymisierte Akten tragen stabile Token, die eine Längsschnittverknüpfung ohne Offenlegung der Identität ermöglichen; sie werden für die meisten Forschungs- und Qualitäts-Workflows genutzt. De-identifizierte Datensätze werden nach dokumentierter Methodik für umfassenderes KI-Training freigegeben und zusammen mit ihrer Transformationshistorie aufbewahrt. Die Dokumentation ist Teil der Architektur. Jede De-Identifizierung sollte einen Audit-Datensatz erzeugen, der Methode, Parameter, ausführende Instanz (Mensch oder Workload-Identität) und Zeitstempel nennt. Genau diesen Datensatz wird eine Prüfung durch das HHS Office for Civil Rights in zwei Jahren verlangen. Siehe HIPAA-konformer Speicher zu den Anforderungen an die Speicherebene, die das in der Praxis prüfbar machen. 5. Feature Engineering und modellseitiger Zugriff Auf der modellseitigen Zugriffsebene wird die Patientenakte zu Trainingsdaten, Embeddings oder Kontext für Retrieval-Augmented Generation. Feature-Engineering-Pipelines lesen normalisierte Längsschnittakten und erzeugen tabellarische Features, Text-Embeddings, Bildtensoren oder Graphdarstellungen. RAG-Workflows indizieren de-identifizierte Aktenabschnitte in Vektorspeichern. Inferenzendpunkte rufen zur Abfragezeit den relevanten Patientenkontext ab, wobei der Zugriff an die Identität der anfragenden Ärztin oder des anfragenden Arztes und an den Einwilligungsumfang des Patienten gebunden ist. Die Architekturregel lautet: Jeder Lesezugriff auf dieser Ebene ist identitätsgebunden und klassifizierungsbewusst. Ein Trainingsjob liest de-identifizierte Akten im Rahmen der Einwilligungsumfänge, für die er autorisiert ist. Ein Inferenzendpunkt, der eine Ärztin bedient, liest identifizierte PHI nur für deren eigene Patienten. Auf der Zugriffsebene werden die Versprechen der übrigen Architektur tatsächlich durchsetzbar. 6. Registry für Modellartefakte Nach dem EU AI Act und 21 CFR Part 11 sind Modellartefakte, die aus Patientendaten abgeleitet sind – Checkpoints, Embeddings, Evaluierungsdatensätze, Prompts –, selbst Teil des regulierten Datenbestands. Sie müssen mit derselben Unveränderlichkeit, Herkunftsnachverfolgung und Nachvollziehbarkeit aufbewahrt werden wie die Quelldatensätze, mit denen sie trainiert wurden. Die Artefakt-Registry ist die Ebene, die das leistet, und in gut konzipierten Architekturen liegt sie auf demselben Speicherfundament wie die Patientenakte – nicht in einer separaten Datenbank, die später abgeglichen werden muss. 7. Langzeitaufbewahrung und souveräne Kontrolle Die letzte Ebene ist die Aufbewahrungsebene über mehrere Jahrzehnte. Patientenakten, Bildgebungsstudien, Genomsequenzen, Audit-Trails und Modellartefakte bleiben für die Lebensdauer des Patienten zuzüglich gesetzlicher Nachfristen bestehen. Sie müssen unveränderlich, wiederherstellbar, an einen Speicherort gebunden und über Mediengenerationen hinweg prüfbar sein. Die Aufbewahrungsebene ist für den KI-Workload selten sichtbar – doch aus ihr liest letztlich jedes Audit und jede Anfrage zum Widerruf einer Einwilligung. Siehe Richtlinie zur Datenaufbewahrung: Definition, Beispiele und Best Practices und Ist Langlebigkeit für Gesundheitsdaten wichtig? (auf Englisch) zu Designmustern, die sich langfristig bewähren. Wie die Ebenen zusammenhängen Von oben nach unten gelesen sieht der Vertrag so aus: EHR-, PACS-, Labor- und Genomquellen schreiben Rohextrakte als unveränderliche Objekte. Der Master Patient Index verknüpft Kennungen über Quellen hinweg. Die Normalisierung setzt die Längsschnittakte zusammen, gespeichert als versionierte Objektmenge. Metadaten zu Einwilligung und Klassifizierung werden jedem Datensatz aufgeprägt. Die De-Identifizierungsebene erzeugt identifizierte, pseudonymisierte und de-identifizierte Zustände explizit, jeweils mit eigenem Zugriffsumfang. Feature Engineering, Training und Inferenz lesen über identitätsgebundenen, klassifizierungsbewussten Zugriff. Modellartefakte landen wieder im Speicherfundament, nach denselben Regeln wie die Quelle. Die Aufbewahrungsebene trägt alles über Jahrzehnte weiter, unter Vorgaben zu Residenz und Unveränderlichkeit. Hält dieser Vertrag, kann eine Einrichtung einen neuen klinischen KI-Workload hinzufügen – einen Sepsis-Prädiktor, einen Triage-Assistenten für die Radiologie, ein klinisches Chat-Frontend –, ohne die Patientendatenebene neu aufzubauen. Bricht er, handelt jeder neue Workload seine eigene Version von Einwilligung, De-Identifizierung und Audit aus, und die Architektur zerfällt in anwendungsspezifische Silos. Wie Scality ADI die Architektur für Patientendaten mit KI unterstützt Scality ADI (Autonomous Data Infrastructure) ist eine Dateninfrastruktur für KI in Unternehmen, Cyber-Resilienz und souveräne Kontrolle, die autonom und nachhaltig die passenden Speichermedien im Maßstab von mehreren Petabyte bis Exabyte zuordnet. Für eine Architektur für Patientendaten mit KI in einem klinischen System ist das das Fundament, auf dem die Architektur ruht. Konkret lässt sich Scality ADI so auf die Architektur für Patientendaten abbilden: Eine Plattform über vier Ebenen. GPU-direkter Flash mit S3 over RDMA für aktives Training und den KV-Cache der Inferenz, heißer QLC- und NL-SSD-Speicher für aktive Längsschnittakten und Embeddings, warmer HDD-Speicher für kuratierte Kohorten und aktuelle Bildgebung sowie kalte Band- oder Cloud-nahe Archivierung für die PHI-Aufbewahrung über mehrere Jahrzehnte. Die Patientenakte durchläuft diese Ebenen, ohne Identität, Klassifizierung oder Audit-Historie zu ändern. CORE5-Cyber-Resilienz für PHI. Unveränderlichkeit, Haltbarkeit durch Erasure Coding, Schutz der Metadaten, standortübergreifender Schutz und Durchsetzung von Richtlinien sind Eigenschaften der Plattform. Dadurch entstehen Nachweise für HIPAA, EU AI Act und 21 CFR Part 11 auf der Speicherebene, statt zum Zeitpunkt des Audits rekonstruiert werden zu müssen. Souveräne Kontrolle von Grund auf. Scality ADI läuft vollständig On-Premises oder in einer Private Cloud, die die Einrichtung kontrolliert. Patientendaten bleiben dort, wo es die Residenzvorgaben verlangen – im Kliniknetz, im Land, innerhalb der Grenzen des Business Associate Agreement (BAA) –, ohne von der Auftragsverarbeitungsvereinbarung eines Hyperscalers abzuhängen. Autonomer Betrieb innerhalb definierter Richtlinien. Guardian liefert über Agenten Erkenntnisse und Empfehlungen zu Tier-Migration, Selbstheilung, Erweiterung und Validierung innerhalb kundenseitig definierter Richtlinien. Menschen genehmigen wesentliche Änderungen. Der Audit-Trail jeder betrieblichen Aktion wird zusammen mit den Patientendaten aufbewahrt, die sie betroffen hat. S3-nativ über den gesamten Lebenszyklus. Dasselbe Protokoll bedient einen Trainingslauf, der de-identifizierte Längsschnittakten liest, einen Inferenzendpunkt, der den Kontext eines Patienten abruft, einen Backup-Job, der in ein unveränderliches Archiv schreibt, und eine PHI-Aufbewahrungsebene auf Band für 25 Jahre. Scality ADI ist kein schnellerer Objektspeicher. Es ist ein neues Betriebsmodell für die Dateninfrastruktur von Unternehmen im KI-Zeitalter – und für ein klinisches System ist es die Ebene, auf der identifizierte PHI, pseudonymisierte Forschungsakten, de-identifizierte Trainingsdatensätze und jahrzehntelange Aufbewahrungsarchive einen gemeinsamen Satz von Kontrollen teilen statt fünf voneinander getrennter. Die übergreifenden Muster dahinter beschreiben die Beiträge Mehrstufiger Speicher für KI und Lösungen für Datensouveränität ausführlicher. Häufig gestellte Fragen Was ist eine Architektur für Patientendaten mit KI – in einem Satz? Es ist das Design mit der Patientenakte im Mittelpunkt – EHR-Integration, Längsschnittakten, Einwilligung, Klassifizierung, De-Identifizierung, modellseitiger Zugriff und jahrzehntelange Aufbewahrung –, das eine klinische Akte in etwas verwandelt, das ein KI-Workload nutzen kann, ohne Datenschutz, Nachvollziehbarkeit oder Residenz zu verletzen. Worin unterscheidet sie sich von einer klinischen Datenpipeline? Die Pipeline-Sicht beschreibt die Phasen, die Daten durchlaufen – Aufnahme, Normalisierung, Training, Inferenz, Aufbewahrung. Die Architektur für Patientendaten beschreibt, was mit der Akte des Patienten selbst geschieht – Identitätsverknüpfung, Aufbau der Längsschnittakte, Einwilligung, De-Identifizierung und Aufbewahrung. Beide Sichten werden gebraucht; sie beantworten unterschiedliche Fragen. Wo hat die De-Identifizierung nach HIPAA ihren Platz? De-Identifizierung ist eine explizite Transformation innerhalb der Architektur, keine Eigenschaft der Speicherebene. Identifizierte PHI, pseudonymisierte Akten und de-identifizierte Datensätze sind drei getrennte Zustände; jeder unterliegt einem eigenen Zugriffsumfang, und der Übergang zwischen den Zuständen ist ein dokumentiertes, prüfbares Ereignis. Der Speicher hält alle drei Zustände und setzt die Zugriffsumfänge beim Lesen durch. Muss die Einwilligung wirklich mit der Akte wandern? Ja. Ein Einwilligungsdienst, der getrennt von der Akte existiert, driftet ab, und diese Abweichung wird zu einem Audit-Befund. Metadaten zu Einwilligung und Klassifizierung in den Objektdatensatz einzubetten – und sie auf der Zugriffsebene durchzusetzen – ist das Design, das Prüfungen durch das HHS Office for Civil Rights und Audits nach dem EU AI Act standhält. Welche Rolle spielt Scality ADI dabei? Scality ADI ist das Speicherfundament, auf dem die Architektur für Patientendaten ruht – eine Plattform über vier Medienebenen mit integrierter Unveränderlichkeit, Herkunftsnachverfolgung, Residenz und autonomem Betrieb. EHR-Rohextrakte, der Speicher für Längsschnittakten, de-identifizierte Trainingskorpora, Modellartefakte und das PHI-Archiv über mehrere Jahrzehnte liegen alle auf demselben Fundament unter einem Betriebsmodell. Fazit Die Architektur für Patientendaten mit KI in klinischen Systemen wird nicht dadurch definiert, welches Modell obenauf sitzt oder welche Datenbank das EHR hält. Sie wird dadurch definiert, was mit der Akte des Patienten über Jahrzehnte geschieht – wie Identitäten abgeglichen werden, wie die Einwilligung mitwandert, wie der Identifikationsstatus durchgesetzt wird und welches Fundament die Akte über Mediengenerationen und Audit-Zyklen hinweg hält. Die Einrichtungen, die das richtig machen, gestalten zuerst die Ebene für Einwilligung, Klassifizierung und Speicher und lassen dann jeden neuen klinischen KI-Workload an diesen Vertrag andocken. Der Patient überdauert jedes einzelne System der Architektur. Die Speicherebene überdauert die meisten davon. Diese Designentscheidung sollte richtig getroffen sein, bevor das erste Modell in Produktion geht. Weiterführende Lektüre: Überblick über die KI-Architektur im Gesundheitswesen für CIOs (auf Englisch) Medizinische KI-Datensysteme: Design und zentrale Komponenten (auf Englisch) Klinische KI-Datenpipelines: ein praktischer Architekturleitfaden HIPAA-konformer Speicher für Gesundheitsdaten Richtlinie zur Datenaufbewahrung: Definition, Beispiele und Best Practices Mehrstufiger Speicher für KI: skalierbare Leistung und Kostenkontrolle Lösungen für Datensouveränität Was unveränderlicher Speicher ist und wie er funktioniert Ist Langlebigkeit für Gesundheitsdaten wichtig? (auf Englisch)
