FHIR und Interoperabilität im Krankenhaus: ISiK, HL7 und Umsetzung

Was HL7 v2 und FHIR unterscheidet, was ISiK von Krankenhäusern und Herstellern verlangt, welche Rolle Interoperabilitätsnavigator, ePA und MIO spielen und wie Kliniken Schnittstellen planvoll umsetzen.

Foto: Michael DeinhardGeschäftsführer, Berater und Trainer

Veröffentlicht am 9 Min. Lesezeit

Kurze Antwort

FHIR (Fast Healthcare Interoperability Resources) ist der Standard von HL7 International für den Austausch von Gesundheitsdaten über Web-Schnittstellen. In deutschen Krankenhäusern bildet er die Grundlage von ISiK, den offenen Schnittstellen, die Krankenhausinformations- und Subsysteme nach § 373 SGB V anbieten müssen. Daneben bleibt HL7 v2 über den Kommunikationsserver das Rückgrat des internen Datenaustauschs. Interoperabilität gelingt, wenn Krankenhäuser beide Welten planvoll verbinden und ISiK bei jeder Beschaffung einfordern.

Stand: November 2026

Das Wichtigste in Kürze

  • HL7 v2 überträgt Ereignisse als Nachrichten, FHIR stellt Daten als Ressourcen über eine REST-Schnittstelle bereit. Beide laufen im Krankenhaus nebeneinander.
  • ISiK sind FHIR-Spezifikationen der gematik nach § 373 SGB V. Zugelassene Krankenhäuser müssen Systeme einsetzen, die die Konformitätsbewertung bestanden haben.
  • Laut gematik ist ISiK Stufe 3 seit 1. Juli 2025 verpflichtend; Stufe 5 und 6 sind veröffentlicht, Stufe 5 wird über die IOP-Governance-Verordnung verbindlich.
  • Der Interoperabilitätsnavigator INA bündelt Standards, verbindliche Festlegungen und die Konformitätsbewertung des Kompetenzzentrums für Interoperabilität (KIG).
  • Seit Oktober 2025 nutzen Krankenhäuser die ePA verpflichtend; MIO legen die Formate für ePA-Inhalte fest.
  • Die größten Stolpersteine sind selten technisch: unklare Zuständigkeiten, fehlende Anforderungen in Ausschreibungen und uneinheitliche Stammdaten.

Was unterscheidet HL7 v2 und FHIR?

Kurze Antwort

HL7 v2 verschickt Nachrichten, wenn etwas passiert – etwa eine Aufnahme oder ein neuer Laborbefund. FHIR bietet Daten als einzelne Ressourcen an, die andere Systeme über eine Web-Schnittstelle gezielt abfragen oder schreiben können.

Merkmal HL7 v2 HL7 FHIR
Prinzip Ereignisgesteuerte Nachrichten (zum Beispiel Aufnahme, Verlegung, Entlassung, Befund) Ressourcen wie Patient, Encounter, Observation oder DocumentReference
Format Textnachrichten aus Segmenten und Feldern JSON oder XML
Übertragung meist über TCP-Verbindungen, zentral über den Kommunikationsserver REST-Schnittstelle über HTTPS, auch Nachrichten und Dokumente möglich
Stärken sehr verbreitet, in nahezu allen Bestandssystemen vorhanden, bewährt im Hausbetrieb gezielte Abfragen, Web- und App-Technik, Profile für nationale Vorgaben
Grenzen viele hausspezifische Varianten, schwer für Apps und Portale nutzbar Profile und Versionen müssen sauber abgestimmt sein
Rolle in Deutschland Standard für interne Schnittstellen Grundlage von ISiK, ePA-Inhalten (MIO) und vielen Vorgaben der gematik

FHIR hat aus den Erfahrungen mit HL7 v2, HL7 v3 und CDA gelernt und lässt sich allein oder neben diesen Standards einsetzen. Die meisten FHIR-Ressourcen sind auf HL7-v2-Strukturen abbildbar. Für Krankenhäuser heißt das: FHIR ersetzt HL7 v2 nicht über Nacht, sondern ergänzt es dort, wo Systeme Daten gezielt abfragen, Apps eingebunden werden oder gesetzliche Vorgaben FHIR verlangen.

Was ist ISiK und was verlangt § 373 SGB V?

Kurze Antwort

ISiK sind einheitliche FHIR-Schnittstellen für Krankenhaussysteme. § 373 SGB V verpflichtet zugelassene Krankenhäuser, Systeme einzusetzen, deren Umsetzung in einer Konformitätsbewertung nach § 387 SGB V bestätigt wurde.

Die gematik hat die ISiK-Spezifikationen im Auftrag des Gesetzgebers als FHIR Implementation Guides erstellt. Sie enthalten FHIR-Profile und eine REST-Schnittstelle, die im Wesentlichen vom FHIR-Standard vorgegeben ist. Die Spezifikationen wachsen in Stufen; jede Stufe ergänzt oder aktualisiert Module.

Stufe Veröffentlicht Verbindlichkeit laut gematik
Stufe 3 (Basis, Dokumentenaustausch, Medikation, Terminplanung, Vitalparameter) 1. Juli 2023 verpflichtend ab 1. Juli 2025, gültig voraussichtlich bis 31. Mai 2027
Stufe 5 1. Juli 2025 Verbindlichkeit über Anlage 1 der IOP-Governance-Verordnung (GIGV), gültig voraussichtlich bis 31. Mai 2027
Stufe 6 1. Juli 2026 noch offen

Stufe 5 umfasst unter anderem die Module Basis, Dokumentenaustausch, Vitalparameter und Körpermaße, Terminplanung, Medikation, ICU-Normalstation, Labor, Connect, Formular und Subscription. Nicht jedes Modul ist für jedes System „bestätigungsrelevant“: Die gematik legt je Modul fest, welche Akteure – etwa der Basis-Server oder der Dokumenten-Server – die Anforderungen erfüllen müssen.

Vom Bestätigungsverfahren zur Konformitätsbewertung: Hersteller konnten ihre Systeme bisher in einem ISiK-Bestätigungsverfahren der gematik prüfen lassen. Ab Stufe 5 mündet dieses Verfahren durch die Aufnahme der Anforderungen in die Anlage 1 der GIGV in die Konformitätsbewertung nach § 387 SGB V. Das Kompetenzzentrum für Interoperabilität oder eine akkreditierte Stelle stellt dann ein Zertifikat aus, das höchstens drei Jahre gilt.

Pflichten nach § 373 SGB V:

  • Das Kompetenzzentrum erstellt die Spezifikationen im Benehmen mit der Deutschen Krankenhausgesellschaft und den Verbänden der IT-Industrie; verbindlich festgelegt werden sie per Rechtsverordnung des Bundesgesundheitsministeriums.
  • Welche Subsysteme die Schnittstellen integrieren müssen, legt die Deutsche Krankenhausgesellschaft im Einvernehmen mit dem Kompetenzzentrum fest, jährlich bis zum 30. April.
  • Zugelassene Krankenhäuser müssen Systeme einsetzen, die die Konformitätsbewertung bestanden haben.

Die gematik weist außerdem darauf hin, dass die ISiK-Konformitätsbewertung bei der Vorabprüfung von Förderkriterien nach § 21 Abs. 2 der Krankenhausstrukturfonds-Verordnung helfen kann.

Welche Rolle spielen INA und das Kompetenzzentrum für Interoperabilität?

Kurze Antwort

Das Kompetenzzentrum für Interoperabilität im Gesundheitswesen (KIG) ist nach § 385 SGB V bei der gematik angesiedelt. Es ermittelt Bedarf, empfiehlt und entwickelt Standards, schlägt verbindliche Festlegungen vor und führt Konformitätsbewertungen durch. Seine Plattform ist der Interoperabilitätsnavigator INA.

Auf INA finden Krankenhäuser und Hersteller:

  • Standards und Profile: Übersicht über Spezifikationen, Leitfäden und Initiativen, darunter ISiK, MIO, die Medizininformatik-Initiative und Terminologien des BfArM.
  • Verbindliche Festlegungen: die Anforderungen, die über die GIGV verpflichtend werden, gesondert ausgewiesen.
  • Konformitätsbewertung: Informationen zum Verfahren und zu erteilten Zertifikaten.
  • Mitwirkung: Anträge für Standards und die Meldung von Interoperabilitätsproblemen.

Für Krankenhäuser lohnt sich ein Blick auf INA vor jeder Beschaffung: Dort lässt sich prüfen, welche Anforderungen für ein System gelten und ob ein Hersteller bereits zertifiziert ist.

Wie hängen ePA, MIO und Krankenhaus-IT zusammen?

Kurze Antwort

Krankenhäuser müssen die elektronische Patientenakte seit dem 1. Oktober 2025 nutzen und nach § 348 SGB V unter anderem Entlassbriefe einstellen. MIO legen fest, in welchem Format solche Inhalte gespeichert werden.

ePA-Anbindung: Nach § 348 SGB V übermitteln zugelassene Krankenhäuser Daten aus der aktuellen Behandlung in die ePA, sofern sie elektronisch und interoperabel verarbeitet werden und die versicherte Person nicht widersprochen hat. Ausdrücklich genannt sind Entlassbriefe. Widersprüche sind in der Behandlungsdokumentation festzuhalten, bei besonders sensiblen Daten ist auf die Möglichkeit einer Beschränkung hinzuweisen. Technisch läuft die Anbindung über das KIS und die Telematikinfrastruktur; der Kommunikationsserver liefert oft die Dokumente aus Subsystemen zu. Nach einer Umfrage des Deutschen Krankenhausinstituts vom Februar 2026 bereitete vielen Häusern vor allem das automatisierte Hochladen von Dokumenten noch Probleme – ein Hinweis darauf, wie wichtig saubere Schnittstellen zwischen KIS, Archiv und Subsystemen sind.

MIO: Medizinische Informationsobjekte sind standardisierte Bausteine für ePA-Inhalte, etwa Impfpass, Laborbefund, Medikationsplan, Patientenkurzakte, Entlassbrief oder Überleitungsbogen. Die Kassenärztliche Bundesvereinigung trifft die Festlegungen nach § 355 SGB V und stellt dafür das Einvernehmen mit dem Kompetenzzentrum für Interoperabilität her. Für Krankenhäuser ist wichtig: Je mehr Inhalte als MIO strukturiert vorliegen, desto besser können Ärztinnen, Ärzte und Pflegekräfte sie in ihren Systemen weiterverarbeiten.

Welche Rolle hat der Kommunikationsserver?

Kurze Antwort

Der Kommunikationsserver – oft auch Integrationsplattform genannt – verbindet die Systeme im Haus. Er empfängt, übersetzt und verteilt Nachrichten und wird zunehmend zur Drehscheibe zwischen HL7 v2 und FHIR.

Typische Aufgaben:

  • Routing: Eine Aufnahme im KIS wird an Labor, Radiologie, Pflegedokumentation und Küche weitergegeben.
  • Übersetzung: Hausspezifische HL7-v2-Varianten werden angeglichen oder in FHIR-Ressourcen umgewandelt.
  • Überwachung: Fehlgeschlagene Nachrichten werden erkannt, protokolliert und erneut gesendet.
  • Entkopplung: Systeme lassen sich austauschen, ohne alle Schnittstellen neu zu bauen.

Wichtig ist eine klare Rollenverteilung: Der Kommunikationsserver ersetzt nicht die ISiK-Schnittstellen der Systeme selbst, kann aber helfen, ältere Subsysteme anzubinden. Auch Datenplattformen für Analysen profitieren von einem gepflegten Kommunikationsserver, weil Ereignisse dort bereits strukturiert vorliegen.

Wie gehen Krankenhäuser bei der Umsetzung vor, und was sind typische Stolpersteine?

Kurze Antwort

Mit einer Bestandsaufnahme aller Schnittstellen, klaren Anforderungen in Ausschreibungen, einem kleinen Kernteam aus IT, Fachbereichen und Herstellern und Tests mit echten Abläufen. Die häufigsten Probleme sind organisatorisch.

  1. Schnittstellenlandkarte erstellen: Welche Systeme tauschen welche Daten über welchen Standard aus? Wer ist verantwortlich, wer der Hersteller?
  2. ISiK-Status prüfen: Für KIS und bestätigungsrelevante Subsysteme beim Hersteller und auf INA klären, welche Stufe umgesetzt und zertifiziert ist.
  3. Anforderungen in Verträge schreiben: Bei Ausschreibungen ISiK-Konformität, FHIR-Version, Profile, Testumgebung und Kosten für Updates ausdrücklich fordern.
  4. Stammdaten ordnen: Einheitliche Patienten-, Fall- und Organisationskennungen sowie gemeinsame Kataloge sind Voraussetzung für jede Schnittstelle.
  5. Sicherheit mitdenken: FHIR-Schnittstellen sind Web-Schnittstellen. Authentifizierung, Berechtigungen, Verschlüsselung und Protokollierung gehören in das Konzept – passend zu § 391 SGB V und, für größere Häuser, NIS2.
  6. Testen und überwachen: Mit realistischen Fällen testen, Fehlermeldungen auswerten, Verantwortliche für den Betrieb benennen.

Typische Stolpersteine

Stolperstein Folge Gegenmaßnahme
ISiK nur auf dem Papier gefordert Hersteller liefern Teilumsetzungen oder Zusatzkosten Konkrete Stufe, Module und Nachweis der Konformitätsbewertung im Vertrag
Uneinheitliche Stammdaten Datensätze lassen sich nicht zuordnen Führendes System je Datenart festlegen
Viele hausspezifische HL7-v2-Varianten Jede neue Anbindung wird zum Einzelprojekt Varianten dokumentieren und schrittweise vereinheitlichen
Fehlendes Wissen im Haus Abhängigkeit von Herstellern und Dienstleistern Kernteam mit FHIR- und Schnittstellenwissen aufbauen
Schnittstellen ohne Sicherheitskonzept neue Angriffsflächen Sicherheitsanforderungen von Beginn an festlegen

Bei Schnittstellen, Datenintegration und Automatisierung unterstützt Sie unser Bereich Softwareentwicklung im Gesundheitswesen. Wie Digitalisierung und Interoperabilität zusammenhängen, beschreibt der Artikel Was bedeutet Digitalisierung im Gesundheitswesen?, Werkzeuge aus der Open-Source-Welt wie FHIR-Server stellt der Artikel Open Source im Gesundheitswesen vor.

Welche Schulungen helfen bei Interoperabilitätsprojekten?

Kurze Antwort

Interoperabilität braucht Wissen über Beschaffung, Datenmodelle, Programmierung, Sicherheit und Projektsteuerung. Ein eigenes FHIR-Seminar bieten wir derzeit nicht als offenen Termin an; die folgenden Seminare decken die Grundlagen im Projektteam ab.

Aufgabe Passendes Seminar Dauer
Schnittstellenanforderungen in Ausschreibungen und Verträgen festlegen Beschaffung im Gesundheitswesen 2 Tage
Datenmodelle verstehen und Stammdaten ordnen SQL und Datenbankdesign Grundkurs 3 Tage
FHIR-Ressourcen verarbeiten und Schnittstellen testen Python – Grundlagen 5 Tage
Schnittstellen und Patientendaten absichern Healthcare-Security 3 Tage
Interoperabilitätsprojekte planen und steuern CompTIA Project+ 4 Tage

Weitere Seminare finden Sie in den Bereichen Softwareentwicklung & DevOps und Management & Beschaffung.

Fazit

FHIR und ISiK machen den Datenaustausch im Krankenhaus planbarer – vorausgesetzt, Kliniken nutzen die Vorgaben aktiv. HL7 v2 und der Kommunikationsserver bleiben für viele Jahre im Einsatz; FHIR kommt dort hinzu, wo ISiK, ePA und neue Anwendungen es verlangen. Wer seine Schnittstellen kennt, ISiK-Konformität konsequent in Verträge schreibt, Stammdaten ordnet und ein eigenes Kernteam aufbaut, wird unabhängiger von einzelnen Herstellern und schafft die Grundlage für ePA, Datenanalyse und KI.

Hinweis: Dieser Überblick ersetzt keine Rechtsberatung.

Quellen

  1. § 373 SGB V – Spezifikationen zu den offenen und standardisierten Schnittstellen für informationstechnische Systeme. Bundesministerium der Justiz.
  2. § 385 SGB V – Kompetenzzentrum für Interoperabilität im Gesundheitswesen. Bundesministerium der Justiz.
  3. § 387 SGB V – Konformitätsbewertung. Bundesministerium der Justiz.
  4. § 348 SGB V – Übertragung von Behandlungsdaten in die elektronische Patientenakte durch zugelassene Krankenhäuser. Bundesministerium der Justiz.
  5. Blitzumfrage Umsetzung ePA (März 2026). Deutsches Krankenhausinstitut, zur Nutzungspflicht seit 1. Oktober 2025.
  6. ISiK – Informationstechnische Systeme in Krankenhäusern. gematik, Fachportal.
  7. IOP-Anforderungen im Rahmen von ISiK Stufe 5. gematik, Kompetenzzentrum für Interoperabilität im Gesundheitswesen, Version 1.0.0 vom 6. November 2025.
  8. INA – Interoperabilitätsnavigator. gematik.
  9. FHIR Overview. HL7 International.
  10. Medizinische Informationsobjekte (MIO). Kassenärztliche Bundesvereinigung.

Passende Schulungen

Vertiefen Sie das Thema mit Ihrem Team – im offenen Seminar oder als Inhouse-Schulung.

Häufige Fragen

Was ist der Unterschied zwischen HL7 v2 und FHIR?

HL7 v2 ist ein seit Jahrzehnten verbreiteter Nachrichtenstandard, mit dem Systeme Ereignisse wie Aufnahme, Verlegung oder Befund als Textnachrichten austauschen. FHIR baut auf Ressourcen auf, die per Web-Schnittstelle (REST) im Format JSON oder XML abgefragt und geschrieben werden. In Krankenhäusern laufen beide nebeneinander.

Was ist ISiK?

ISiK steht für „Informationstechnische Systeme in Krankenhäusern“. Es sind von der gematik nach § 373 SGB V festgelegte FHIR-Schnittstellen, die Krankenhausinformations- und Subsysteme anbieten müssen. Die Spezifikationen werden in Stufen veröffentlicht und in Module wie Basis, Dokumentenaustausch, Medikation oder Terminplanung gegliedert.

Müssen Krankenhäuser ISiK-konforme Systeme einsetzen?

Ja. Nach § 373 Abs. 5 SGB V sind zugelassene Krankenhäuser verpflichtet, informationstechnische Systeme einzusetzen, die ein Konformitätsbewertungsverfahren nach § 387 SGB V erfolgreich durchlaufen haben. Die verbindlichen Fassungen und Zeiträume legt das Bundesgesundheitsministerium in der Verordnung nach § 385 SGB V fest.

Welche ISiK-Stufe gilt im November 2026?

Laut gematik ist Stufe 3 seit dem 1. Juli 2025 verpflichtend und voraussichtlich bis 31. Mai 2027 gültig. Stufe 5 wurde am 1. Juli 2025 veröffentlicht, Stufe 6 am 1. Juli 2026. Mit Stufe 5 werden die Anforderungen in die Anlage 1 der IOP-Governance-Verordnung aufgenommen und über eine Konformitätsbewertung nachgewiesen.

Was ist der Interoperabilitätsnavigator INA?

INA ist die Wissensplattform der gematik und des Kompetenzzentrums für Interoperabilität im Gesundheitswesen (KIG). Dort finden Sie Standards, Profile und Leitfäden, verbindliche Festlegungen, Informationen zur Konformitätsbewertung und die Möglichkeit, Interoperabilitätsprobleme zu melden.

Was haben ePA und MIO mit Interoperabilität im Krankenhaus zu tun?

Krankenhäuser müssen nach § 348 SGB V unter anderem Entlassbriefe in die elektronische Patientenakte einstellen, sofern Versicherte nicht widersprochen haben. Medizinische Informationsobjekte (MIO) legen fest, in welchem Format Inhalte wie Impfpass, Laborbefund oder Entlassbrief in der ePA gespeichert werden, damit andere Systeme sie lesen können.

Lassen Sie uns über Ihr Projekt sprechen.

Unverbindliches Erstgespräch zu Beratung, Projekt oder Schulung.