Kontext aus Vorbefunden: Wo IT-Architektur über Klinik-Qualität entscheidet

Auf dem Schreibtisch der Aufnahme-Ärzt:in liegt am Montagvormittag eine Mappe mit Vorbefunden — drei Berichte als ausgedruckte Briefe, ein Operations-Bericht als gescanntes Portable-Document-Format (PDF), ein Bildgebungs-Eintrag, der per Kommunikation im Medizinwesen (KIM) gestern Nachmittag eingegangen ist, ein älterer Fax-Bericht aus der Hausarzt-Praxis. In der elektronischen Patientenakte (ePA) der Patientin liegt zusätzlich ein Medikationsplan, ein Laborbefund und ein eingebettetes Dokument der Akut-Klinik. Die Vorbefunde sind alle da. Was die Aufnahme-Ärzt:in in der nächsten Stunde tun wird — Befunde lesen, Datums-Reihenfolge sortieren, Indikations-Anker rekonstruieren, in die eigene Akte abtippen — ist eine Form von Aufnahme-Arbeit, die in fast jeder deutschen Klinik wiederkehrt. Die Frage, warum diese Stunde überhaupt anfällt, hat keine ärztliche Antwort. Sie hat vier IT-Architektur-Antworten.

Die zugrunde liegenden Standards sind seit Jahren beschrieben. HL7 Fast Healthcare Interoperability Resources (FHIR) Release 4 definiert rund 140 ressourcen-orientierte Datenstrukturen — Patient, Observation, Condition, MedicationRequest, DocumentReference, Bundle, Provenance — mit einer Representational-State-Transfer-Schicht und JavaScript-Object-Notation- oder Extensible-Markup-Language-Serialisierung; die Provenance-Ressource führt für jede klinische Aussage einen maschinen-lesbaren Quell-Verweis. Die Profile-Familie der Integrating-the-Healthcare-Enterprise-Initiative (IHE) zur Patient Care Coordination — Cross-Enterprise Document Sharing (XDS), Mobile Access to Health Documents (MHD), Basic Patient Privacy Consents (BPPC), Cross-Community Document Reliable Interchange (XCDR) — beschreibt Dokument-Sharing-Pattern, die eine Klinik nicht selbst neu entwerfen muss. Der openEHR-Referenz-Ansatz trennt Referenz-Modell und klinische Archetypen und ist in europäischen E-Health-Programmen — Großbritannien, Schweden, Norwegen, Slowenien — produktiv im Einsatz. Diese Standards sind keine Pflicht; sie sind die Vokabel, mit der die Architektur-Entscheidungen einer Klinik formulierbar werden.

Die deutsche Realität liegt anderswo. Die Bitkom-Krankenhausstudie 2024 — eine Selbst-Auskunft von rund 200 Geschäftsführer:innen und IT-Leitungen — verzeichnet, dass etwa 90 Prozent die Interoperabilität der eigenen Klinik-IT-Systeme als „eher schlecht“ oder „sehr schlecht“ bewerten und dass etwa 60 Prozent weiterhin Health Level Seven Version 2.x als primären Schnittstellen-Standard nutzen. FHIR ist in der Adoption auf ePA und ausgewählte Medizinische Informationsobjekte (MIO) des Bundesinstituts für Arzneimittel und Medizinprodukte (BfArM) konzentriert; die Mehrheit der Häuser plant in den nächsten fünf Jahren keine FHIR-Vollumstellung. Die Befragung ist branchen-finanziert und arbeitet mit einer geneigten Stichprobe; die strukturelle Beobachtung — Vorbefunde landen mehrheitlich als Anhänge in einer dokumenten-orientierten Architektur — ist trotzdem konvergent mit Bundesgesundheitsblatt-Beiträgen 2020 bis 2025 und mit der Diskussion zum Krankenhauszukunftsgesetz. Die Ausgangslage einer typischen Aufnahme-Ärzt:in ist nicht, dass FHIR fehlt. Die Ausgangslage ist, dass die eigene Klinik-IT-Architektur Vorbefund-Eingänge als binäre Dokumente einsortiert und nicht als strukturierte Datenpunkte modelliert.

Vier IT-Architektur-Entscheidungen, die zusammenspielen

Erstens: das Dokumenten-Modell. Eingehende Vorbefund-Inhalte werden in der Klinik-IT-Architektur entweder als FHIR-Bundle mit referenzierten Sub-Ressourcen abgelegt — die Composition-Ressource bindet eine ärztliche Aussage, die Sub-Ressourcen tragen Diagnose, Befund, Medikamenten-Liste, Operations-Detail je strukturiert — oder als binärer Anhang an ein Dokumenten-Verweis-Objekt gehängt, der nur für menschliche Lese-Augen erschließbar bleibt. Die FHIR-DocumentReference-Ressource bindet beides: einen Verweis auf das menschen-lesbare Dokument und einen Verweis auf ein Composition-Bundle. Wer beides bindet, hält die Architektur offen für strukturierte Auswertbarkeit; wer nur ersteres pflegt, hat eine Anhang-Architektur, in der jedes spätere Lesen erneut menschlich erfolgt. Die Entscheidung ist binär in der Wirkung — sie sitzt in der KIS-Schnittstellen-Konfiguration und im Schnittstellen-Aufsatz zwischen Dokument-Empfänger und Akten-Persistenz.

Zweitens: die Provenance-Ressource. Pro klinischer Aussage trägt eine ressourcen-orientierte Architektur einen maschinen-lesbaren Quell-Verweis — recorded, agent, entity, target. Die Information „diese Diagnose stammt aus dem Akut-Bericht der einweisenden Klinik vom 12.04.2026“ liegt dann nicht im Freitext irgendwo im Body, sondern als adressierbares Feld am Datenpunkt. Architekturen ohne Provenance führen die Quelle bestenfalls am Dokument als Ganzes mit; die Aussage „dieser Datenpunkt stammt aus jenem Dokument“ ist dann eine Suche im PDF-Volltext, nicht eine Filter-Operation auf der Datenbank. Span-Attribution für KI-Auswertungen, retrospektive Audit-Pfade und Widerspruchs-Detektion zwischen zwei Vorbefund-Quellen werden ohne Provenance-Schicht nicht trivial; sie werden ad hoc rekonstruiert. Die Entscheidung sitzt in der Datenmodell-Wahl der primären Akte und in der Schnittstellen-Konfiguration der eingehenden Dokument-Verarbeitung.

Drittens: das Document-Sharing-Pattern. Wenn eine Klinik Dokumente von und zu anderen Leistungs-Erbringern austauscht, folgt das entweder einem etablierten IHE-Profil — XDS für Dokument-Repository und -Registry, MHD als FHIR-basierte Variante für mobile und moderne Klienten, BPPC für die Einwilligungs-Modelle pro Dokument, XCDR für die zuverlässige Übertragung über Versorgungs-Netzwerke — oder einer anbieter-eigenen Kopier-Logik, die jede Klinik-zu-Klinik-Strecke neu erfindet. IHE-Profile sind nicht verbindlich; sie sind komponierbar — wer XDS und MHD und BPPC zusammen einführt, hat ein Pattern, das mit jedem anderen XDS-konformen Akteur aus dem Stand interoperabel ist. Wer eine eigene Logik gebaut hat, hat eine Strecke pro Partner und einen Vermehrungs-Punkt für jede neue Anbindung. Die Entscheidung sitzt in der Schnittstellen-Engine und im Beschaffungs-Lastenheft des Klinik-Informations-Systems (KIS).

Viertens: die Persistenz-Schicht. Vorbefund-Daten werden in der primären Akte entweder als ressourcen-orientierte Datenpunkte modelliert — jede Aussage als adressierbares Feld in der Patient-Akte mit Bezug auf ihre Composition und ihre Provenance — oder als Dokument-Stapel in einem Archiv-System geparkt, der von der primären Akte aus nur über einen Anhang-Verweis erreichbar bleibt. openEHR und FHIR teilen den ersten Weg, mit unterschiedlicher Modellierungs-Ästhetik; die zweite Form ist in deutschen Häusern überwiegend, weil das Archiv-System historisch ein eigenes Subsystem mit eigener Identifier-Welt war. Die Entscheidung ist die teuerste der vier — sie reicht in die Datenbank-Architektur des KIS und in die Migrations-Frage der bestehenden Akten-Bestände hinein. Wer die Persistenz-Frage strukturell trifft, hat eine andere Klinik-Akte als wer sie aus dem Archiv-Subsystem heraus delegiert.

Wo die vier Entscheidungen kompoundieren

Die vier Entscheidungen sind unabhängig voneinander, aber sie multiplizieren sich in der Wirkung. Eine Klinik mit FHIR-Bundle als Dokumenten-Modell, aber ohne Provenance-Schicht, hat strukturierte Daten ohne Quell-Anker — KI-Auswertungen können laufen, ihre Aussagen sind aber nicht audit-fest. Eine Klinik mit Provenance-Schicht, aber ohne IHE-Sharing-Pattern, kann jede Übergabe sauber attribuieren — die Übergabe-Strecken bleiben aber bilateral und brechen bei jedem neuen Partner. Eine Klinik mit IHE-Sharing-Pattern, aber dokument-orientierter Persistenz, kann zuverlässig austauschen — und legt das Ergebnis in einem Archiv-System ab, das die Daten der primären Akte nicht zur Verfügung stellt. Erst wenn alle vier Entscheidungen ressourcen-orientiert getroffen sind, entsteht die Architektur, in der ein eingehender Vorbefund als Datenquelle ankommt — strukturierter Datenpunkt mit Quelle, austauschbar nach Standard, abrufbar in der primären Akte. Die Folge-Frage „welche KI-Komponente kann auf welche Vorbefund-Information zugreifen“ ist in der Anhang-Architektur eine Volltext-Suche im PDF; in der ressourcen-orientierten Architektur ist sie eine Filter-Operation mit Provenance-Pfad.

Die klinische Folgefrage gehört in die ärztliche Begründung. Die Bundesärztekammer (BÄK) hat in mehreren Stellungnahmen 2023 bis 2025 darauf hingewiesen, dass die strukturierte Übergabe von Vorbefunden eine zentrale Voraussetzung der Versorgungs-Qualität ist und dass die ePA-Befüllung allein nicht ausreicht — entscheidend sei die Lesbarkeit und Kontextualisierbarkeit in der aufnehmenden Klinik. Diese Aussage liest sich aus der Tribüne als Versorgungs-Mahnung. Aus der Klinik-IT-Architektur gelesen, benennt sie eine Stellschraube — Lesbarkeit und Kontextualisierbarkeit sind nicht Eigenschaften des Dokuments, sondern Eigenschaften der aufnehmenden Architektur. Eine Aufnahme-Ärzt:in, die in einer ressourcen-orientierten Akte mit Provenance-Schicht arbeitet, sieht die Vorbefund-Daten als adressierbare Datenpunkte; eine, die in einer Anhang-Architektur arbeitet, sieht denselben Inhalt nur, wenn sie ihn am Aufnahmetag öffnet, liest, abtippt. Die ärztliche Sorgfalt unterscheidet sich nicht; die Architektur unterscheidet sich. Was der Klinik-Alltag als ärztliche Aufnahme-Stunde sieht, ist die ökonomische Folge einer IT-Architektur-Wahl, die in der KIS-Beschaffung vor Jahren getroffen wurde.

Die vier Entscheidungen liegen nicht in einem geheimen Spezial-Lastenheft. Sie liegen in der KIS-Beschaffung, in der Schnittstellen-Engine, in der Dokument-Persistenz-Konfiguration und in der ePA-Anbindung — Stellen, die in jeder mittelgroßen deutschen Klinik existieren und die im laufenden Betrieb selten als zusammengehöriges Architektur-Bündel gelesen werden, weil jede für sich von einem anderen Team gepflegt wird. Wer sie als Bündel liest, sieht die Vorbefund-Aufnahme als Architektur-Frage. Wer sie einzeln liest, sieht vier Beschaffungs-Themen, die nichts miteinander zu tun haben — und die ärztliche Aufnahme-Stunde am Montagvormittag bleibt das Symptom, das sich nicht an der ärztlichen Sorgfalt heilen lässt. Die Architektur-Entscheidungen sind voneinander unabhängig in der Beschaffung; sie sind nicht voneinander unabhängig in der Wirkung. Klinische Qualität entsteht in der Architektur-Wahl, nicht in der ärztlichen Sorgfalt am Aufnahmetag.