FHIR-Mapping im Krankenhaus: Von heterogenen Daten zu klaren Strukturen
Wie aus Dateien, Transferprotokollen und Systemdaten nutzbare FHIR-Ressourcen für klinische Prozesse und Interoperabilitätsplattformen entstehen.
FHIR-Mapping ist mehr als Formatkonvertierung
FHIR steht für Fast Healthcare Interoperability Resources und ist ein Standard von HL7 für den elektronischen Austausch von Gesundheitsinformationen. Sein Grundbaustein ist die Ressource: ein klar beschriebenes Datenobjekt für beispielsweise Patientinnen und Patienten, Beobachtungen, Befunde, Medikamente oder Dokumente.
Beim Mapping wird deshalb nicht lediglich eine Datei in JSON oder XML umgewandelt. Die Bedeutung einer Information muss erkannt und an der richtigen Stelle im Zielmodell abgebildet werden. Erst dann wird aus technisch lesbaren Daten ein klinisch verständlicher und zwischen Systemen nutzbarer Kontext.
Viele Quellen, eine gemeinsame Struktur
Im Krankenhaus entstehen Informationen in sehr unterschiedlichen Formen: als strukturierter Systemexport, Nachricht eines Schnittstellenprotokolls, Tabellenzeile, PDF, Textdokument oder Bestandteil eines Befundberichts. Selbst identische Inhalte können je nach Quellsystem anders benannt, codiert oder angeordnet sein.
LLMedi führt diese Quellen in einem gemeinsamen Verarbeitungsschritt zusammen. Inhalte, Metadaten und vorhandene Beziehungen werden erfasst und für das vorgesehene FHIR-Zielmodell eingeordnet, ohne den Bezug zur ursprünglichen Quelle zu verlieren.
Vom Eingang zur validierten FHIR-Ressource
Ein belastbares Mapping besteht aus mehreren aufeinander abgestimmten Schritten. Automatisierung kann dabei die wiederkehrende Zuordnung übernehmen; Zielprofile, Regeln und Validierung sorgen dafür, dass die Ausgabe zum konkreten Integrationsszenario passt.
- Quelle erfassen: Struktur, Freitext, Metadaten und Beziehungen identifizieren
- Semantik einordnen: klinische Konzepte, Werte, Einheiten und Bezüge normalisieren
- FHIR abbilden: passende Ressourcen erzeugen und miteinander referenzieren
- Zielprofil prüfen: Pflichtfelder, Kardinalitäten, Terminologien und weitere Vorgaben validieren
Aus einzelnen Angaben wird Patientenkontext
Ein Laborwert kann als Observation abgebildet und mit einem DiagnosticReport sowie der zugehörigen Patient-Ressource verknüpft werden. Eine Verordnung kann in einer MedicationRequest strukturiert sein, während ein vorhandener Arztbrief über eine DocumentReference mitsamt Quelle auffindbar bleibt.
Der eigentliche Wert liegt in diesen Beziehungen. FHIR-Ressourcen werden nicht als isolierte Datensätze betrachtet, sondern zu einem nachvollziehbaren klinischen Zusammenhang verbunden, den angebundene Systeme gezielt weiterverwenden können.
FHIR, Profile, ISiK und die IOP
Der FHIR-Basisstandard lässt bewusst Spielraum für unterschiedliche Anwendungsfälle. Profile schränken Ressourcen für einen konkreten Zweck ein, etwa durch verbindlichere Pflichtfelder, Terminologien oder Kardinalitäten. Ein Mapping muss deshalb immer das vorgesehene Zielprofil berücksichtigen und nicht nur eine allgemeine FHIR-Ressource erzeugen.
Für den deutschen Krankenhausbereich konkretisiert ISiK den interoperablen Datenaustausch über FHIR-Implementierungsleitfäden und eine REST-basierte Schnittstelle. Entsprechend abgebildete und geprüfte Ressourcen können an eine Interoperabilitätsplattform übergeben und dort für angeschlossene klinische Systeme bereitgestellt werden.
Automatisieren, ohne Mehrdeutigkeiten zu übersehen
Nicht jede Quelle ist eindeutig. Abkürzungen, lokale Bezeichnungen, fehlende Einheiten oder unvollständige Dokumente können mehrere Interpretationen zulassen. Gutes Mapping macht solche Unsicherheiten sichtbar, anstatt sie stillschweigend in scheinbar saubere Strukturen zu übertragen.
Dafür verbindet LLMedi automatische Extraktion und semantische Zuordnung mit definierten Mappingregeln und technischer Validierung. So kann der wiederkehrende Aufwand sinken, während die Ausgabe kontrollierbar und auf das jeweilige Zielsystem abgestimmt bleibt.
Mapping innerhalb der Klinik-Infrastruktur
Die Verarbeitung kann vollständig innerhalb der vorgesehenen Infrastruktur des Krankenhauses erfolgen. Quelldaten müssen für Extraktion, Zuordnung und FHIR-Erzeugung damit nicht an einen öffentlichen Cloudanbieter übertragen werden.
Gemeinsam mit der Klinik wird festgelegt, welche Quellen angebunden werden, welche Profile gelten und an welche IOP oder Zielsysteme die validierten Ressourcen übergeben werden. So entsteht keine universelle Einmalschnittstelle, sondern ein kontrollierter Datenfluss für die konkrete Systemlandschaft.
Standards & Quellen
Von der Einordnung zur Anwendung
Erfahren Sie, wie LLMedi in Ihren klinischen Prozess passt.
Weiterlesen
KI für Krankenhäuser: Wo klinische Unterstützung wirklich ansetzt
Wie klinische KI Patientenkontext, Gespräch und Dokumentation verbindet und sich sinnvoll in bestehende Krankenhausprozesse einfügt.
On-Premise-KI im Krankenhaus: Was lokaler Betrieb bedeutet
Eine Einordnung von lokaler KI-Infrastruktur, Datenverarbeitung im Haus und der Anbindung an bestehende klinische Systeme.