HL7 und FHIR im Krankenhaus: Was interoperable KIS-Schnittstellen für das digitale Entlassmanagement bedeuten

HL7 (Health Level Seven) prägt die klinische Kommunikation seit Jahrzehnten. In deutschen Krankenhäusern ist HL7 v2 nach wie vor das Arbeitspferd: Aufnahme-, Verlegungs- und Entlassnachrichten, Anforderungen und Befundrückmeldungen sowie viele Abteilungsintegrationen laufen über v2-Nachrichtenströme, häufig vermittelt über eine Kommunikationsserver-/Integration-Engine.

HL7 v2 ist ein Messaging-Standard: Systeme tauschen Ereignisse aus – ein Patient wurde aufgenommen, ein Befund liegt vor, eine Anforderung wurde erstellt – in einem kompakten, segmentbasierten Format. Das ist robust, extrem verbreitet und in Integrationsteams gut verstanden.

Was HL7 v2 nicht bietet, ist ein modernes Abfragemodell. Eine Nachricht teilt mit, dass etwas passiert ist; sie gibt einer Anwendung keinen sauberen Weg, gezielt eine bestimmte Information abzurufen. Genau hier beginnt die Entwicklung hin zu API-basierter Interoperabilität.

Entscheidend ist: Bestehende HL7-v2-Infrastruktur verschwindet nicht, weil FHIR eingeführt wird. In der Praxis koexistieren beide über Jahre – v2 trägt weiterhin etablierte Ereignisflüsse, FHIR bedient neue, anwendungsnahe Use Cases. Integrationsstrategien sollten daher von Ergänzung statt Ablösung ausgehen. (Frühere HL7-Versionen sind nur historischer Kontext und keine Basis für neue Integrationen.)

ISiK (Informationstechnische Systeme im Krankenhaus) ist der deutsche Spezifikationsrahmen, der FHIR im Krankenhaus konkret nutzbar macht. Er existiert, weil ein Standard allein zu viel Spielraum lässt: Zwei Hersteller können FHIR-Unterstützung angeben und in der Praxis dennoch inkompatibel sein.

ISiK ist deshalb mehr als „eine FHIR-API“. ISiK besteht aus standardisierten Interoperabilitätsvorgaben, die FHIR-Ressourcen nutzen, zusammen mit definierten Anwendungsfällen für den Informationsaustausch zwischen Krankenhausinformationssystemen und anderen Anwendungen. Festgelegt werden Profile, geforderte Fähigkeiten und erwartetes Verhalten – damit Drittanwendungen sich darauf verlassen können, was ein bestätigtes KIS tatsächlich bereitstellt.

Das ISiK Basismodul deckt die Grundlagen ab, die nahezu jede Anwendung benötigt: administrative Patientendaten, Fall- und Kontaktinformationen sowie grundlegenden Lese- und Suchzugriff. Weitere Module erweitern den Rahmen unter anderem um Medikation, Dokumente sowie Termin- und Versorgungsinformationen.

Für Krankenhäuser macht ISiK aus der Aussage „unser KIS kann FHIR“ eine planbare Integrationsgrundlage. Für Systeme wie ORBIS (Dedalus), SAP IS-H, NEXUS AG, CGM, Meierhofer oder Epic definiert ISiK eine gemeinsame Basislinie und reduziert projektspezifischen Schnittstellenaufwand.

Die gematik verantwortet die Telematikinfrastruktur in Deutschland und spezifiziert und zulässt zentrale Anwendungen und Komponenten darin. Sie prägt wesentliche Teile des digitalen Gesundheitsökosystems – betreibt aber nicht jeden Interoperabilitätsstandard: HL7 und FHIR sind internationale Standards, die außerhalb der gematik entwickelt werden.

Die Telematikinfrastruktur (TI) ist das geschützte Netz des deutschen Gesundheitswesens. Sie verbindet berechtigte Teilnehmer – Krankenhäuser, Praxen, Apotheken, Kostenträger – und stellt Identitäten, Sicherheit und die Plattform für nationale Anwendungen bereit. Ziel ist der sichere, standardisierte Austausch von Gesundheitsinformationen zwischen geprüften Beteiligten.

KIM (Kommunikation im Medizinwesen) ist der TI-Dienst für den sicheren, formalen Nachrichtenaustausch: ein authentifizierter, verschlüsselter E-Mail-ähnlicher Kanal, über den etwa Entlassbriefe oder Überweisungsinformationen zwischen berechtigten Teilnehmern versendet werden.

Der TI-Messenger ergänzt dies um interoperable Echtzeitkommunikation für kurze organisatorische und fachliche Abstimmungen – näher an einem sicheren Chat als an formalem Dokumentenversand.

Die ePA (elektronische Patientenakte) macht patientenbezogene Informationen sektorenübergreifend verfügbar. Ihr praktischer Wert im Krankenhaus hängt nicht nur vom technischen Zugriff ab, sondern von der Integration in das KIS/Primärsystem und in Alltagsprozesse wie Aufnahme und Entlassung. Zugriff allein erzeugt noch keinen nutzbaren Kontext.

Das E-Rezept ist für Krankenhäuser vor allem am Übergang von stationärer zu ambulanter Versorgung relevant: Entlassmedikation muss verordnet, beschaffbar und nach der Entlassung verlässlich abgegeben werden – Entlassung, Medikation, ambulanter Übergang und Apotheke bilden eine durchgehende Kette, keine getrennten Schritte.

WardPilot folgt dem Prinzip, das die Architektur bereits beschreibt: Wir ersetzen Ihr KIS nicht, wir ergänzen es um eine operative Ebene. Das Krankenhausinformationssystem bleibt das führende System; WardPilot ergänzt die operative Schicht, für die diese Systeme nie ausgelegt waren.

Relevante Informationen werden über HL7- und FHIR-REST-APIs aus bestehenden Systemen gelesen und in gemeinsamen operativen Status überführt: Wer verantwortet welchen Entlassschritt, was blockiert ihn und wie weit ist die Entlassbereitschaft je Patient tatsächlich.

Das ist eine Architekturaussage, keine Zertifizierungsaussage. WardPilot beansprucht keine ISiK-, gematik-, TI- oder KIM-Zertifizierung; die konkreten Integrationsmöglichkeiten hängen immer von den Systemen und Schnittstellen des jeweiligen Krankenhauses ab.