Elektronisches Patientendossier

HL7 zu FHIR.
Mit Bridgelink.

Wie Spitaeler ihre bestehenden HL7v2-Systeme ueber Bridgelink an einen zentralen FHIR R4 Server anbinden koennen – ohne eigenen Gateway zu bauen.

Das Problem: Eigener Gateway vs. fertige Loesung

Warum ein selbstgebauter Gateway bei der EPD-Integration an seine Grenzen stoesst

Eigener Gateway

  • ✗  HL7v2-Parsing selbst implementieren
  • ✗  FHIR-Mapping manuell programmieren
  • ✗  Fehlerbehandlung & Retry-Logik bauen
  • ✗  Monitoring & Logging entwickeln
  • ✗  Jedes Spital = neuer Aufwand
  • ✗  Wartung, Updates, Bugfixes – alles intern
  • ✗  Monate Entwicklungszeit

Bridgelink + FHIR Server

  • ✓  HL7v2 nativ unterstuetzt (TCP/MLLP)
  • ✓  FHIR-Mapping per JavaScript-Transformer
  • ✓  Retry, Queuing & Error-Handling eingebaut
  • ✓  Dashboard zeigt jede Nachricht in Echtzeit
  • ✓  Neues Spital = neuer Channel, fertig
  • ✓  Industriestandard, gepflegt von Innovar Healthcare
  • ✓  Proof of Concept in Tagen statt Monaten

Warum FHIR als zentraler Standard?

Die meisten Schweizer Spitaeler senden heute HL7v2 – ein Format aus den 90er-Jahren, pro Spital unterschiedlich implementiert. Das EPD verlangt aber einen einheitlichen, modernen Standard: FHIR R4 (Fast Healthcare Interoperability Resources).

FHIR ist REST-basiert (wie jede moderne Web-API), nutzt JSON, und definiert klare Ressourcen-Typen wie Patient, Encounter und Observation. Jedes System, das FHIR spricht, kann sofort auf die Daten zugreifen – ohne individuelle Schnittstellen-Anpassung.

Spital sendet
HL7v2 (ADT, ORU, ORM) – wie bisher, kein Umbau noetig
Bridgelink transformiert
HL7v2 → FHIR R4, automatisch, pro Nachricht, mit Monitoring
FHIR Server speichert
Zentrale Datenhaltung, REST API, jederzeit abrufbar

Live-System – Online Zugang

FHIR Server (UI) fhir.algorithma-dev.ch  (Web-Oberflaeche mit Suchfunktion)
Bridgelink Admin bridgelink.algorithma-dev.ch
Bridgelink Login admin / admin
Demo-Seite epd.algorithma-dev.ch
Schnellzugriff FHIR-Daten:
Alle Patienten Alle Encounters Alle Observations HAPI Tester UI

FHIR Server und Bridgelink erfordern laufende Docker-Container mit Cloudflare Tunnel. Demo-Seite ist permanent unter epd.algorithma-dev.ch erreichbar.

Architektur

Vom Spital-KIS bis zum EPD – der komplette Datenfluss

Spital A

KIS / PIS System

HL7v2

Spital B

KIS / PIS System

HL7v2

Spital C

KIS / PIS System

HL7v2
ADT, ORU, ORM ...

Bridgelink

Integration Engine
Empfang (TCP/HTTP)
Transformation
Routing
Monitoring
FHIR R4 Bundles (REST API)

FHIR R4 Server

Zentrale Datenhaltung (HAPI FHIR)
Patient Encounter Observation DocumentReference Condition
FHIR REST API / IHE MHD

EPD Gemeinschaft

Zugriff auf Patientendaten

FHIR R4

Andere Spitäler

Dossier einsehen

FHIR R4

Zuweiser / Hausarzt

Befunde abrufen

FHIR R4

Patient

Eigenes Dossier

FHIR R4

HL7v2 → FHIR Mapping

So werden bestehende HL7v2-Nachrichten in standardisierte FHIR-Ressourcen transformiert

Patient-Aufnahme

Patient wird ins Spital aufgenommen
ADT^A01

HL7v2 Segmente

MSH
MSH.9 Nachrichtentyp MSH.10 Message-ID
PID
PID.3 Patienten-ID PID.5 Name PID.7 Geburtsdatum PID.8 Geschlecht
PV1
PV1.3 Station PV1.7 Arzt PV1.44 Aufnahmedatum
PID Patient
PV1 Encounter

FHIR R4 Ressourcen

Patient
identifier Patienten-ID name Vor-/Nachname birthDate Geburtsdatum gender Geschlecht
Encounter
status in-progress class IMP (stationär) subject → Patient period.start Aufnahme location Station
HL7v2 Nachricht
MSH|^~\&|KIS|SPITAL_BERN|EPD||202603281400||ADT^A01|MSG001|P|2.5 PID|1||PAT001^^^SPITAL^MR||Mueller^Anna||19850315|F PV1|1|I|CHIRURGIE^^^^||DR.MEIER|||||||||||||||||||||||||202603281400
FHIR R4 Bundle
{ "resourceType": "Bundle", "type": "transaction", "entry": [{ "resource": { "resourceType": "Patient", "name": [{"family":"Mueller","given":["Anna"]}], "gender": "female", "birthDate": "1985-03-15" } }, { "resource": { "resourceType": "Encounter", "status": "in-progress", "location": [{"display":"CHIRURGIE"}] } }] }

Patient-Entlassung

Patient wird aus dem Spital entlassen, Aufenthalt wird abgeschlossen
ADT^A03

HL7v2 Segmente

PID
PID.3 Patienten-ID PID.5 Name
PV1
PV1.44 Aufnahmedatum PV1.45 Entlassungsdatum
PID Patient
PV1 Encounter

FHIR R4 Ressourcen

Patient
Gleiche Struktur wie bei Aufnahme
Encounter
status finished period.start Aufnahme period.end Entlassung

Laborbefund

Laborergebnisse wie Glucose, Hämoglobin oder CRP
ORU^R01

HL7v2 Segmente

PID
PID.3 Patienten-ID PID.5 Name
OBR
OBR.4 Untersuchungscode OBR.7 Zeitpunkt
OBX
OBX.3 Labortest-Code OBX.5 Messwert OBX.6 Einheit OBX.7 Referenzbereich
PID Patient (Ref)
OBX Observation

FHIR R4 Ressourcen

Observation
code LOINC-Code valueQuantity Wert + Einheit referenceRange Normbereich subject → Patient status final category laboratory
HL7v2 Nachricht
MSH|^~\&|LABOR|SPITAL_BERN|EPD||202603281400||ORU^R01|MSG042|P|2.5 PID|1||PAT001^^^SPITAL^MR||Mueller^Anna||19850315|F OBR|1||ORD1234|GLU^Glucose^LN|||202603281400 OBX|1|NM|GLU^Glucose^LN||5.8|mmol/L|3.9-5.8|N|||F
FHIR R4 Observation
{ "resourceType": "Observation", "status": "final", "code": { "coding": [{"system":"http://loinc.org", "code":"GLU","display":"Glucose"}] }, "valueQuantity": { "value": 5.8, "unit": "mmol/L" }, "referenceRange": [{ "low": {"value":3.9}, "high": {"value":5.8} }], "subject": {"reference":"Patient/PAT001"} }

Bridgelink statt Eigenentwicklung

Warum eine fertige Integration Engine die bessere Wahl ist

Wochen statt Monate

Einen eigenen Gateway zu bauen und zu warten kostet Monate. Mit Bridgelink: Channel konfigurieren, Mapping definieren, läuft.

Monitoring ohne Aufwand

Bei Eigenentwicklung muss Logging und Fehlerbehandlung selbst gebaut werden. Bridgelink zeigt jede Nachricht, jeden Fehler, sofort.

Einfach erweiterbar

Neues Spital anbinden? Neuen Nachrichtentyp unterstützen? Ein Channel dazu – ohne am bestehenden Code etwas zu ändern.

EPD-konform

Eigene Gateways müssen EPD-Standards selbst implementieren. Bridgelink bringt HL7v2, FHIR R4 und IHE-Profile von Haus aus mit.

Skaliert mit jedem Spital

Ein eigener Gateway wird mit jedem neuen Spital komplexer. Bridgelink: ein Channel pro Spital, voneinander unabhaengig.

Kein KIS-Umbau nötig

Spitäler senden HL7v2 wie bisher. Die ganze Transformation passiert in Bridgelink – das KIS merkt keinen Unterschied.

PDF-Dokumente ins EPD

Austrittsberichte, Befunde und andere Dokumente als FHIR DocumentReference speichern

Austrittsbericht als PDF

Ein Spital will einen PDF-Bericht im EPD ablegen
DocumentReference

Quell-Dokument

PDF-Datei
Austrittsbericht.pdf Klinischer Bericht
Metadaten
Patient Zuordnung Datum Erstellungsdatum Autor Behandelnder Arzt Typ Dokumentenklasse
PDF Base64
Meta DocRef

FHIR R4 Ressource

DocumentReference
status current type LOINC 18842-5 subject → Patient author → Arzt date Erstellungsdatum content.attachment Base64 PDF
Ablauf
1. Spital erstellt PDF-Austrittsbericht 2. KIS sendet PDF + Metadaten an Bridgelink 3. Bridgelink kodiert PDF als Base64 4. Bridgelink erstellt DocumentReference 5. POST an FHIR Server 6. Dokument ist im EPD abrufbar
FHIR DocumentReference
{ "resourceType": "DocumentReference", "status": "current", "type": {"coding": [{ "code": "18842-5", "display": "Discharge summary" }]}, "subject": {"reference": "Patient/PAT001"}, "author": [{"display": "Dr. Meier"}], "content": [{ "attachment": { "contentType": "application/pdf", "data": "JVBERi0xLjQK...", "title": "Austrittsbericht.pdf" } }] }

Selber ausprobieren

HL7-Nachrichten generieren, PDF hochladen und FHIR-Daten abfragen – direkt hier

-
Patienten
-
Encounters
-
Observations
-
Dokumente
HL7-Nachricht senden
Nachrichtentyp
Patient
Bereit. Waehle einen Typ und klicke "Nachricht senden".
PDF-Dokument hochladen

PDF hierher ziehen oder klicken

Max. 10 MB
Zuordnung
PDF-Datei wählen und Patient zuordnen.
FHIR-Daten abfragen
Waehle eine Abfrage und klicke "Abfragen".