Zum Hauptinhalt
CareBond

HL7 und FHIR, erklärt für die Leitung von Pflegeeinrichtungen

«Wir sind HL7/FHIR-kompatibel.» Der Satz steht in fast jeder Offerte für Pflegesoftware – und er sagt fast nichts darüber aus, was zwei Systeme am Ende tatsächlich austauschen können. Dieser Beitrag erklärt, was hinter den beiden Standards steckt, was sie einem Alters- und Pflegeheim oder einer Spitex-Organisation bringen und wie sie mit dem elektronischen Patientendossier zusammenhängen.

HL7 und FHIR: Wovon ist genau die Rede?

HL7 International ist eine Normierungsorganisation; HL7 v2 und FHIR sind zwei ihrer Standards, nicht zwei Produkte. Das Messaging nach HL7 v2 ist die historische Sprache des Datenaustauschs zwischen Spitalsystemen. FHIR, die jüngere Entwicklung, beschreibt eHealth Suisse als «internationalen Interoperabilitätsstandard für den Austausch medizinischer Daten im Gesundheitswesen», der «moderne Web-Technologien wie REST-APIs sowie die Datenformate JSON, XML und Turtle (RDF)» nutzt.

Die Version zählt so viel wie der Name. FHIR R4 trägt die Nummer 4.0.1, veröffentlicht am 30. Oktober 2019, mit gemischtem Status: teils normativ, teils «Standard for Trial Use». Die aktuelle Fassung, FHIR R5 (5.0.0), stammt vom März 2023. Die Spezifikation erscheint unter der offenen Lizenz CC0 – Ihre IT-Verantwortlichen können sie gratis lesen und nachprüfen, was ein Anbieter ankündigt.

FHIR ersetzt die Vorgängergeneration deswegen nicht: «FHIR ergänzt die älteren Standards HL7 V2 und V3, ersetzt sie jedoch nicht vollständig, da diese in vielen Systemen weiterhin aktiv genutzt werden», schreibt eHealth Suisse.

HL7 v2 und FHIR: der Unterschied, der für Sie etwas ändert

HL7 v2 arbeitet mit Nachrichten, die ein Ereignis auslöst. Ein Eintritt, eine Verlegung oder ein Austritt erzeugen eine ADT-Nachricht, ein Laborresultat eine ORU-Nachricht. Kapitel 1 der Version 2.7 nennt das Ziel des Standards: Austauschregeln, die den Programmieraufwand für massgeschneiderte Schnittstellen beseitigen oder wesentlich verringern.

Dasselbe Kapitel benennt die Grenze – und die gehört in jede Verhandlung. Zwingend sind nur jene Felder, welche die Logik der Nachrichten tragen; viele weitere sind zwar spezifiziert, aber optional gelassen. Der Text zieht den Schluss gleich selbst: HL7 v2.7 kann kein echter «Plug-and-play»-Schnittstellenstandard sein, und die Unterschiede von Standort zu Standort werden höchstwahrscheinlich standortspezifisch ausgehandelte Vereinbarungen nötig machen.

FHIR denkt anders: Es zerlegt die Information in Ressourcen – Patient, Observation, DocumentReference –, die ein System über eine Web-Abfrage holt. Das ist einfacher zu testen und zu dokumentieren. Die Optionalität verschwindet aber nicht, sie verschiebt sich in sogenannte Profile, die für ein Land oder einen Anwendungsfall festlegen, welche Felder verlangt sind. Daraus folgt eine praktische Regel: die genaue Version verlangen. Zwei Programme, die «FHIR können», aber in unterschiedlichen Versionen, sprechen ohne Anpassung nicht miteinander.

Was Interoperabilität einer Einrichtung wirklich bringt

eHealth Suisse definiert Interoperabilität als «die Fähigkeit zweier IT-Systeme, Daten ohne menschliches Eingreifen auszutauschen, korrekt zu interpretieren und wiederzuverwenden».

Dieselbe Quelle unterscheidet fünf Ebenen: Politik und Recht, Organisation, Technik, Syntax, Semantik. Diese Aufzählung erklärt, warum so viele Schnittstellenprojekte enttäuschen. Die technische Ebene – Daten zum Fliessen bringen – ist die einfachste und die einzige, die eine Verkaufsdemonstration zeigt. Über das Ergebnis entscheiden die semantische und die organisatorische Ebene: Sind «Allergie» oder «Sturz» auf beiden Seiten nicht gleich codiert, funktioniert der Austausch – und die klinische Information geht trotzdem verloren.

Der konkrete Gewinn lässt sich kurz fassen: Eintrittsdaten nur einmal erfassen, Laborresultate, die im Dossier landen statt im Fax, ein lesbarer Bericht beim Übertritt aus dem Spital. Nichts Spektakuläres – zurückgewonnene Zeit für die Pflege.

Der Zusammenhang mit dem EPD – und was FHIR dort nicht leistet

Das Bundesgesetz über das elektronische Patientendossier (EPDG) ist seit dem 15. April 2017 in Kraft. Laut BAG ist der Anschluss ans EPD eine gesetzliche Pflicht für stationäre Gesundheitseinrichtungen, die zulasten der obligatorischen Krankenpflegeversicherung (OKP) abrechnen: Spitäler, Rehabilitationskliniken, psychiatrische Kliniken, Pflegeheime und Geburtshäuser; seit dem 1. Januar 2022 gilt sie auch für neu zugelassene Ärztinnen und Ärzte. Für die übrigen ambulant tätigen Gesundheitsfachpersonen – darunter die Spitex – und für die Bevölkerung bleibt sie freiwillig.

Technisch beruht das EPD nicht in erster Linie auf FHIR. Seine Spezifikationen, als Anhänge zur Verordnung des EDI über das elektronische Patientendossier (EPDV-EDI), schreiben IHE-Profile vor: CH:XDS für den Dokumentenaustausch, CH:XUA für die Authentifizierung, CH:PIXV3 und CH:PDQV3 für die Patientenidentifikation, CH:ATNA für die Protokollierung. Der sogenannte mobile Zugriff stützt sich demgegenüber auf FHIR R4, über den CH EPR FHIR Implementation Guide von eHealth Suisse (MHD, PDQm, PIXm, IUA).

Für die Zukunft ist die Richtung angekündigt: «eHealth Suisse setzt für die Erarbeitung von neuen Austauschformaten auf den HL7 FHIR Standard.» Die Folge: Eine Software, die «FHIR kann», ist deswegen noch lange nicht ans EPD angeschlossen. Der Anschluss setzt voraus, die EPD-Schnittstellen selbst zu implementieren oder einen Konnektor zu nutzen – eHealth Suisse stellt dafür den Open-Source-Konnektor HUSKY bereit – und in jedem Fall den Anschluss an eine zertifizierte Gemeinschaft oder Stammgemeinschaft.

Vom EPD zum E-GD: was das EGDG vorsieht

Der Bundesrat hat dem Parlament am 5. November 2025 die Botschaft zu einem neuen Bundesgesetz über das elektronische Gesundheitsdossier (EGDG) überwiesen, das das EPDG ablösen soll. Der Nationalrat hat die Vorlage am 14. September 2026 mit 134 zu 53 Stimmen bei 10 Enthaltungen angenommen; das Geschäft geht nun an den Ständerat.

Was der Entwurf laut BAG vorsieht: ein E-GD, das jede Person mit Wohnsitz in der Schweiz automatisch und kostenlos erhält und dem sie widersprechen kann; eine Anschlusspflicht, die auf alle Leistungserbringer ausgeweitet wird, die zulasten der obligatorischen Krankenpflegeversicherung abrechnen; der Bund betreibt das technische System, die Kantone tragen die laufenden Betriebskosten. In Betrieb gehen könnte das neue System «frühestens 2030». Parallel dazu läuft das nationale Programm DigiSanté (2025–2034).

Das Feld bewegt sich schneller als das Gesetz. Am 25. Juni 2026 meldete eHealth Suisse, dass Post Sanela ihre Tätigkeit als Plattformanbieterin und Stammgemeinschaft des EPD per Ende 2026 einstellt; ein Wechsel des Anbieters verhindert einen Unterbruch bei der Bereitstellung der Daten. Am 21. August 2026 hielt der Dachverband ARTISET fest, die SGK-N lasse die zentrale Frage der Anschlusspflicht offen, und empfahl im September, sie für Alters- und Pflegeheime bis zur Einführung des E-GD aufzuheben.

Fragen an einen Anbieter, der «HL7/FHIR» verspricht

Diese Fragen verlangen kein technisches Wissen, nur schriftliche Antworten. Eine vage Antwort ist auch schon eine Antwort.

Eine Dimension zieht sich durch alle anderen: der Datenschutz. Seit dem 1. September 2023 gilt das revidierte Datenschutzgesetz (revDSG). Gesundheitsdaten sind darin besonders schützenswerte Personendaten nach Art. 5 Bst. c Ziff. 2 DSG, und der EDÖB hält fest, dass Therapeutinnen und Therapeuten im beruflichen Kontext erhaltene Daten grundsätzlich nicht ohne Einwilligung der betroffenen Person bekanntgeben dürfen – zum Datenschutz kommt das Berufsgeheimnis nach Art. 321 StGB hinzu.

  • Welcher Standard und welche Version genau: HL7 v2 in welcher Version, FHIR R4 (4.0.1) oder R5 (5.0.0)?
  • Welche Nachrichten oder Ressourcen sind tatsächlich implementiert: ADT, ORU, MDM auf der einen Seite; Patient, Observation, DocumentReference auf der anderen?
  • In welche Richtung fliessen die Daten: lesend, schreibend oder beides? Viele Integrationen empfangen nur.
  • Gibt es ein schriftliches Konformitätsprofil, Feld für Feld? Weil HL7 v2 die meisten Felder optional lässt, ist diese Vereinbarung von Standort zu Standort der eigentliche Schnittstellenvertrag.
  • Hat der Anbieter am Digital Health Projectathon von eHealth Suisse, BAG und IHE Suisse getestet? Ein freiwilliger Test, keine Zertifizierung – aber die Teilnahme lässt sich überprüfen.
  • Zum EPD: Implementiert er die geforderten IHE-Profile selbst oder nutzt er einen Konnektor, und mit welcher Gemeinschaft?
  • Wer bezahlt die Schnittstelle, und wer wartet sie, wenn die Spitalsoftware die Version wechselt? Genau dort stecken die vergessenen Kosten.

Transparenz zum Herausgeber dieses Beitrags

Herausgeberin dieses Beitrags ist CareBond, eine Kommunikations- und Koordinationsplattform, die in der Schweiz bei Infomaniak in Genf gehostet wird, von der Architektur her auf DSGVO und revDSG ausgelegt ist und über ein unveränderliches Audit-Log sowie eine HL7/FHIR-Integration verfügt (FHIR-R4-Server, Empfang von HL7-v2-Nachrichten über HTTPS). Sie ist weder eine Stammgemeinschaft noch eine EPD-Plattformanbieterin, und die Herausgeberin hält keine Zertifizierung: Die obenstehenden Fragen gelten für sie wie für alle anderen.

Quellen

Hinweis

Dieser Beitrag ist eine allgemeine Information für Leitungen von Pflegeeinrichtungen und stellt keine Rechtsberatung dar. Die konkreten Pflichten hängen vom Kanton, von der Art der Einrichtung und von der jeweiligen Situation ab, und der rechtliche Rahmen ist in Bewegung: Zum Zeitpunkt der Veröffentlichung hat der Nationalrat das EGDG am 14. September 2026 angenommen, das Geschäft ist im Ständerat hängig. Stützen Sie Entscheide auf die zitierten offiziellen Texte und wenden Sie sich an Ihre kantonale Gesundheitsdirektion, an Ihre Stammgemeinschaft oder an eine Rechtsberatung.

Alle Ressourcen