HL7 oder FHIR: Ihre Entscheidungshilfe

von | 18.04.2026

HL7 oder FHIR – Wie Sie die richtige Integrationsstrategie für Ihr Krankenhausinformationssystem wählen

In der aktuellen Krankenhaus-IT prallen zwei Welten aufeinander: Der wachsende Bedarf an Integration zwischen Patientendatenmanagementsystem (PDMS), Krankenhausinformationssystem (KIS), Medizingeräten und externen System trifft auf historisch gewachsene HL7-v2-Infrastrukturen. [1] Moderne, häufig auf REST basierende APIs treffen auf ereignisgetriebene HL7-Nachrichten. Jetzt stellt sich die Frage: Weiter mit HL7 oder jetzt auf FHIR umsteigen?

Damit Sie eine fundierte Entscheidung treffen können, beleuchte ich in diesem Artikel die Unterschiede zwischen den Standards und liefere Ihnen eine Grundlage für zukünftige Entwicklungen.

HL7 v2 – der Klassiker

HL7 (Health Level Seven) ist seit Jahrzehnten der De-facto-Standard in vielen Kliniken, langjährig erprobt und eine robuste Wahl zur Übertragung von Patienten- und Labordaten. Der Austausch der Nachrichten erfolgt ereignisgetrieben und ist textbasiert. Jede Nachricht besteht aus einer Reihe von Segmenten, welche weiter in Felder, Komponenten und Subkomponenten unterteilt sind. Während die Spezifikation auf Segmentebene noch einheitlich interpretiert wird (z. B. wofür ein PID-Segment verwendet wird), ist die Interpretation auf Feldebene deutlich uneinheitlicher und erfordert häufig individuelle Anpassungen bei einem oder mehreren Kommunikationspartnern. Oder um es mit den Worten von Captain Barbossa zu sagen: „Handelt es sich bei dem Standard eher um sogenannte Richtlinien als um Regeln“. [2]

Zudem ist die Struktur der HL7-Nachrichten nur eingeschränkt zur Weiterverarbeitung geeignet und erfordert ein umfangreiches Mapping im Zielsystem.

FHIR – der moderne Ansatz

FHIR (Fast Healthcare Interoperability Resources) setzt primär auf REST, unterstützt aber auch Messaging- und dokumentbasierte Ansätze. Patienten, Observationen und dergleichen werden auf Ressourcen abgebildet und mit den HTTP-Verben (GET, POST, PUT, DELETE) bearbeitet. Es gibt ein klar definiertes, aber durch Profile flexibel erweiterbares Datenmodell. Für diverse Programmiersprachen gibt es häufig bereits vorhandene Bibliotheken, so dass man oft direkt starten kann, ohne zunächst einen eigenen Parser entwickeln zu müssen.

Auch bei FHIR wird ein Mapping ins Zielsystem nicht vollständig entfallen, aber da die API bereits strukturierte Objekte wie Patienten oder Beobachtungen bereitstellt, gestaltet sich die Weiterverarbeitung deutlich einfacher. Für Deutschland existieren umfangreiche FHIR-Profile, die eine einheitliche Nutzung sicherstellen sollen. Die gematik bspw. setzt in der Telematikinfrastruktur zunehmend auf FHIR-basierte Profile und stellt entsprechende Spezifikationen für Deutschland bereit. [3]

HL7 v2 und FHIR im Vergleich

Beide Standards haben im Grunde die gleiche Aufgabe: behandlungsrelevante Daten zwischen verschiedenen Systemen auszutauschen. Die Herangehensweise ist jedoch höchst unterschiedlich: In HL7 informieren sich die Systeme gegenseitig nach dem Push-Prinzip, während FHIR die Daten strukturiert bereitstellt.

Historisch entstammt HL7 einer Denkweise, bei der sich verschiedene System gegenseitig kannten und Buch darüber führten, wer bereits welche Information erhalten hat. Bei FHIR holen sich die Clients hingegen die Daten, welche sie benötigen und können sich bei Bedarf durch das FHIR Subscription Framework bei Änderungen benachrichtigen lassen.

Bei HL7 wird der sichere Betrieb durch vertrauenswürdige Proxys oder VPNs sichergestellt (oder manchmal darauf verzichtet). FHIR empfiehlt verschlüsselte Verbindungen zum Datenschutz sowie OAuth 2.0 zur Authentifizierung, und gibt sogar Implementierungsleitfäden raus. Damit sollte es auch für Drittanbieter einfach möglich sein, Apps an diverse Systeme anzubinden. Während der Datenaustausch bei HL7 sich fast immer auf Systeme eines Krankenhauses beschränkte, ist FHIR explizit für den übergreifenden Datenaustausch, nicht zuletzt in der Telematikinfrastruktur, gedacht.

Die folgende Tabelle fasst den Vergleich kurz zusammen: 

Kriterium HL7 v2 FHIR
Paradigma Messaging Messaging (Push) REST + Pull
Datenmodell positionsbasiert ressourcenbasiert
Interoperabilität eingeschränkt hoch
Implementierung komplex moderat

Entscheidungshilfen für HL7 v2 oder FHIR

Wann sollten Sie sich für HL7 v2 oder FHIR entscheiden?

Grundsätzlich gibt es zwei Szenarien:

  1. Bestandssysteme modernisieren: Ihre bestehende Software (z. B. PDMS, KIS) nutzt HL7 v2 für die Kommunikation mit anderen Systemen.
  2. Neuentwicklung: Sie planen eine neue Software und müssen sich für einen Standard entscheiden.

Wenn Sie Ihre bestehende Software ausschließlich mit anderer langer existierender Software kommunizieren muss, dann gibt es keinen Grund überhastete Entscheidungen zu treffen. HL7 wird hier noch lange gute Dienste leisten und im Einsatz bleiben. Allerdings sollten Sie einen Blick in ihre Software und Dokumentation werfen. Zwar gibt es nur geringen Wartungsbedarf, aber häufig ist die Softwarearchitektur veraltet, die ursprünglichen Entwickler längst nicht mehr im Haus und die Dokumentation unvollständig bzw. nur noch in Teilen vorhanden. Selbst einfache Wartungsaufgaben und Anpassungen können hier schnell sehr aufwendig werden, schlicht weil das Wissen um den Zustand des Systems neu aufgebaut werden muss. Langfristig sollten Sie dennoch Ressourcen in FHIR stecken, bevor es ihr Mitbewerber vormacht. Spätestens wenn zwei Mitbewerber FHIR unterstützen, könnte es sonst in der nächsten Ausschreibung schwierig werden.

Wenn Sie eine neue Software entwickeln, wird es etwas komplizierter. Zwar ist die Zukunftssicherheit von HL7 v2 begrenzt, aber wenn ihre Software mit einem bestimmten KIS kommunizieren soll, das nur HL7 v2 anbietet, dann bleibt Ihnen kaum eine Wahl. Entweder Sie nutzen bestehende Konverter von Drittanbietern und holen sich dessen Komplexität ins Haus, oder Sie entwickeln die Schnittstelle selbst. Hier sollten Sie auf eine saubere Architektur, ausreichende Dokumentation und testgetriebene Entwicklung achten und wieder an Captain Barbossa denken: „es sind eher Richtlinien als Regeln“. Im Zweifelsfall sollte ihre Software lieber flexibel sein, als zu stark an der Spezifikation zu kleben.

Wenn ihre Software mit der Telematikinfrastruktur (TI) der gematik [4] oder dem Europäische Gesundheitsdatenraum (EHDS) [5] kommunizieren soll, ist FHIR in der Praxis kaum zu umgehen. Es ist zukunftssicherer und durch das Aufsetzen auf internationale Standards, wird die Schnittstelle für Ihre Entwickler keine große Hürde darstellen.

Fazit

HL7 v2 hat seine Grenzen erreicht, besonders in einer Welt, in der Patienten ambulant versorgt werden, Wearables und Health-Apps Daten liefern und Systeme über Institutionsgrenzen hinweg kommunizieren müssen. FHIR ist die Zukunft, nicht nur weil die gematik und der EHDS darauf setzen, sondern weil es skalierbar, sicher und entwicklerfreundlich ist.

Natürlich wird HL7 v2 nicht von heute auf morgen verschwinden. Kurzfristig wird ein hybrider Ansatz (HL7 v2 für Alt-Systeme, FHIR für neue Integrationen) unvermeidbar sein. Langfristig sollten Sie jedoch Ressourcen in FHIR investieren – sonst riskieren Sie, im Wettbewerb zurückzufallen.

Die entscheidende Frage ist daher nicht mehr, ob Sie FHIR einsetzen werden, sondern wann und wie strategisch Sie den Übergang gestalten.

 

Hinweise:

[1] KIS (Krankenhausinformationssystem) und PDMS (Patientendatenmanagementsystem) sind digitale Kernsysteme im Krankenhaus. Das KIS ist die zentrale Verwaltungs- und Dokumentationssoftware für den gesamten Patientenweg, während das PDMS als hochspezialisiertes Teilsystem Intensivstationen und OPs bei der Echtzeit-Erfassung von Gerätedaten und der Intensivmedizin unterstützt. Hier finden Sie weitere Informationen über PDMS bzw. KIS.
[2] Captain Hector Barbossa ist eine Figur aus dem Spielfilm „Fluch der Karibik“ (2003). Mit der Aussage antwortet er Elizabeth Swann. die sich auf den „Kodex“ der Piraten beruft, um nicht auf einer Insel ausgesetzt zu werden.
[3] Die gematik GmbH (Nationale Agentur für Digitale Medizin) ist die zentrale Stelle in Deutschland, die für den Aufbau, den Betrieb und die Weiterentwicklung der Telematikinfrastruktur (TI) zuständig ist. Sie vernetzt Akteure im Gesundheitswesen, um digitale Anwendungen wie das E-Rezept, die elektronische Gesundheitskarte (eGK) und die elektronische Patientenakte (ePA) sicher umzusetzen.
[4] Die Telematikinfrastruktur (TI) ist das sichere, geschlossene digitale Netzwerk im deutschen Gesundheitswesen, das Ärzte, Krankenhäuser, Apotheken und Krankenkassen vernetzt. Verwaltet von der gematik, ermöglicht sie den schnellen, datenschutzkonformen Austausch medizinischer Daten.
[5] Der Europäische Gesundheitsdatenraum (EHDS) ist eine EU-weite Initiative, die den sicheren Austausch und die Nutzung elektronischer Gesundheitsdaten über Ländergrenzen hinweg ermöglicht. Er trat am 25. März 2025 in Kraft, um die Patientenversorgung durch einfachen Zugang zu eigenen Daten zu verbessern und die Forschung zu fördern.

Hier finden Sie weitere Informationen zu FHIR.

Suchen Sie nach einem Team für Ihre Softwareentwicklung oder -modernisierung, das Sie mit HL7 v2 oder FHIR unterstützt? Dann erzählen Sie uns von Ihrem Projekt oder laden Sie sich alternativ den t2informatik Steckbrief herunter.

Wollen Sie als Meinungsmacherin oder Kommunikator über HL7 v2 oder FHIR diskutieren? Dann teilen Sie den Beitrag gerne in Ihrem Netzwerk. 

Hier finden Sie weitere Artikel aus dem t2informatik Blog:

t2informatik Blog: Unit-Tests mit KI generieren

Unit-Tests mit KI generieren

t2informatik Blog: Anwendungen mit Avalonia UI erstellen

Anwendungen mit Avalonia UI erstellen

t2informatik Blog: Wie gut sind KI-gestützte Code Reviews wirklich?

Wie gut sind KI-gestützte Code Reviews wirklich?

David Störmer
David Störmer

David Störmer ist Softwareentwickler und -architekt mit einer Leidenschaft für sauberen Code und testgetriebene Entwicklung (TDD). Sein Interesse für Programmierung wurde früh geweckt: Mit 15 entdeckte er in der Bibliothek ein Buch über QBasic und brachte damit erste Töne aus dem Windows-95-Rechner seiner Eltern hervor – ein prägendes Erlebnis.

Im Studium der Medieninformatik spezialisierte er sich auf Computer Vision und Visualization Technologies, behielt aber stets den Fokus auf wartbaren, klar strukturierten Code. TDD wurde für ihn zur Selbstverständlichkeit: „Der schönste Code nützt nichts, wenn nicht dokumentiert ist, was er leisten soll.“

Privat pendelt David zwischen Familienausflügen zum Karls Erdbeerhof und Projekten wie Hausautomatisierung oder der Sanierung des Eigenheims – immer mit dem Ziel, Technik und Alltag sinnvoll zu verbinden.

Im t2informatik Blog veröffentlichen wir Beträge für Menschen in Organisationen. Für diese Menschen entwickeln und modernisieren wir Software. Pragmatisch. ✔️ Persönlich. ✔️ Professionell. ✔️ Ein Klick hier und Sie erfahren mehr.