Die digitale Transformation des Gesundheitswesens basiert wesentlich auf der Fähigkeit, heterogene und wachsende Datenmengen in klinisch nutzbare Information zu überführen. Informatik und Medizin treten hierbei in eine wechselseitige Abhängigkeit: Während die Informatik Methoden für Speicherung, Verarbeitung und Analyse bereitstellt, definiert die Medizin die Anforderungen an Patientensicherheit, klinische Validität und regulatorische Nachvollziehbarkeit.

Monolithische Krankenhausinformationssysteme (KIS), lange Zeit die zentralen Plattformen, erreichen in diesem Spannungsfeld ihre architektonischen Grenzen. Die Konsequenz war die Entstehung von hybriden Systemlandschaften: Um die Defizite des KIS zu kompensieren, wurden hochspezialisierte Subsysteme wie Patientendatenmanagementsysteme (PDMS) für die Intensivmedizin angeknüpft. Diese Kombination aus Monolith und Spezial-Tool ist jedoch kein strategisches Design, sondern ein historisch gewachsener Kompromiss. Er manifestiert sich im klinischen Alltag, wenn ein Arzt für eine einzige Entscheidung Daten aus dem KIS, dem PDMS und einem Labor-System mühsam manuell zusammentragen muss. Er führt zu aufwändigen Schnittstellen, Datensilos und hohen Integrationskosten (Benson & Grieve, 2016).

Dieser Beitrag postuliert daher einen Paradigmenwechsel hin zu einer zweckgebundenen, polyglotten Persistenzarchitektur. Statt auf teure und starre Insellösungen zu setzen, ermöglichen moderne Standards wie HL7 FHIR heute eine strategische Integration, die diesen Namen auch verdient. Ziel ist eine strategische Blaupause, in der technische Systemarchitekturen nicht Selbstzweck sind, sondern als notwendige Grundlage für Patientensicherheit, Versorgungsqualität und Innovation verstanden werden.

Visualisierung zielspezifischer Datenarchitektur als Grundvoraussetzung effizienter Systeme. *(Erstellt mit* *Google Gemini, 08/2025)*

Vier Domänen, vier Architekturen

Jede Domäne klinischer Datenverarbeitung folgt eigenen physikalischen und prozessualen Gesetzen. Daraus ergeben sich differenzierte Architekturanforderungen, die nach maßgeschneiderten technologischen Antworten verlangen.

Kompromisslose Wahrheit (Transaktionale Systeme wie KIS/EPA)

In dieser Domäne geht es um die juristisch und medizinisch verbindliche Dokumentation – das "System of Record". Ob eine Diagnose dokumentiert, eine Leistung verbucht oder ein Arztbrief erstellt wird, die oberste Priorität ist kompromisslose Zuverlässigkeit. Die Architektur muss daher Konsistenz und Integrität durch ACID-Konformität garantieren. Transaktionen müssen vollständig (Atomicity), regelkonform (Consistency), ungestört (Isolation) und dauerhaft (Durability) sein. Gepaart mit lückenloser Revisionssicherheit bildet ein hochgradig strukturiertes, relationales Datenmodell die Grundlage. Ähnlich einem Bibliothekskatalog wird jede Information nur einmal gespeichert und über eindeutige IDs verknüpft, um Redundanz und Fehler zu vermeiden. Technologisch ist dies die Domäne klassischer relationaler Datenbanken (RDBMS) wie PostgreSQL, Oracle oder MS SQL Server, deren eingebaute Transaktionssicherheit hier unverzichtbar ist.

Wird im KIS der Tod oder die Verlegung eines Patienten dokumentiert, während Geräte weiter Daten erfassen (z. B. ECMO), entsteht ein inkonsistenter Zustand.
- Harte Regeln („Tod/Verlegung überschreibt alle Zustände“) vermeiden Widersprüche, riskieren aber Informationsverlust.
- Flexible Ereignisarchitekturen erhalten Nachlaufdaten, erhöhen jedoch die Interpretationskomplexität.
Fazit: ACID im KIS genügt nicht systemübergreifend – nötig sind Event-basiertes Messaging (z. B. HL7 FHIR Subscriptions) und klinisch definierte Priorisierungsregeln (Hollnagel, Braithwaite, & Wears, 2013).

Physiologische Realität in Echtzeit (Monitoring und Streaming)

Das genaue Gegenteil der bedächtigen KIS-Welt ist das Echtzeit-Monitoring von Vitalparametern z.B. in Dashboards. Hier geht es um die sofortige Abbildung der physiologischen Realität, was eine Latenz im Millisekundenbereich erfordert. Das System muss einen extrem hohen Schreibdurchsatz bewältigen – Tausende Messwerte pro Sekunde, die als geordnete Zeitreihen erfasst werden. Die Architektur ist daher stark schreiblastig und optimiert für Zeitfenster-Abfragen wie: „Gib mir jeden Herzschlag von Patient X aus den letzten 30 Sekunden“. Anstelle harter Konsistenz genügt hier oft "Eventual Consistency", solange Verfügbarkeit und die korrekte Reihenfolge der Events gewährleistet sind. Technologisch wird dies durch Paradigmen wie Event-Sourcing und spezialisierte Zeitreihen-Datenbanken (z.B. InfluxDB, TimescaleDB) realisiert, die relationalen Systemen für diesen Zweck um Größenordnungen überlegen sind.

In-Workflow Clinical Decision Support (CDS)

CDS-Systeme unterstützen Ärzte aktiv während der Behandlung, indem sie beispielsweise bei der Medikamentenverordnung patientenindividuelle Daten prüfen und vor Wechselwirkungen warnen. Dies erfordert deterministische Antwortzeiten im Sub-Sekunden-Bereich, um den klinischen Workflow nicht zu unterbrechen. Der Workload ist extrem leselastig, mit Fokus auf schnelle Lookups, die oft komplexe, graphenbasierte Beziehungen (z.B. Wirkstoff-Interaktionen) abfragen müssen. Das Datenmodell ist häufig semantisch und versteht medizinische Ontologien wie SNOMED CT, sodass es weiß, dass „Herzinfarkt“ und „Myokardinfarkt“ Synonyme sind (SNOMED CT; Lee, de Keizer, Lau, & Cornet, 2014). Um die geforderte Geschwindigkeit zu erreichen, setzt man auf Caching-Strategien. Benötigte Daten werden aus dem KIS in einen optimierten Zwischenspeicher kopiert und stehen dort als vorgefertigte „Zusammenfassung“ bereit. Dafür eignen sich In-Memory-Datenbanken wie Redis oder Graph-Datenbanken wie Neo4j.

Sekundärnutzung von Gesundheitsdaten (Forschung und Analyse)

Für Forschungszwecke oder das Training von KI-Modellen werden riesige, anonymisierte Datenmengen aggregiert analysiert. Anders als in den anderen Domänen sind hier Abfragen, die Minuten dauern, akzeptabel, solange das System riesige Datenmengen (Terabytes) effizient durchsuchen kann. Der Workload ist analytisch (OLAP): schreibarm, aber mit Scans über große Datenmengen, um Fragen wie „Wie hoch war die durchschnittliche Verweildauer aller Diabetes-Patienten im letzten Jahr?“ zu beantworten. Die Daten werden dafür in einem denormalisierten, spaltenorientierten Format (Columnar Storage) gespeichert, was Aggregationen wie die Berechnung von Durchschnittswerten massiv beschleunigt. ETL/ELT-Pipelines extrahieren die Daten aus den operativen Systemen und laden sie in Cloud-basierte Data Warehouses (z.B. Google BigQuery) oder Big-Data-Frameworks, die für massiv-parallele Verarbeitung ausgelegt sind.

Synthese – Interoperabilität als Schlüssel

Diese Domänen existieren nicht isoliert. Eine zukunftsfähige IT-Strategie zeichnet sich dadurch aus, dass sie diese spezialisierten Systeme intelligent integriert. Das monolithische KIS transformiert sich zu einem Ökosystem interoperabler Services, die über standardisierte, ereignisgesteuerte Schnittstellen kommunizieren. Entscheidend ist hier der HL7 FHIR-Standard, der als lingua franca fungiert: Eine neu dokumentierte Diagnose im KIS aktualisiert gleichzeitig CDS und Forschungsarchive nahezu in Echtzeit.

Schlussfolgerung

Die Abkehr vom „One-Size-Fits-All“-Ansatz hin zu zweckgebundenen Architekturen ist keine rein technische Frage. Sie muss von einer klaren, medizinisch-informatischen Zieldefinition ausgehen: Welche klinische Fragestellung soll unterstützt werden? Welche Datenqualität, Sicherheit und Interoperabilität sind dafür unverzichtbar? Nur so kann eine adäquate Architektur abgeleitet werden. Informatik liefert die Methoden, Medizin die Anforderungen – erst in ihrer Kopplung entstehen Systeme, die Patientensicherheit, Effizienz und Innovation gleichermaßen fördern. So verstanden ist spezialisierte, zielorientierte Architektur nicht Selbstzweck, sondern der Wegbereiter für KI-gestützte Diagnostik, prädiktive Modelle und personalisierte Medizin.

HL7 International. (2021). FHIR® (im Internet)
International Health Terminology Standards Development Organisation. (2024). SNOMED CT. Retrieved from https://www.snomed.org/
Lee, D., de Keizer, N., Lau, F., & Cornet, R. (2014). Use of SNOMED CT in clinical health information systems: A review. Journal of the American Medical Informatics Association, 21(e1), e11–e19. https://doi.org/10.1136/amiajnl-2013-001636
Raghupathi, W., & Raghupathi, V. (2014). Big data analytics in healthcare: Promise and potential. Health Information Science and Systems, 2(1), 3. https://doi.org/10.1186/2047-2501-2-3
Benson, T., & Grieve, G. (2016). Principles of health interoperability: HL7 and SNOMED (3rd ed.). Springer. https://doi.org/10.1007/978-3-319-30370-3
Hollnagel, E., Braithwaite, J., & Wears, R. L. (2013). Resilient health care. Ashgate.
SNOMED CT (im Internet)

Datenarchitektur in der Medizin – One Size Fits None