HL7 MLLP-Protokoll – Überblick

In den 1990er Jahren erlebten wir den Sprung von Bare-Metal-Servern in die Welt der virtuellen Maschinen. Physische Server existieren nach wie vor, weshalb wir in der Regel weiterhin Nachrichten unterstützen müssen, die unser System verlassen oder darin eingehen. Aber wie lässt sich dieser Prozess ein wenig weniger aufwendig gestalten?

In diesem Artikel geben wir Ihnen eine kurze Einführung, die erklärt, wie herkömmliche Bare-Metal-EHR-Netzwerke mit modernen cloudbasierten Gesundheitsanwendungen verbunden werden und wie HL7 v2/v3-Nachrichtenübermittlungen zwischen ihnen mithilfe von MLLP etabliert werden können.

Lesen Sie weiter, um Folgendes zu erfahren:

Was ist HL7 MLLP?
Wie funktioniert eine VPN-Verbindung im Allgemeinen?
Welche Hauptkomponenten werden benötigt, um S2S-VPN-Verbindungen in einer Cloud-Umgebung aufzubauen?

Was ist das MLLP-Protokoll?

MLLP (Minimal Low Layer Protocol) ist ein Protokoll für den HL7-Nachrichtenaustausch. Es besteht aus zwei grundlegenden Elementen:

Übertragung von HL7-Nachrichten über TCP/IP
Rahmung von Anfang und Ende einer HL7-Nachricht

Sicherheit liegt formal außerhalb des Geltungsbereichs von MLLP, aber solange HIPAA nicht geändert wird, sollten Implementierer die Sicherheitsaspekte berücksichtigen. Dies macht den Transport von HL7-Nachrichten über MLLP erheblich komplexer.

Wie stellen wir sichere Verbindungen über MLLP her?

Um eine sichere Kommunikation zu ermöglichen, müssen wir eine verschlüsselte TCP/IP-Verbindung zwischen Sender und Empfänger herstellen. Dies geschieht über eine S2S-VPN-Verbindung (Site-to-Site Virtual Private Network).

Einige weitere Möglichkeiten, HL7-Nachrichten über das Internet (HTTPS) zu senden, umfassen:

Hybrid Lower Layer Protocol (HLLP), eine Variante von MLLP, die zusätzlich die Übertragung einer Prüfsumme erfordert
andere Protokolle, die Daten über TCP/IP übertragen: SOAP, SMTP, S/FTP (standardmäßig nicht HIPAA/DSGVO-konform)

Historische Anmerkung zu ernsthaften technischen Herausforderungen

MLLP wurde in den 1990er Jahren eingeführt. Es war noch eine Ära der Bare-Metal-Server und lokalen Netzwerke mit realen Maschinen und realer Netzwerkhardware. Das Zeitalter des Internets war noch nicht einmal angebrochen.

Das Problem besteht darin, dass wir heutzutage virtuelle Maschinen einsetzen. Unsere Anwendungen werden auf Azure/AWS/Google Cloud Platform mit container-basierten Technologien wie Kubernetes (K8S) und Docker betrieben, sodass wir buchstäblich eine S2S-VPN-Verbindung aus unserem K8S-Netzwerk heraus aufbauen müssen.

S2S VPN aus einem Kubernetes-Cluster: Ist das möglich?

Kurz gesagt: ja. Allerdings sollte man beachten, dass nahezu alle Komponenten, die zur Herstellung einer Verbindung verwendet werden, rein virtuell (logisch) sind. Bei Health Samurai ist es uns gelungen, solche Verbindungen über Microsoft Azure/Amazon AWS/Google Cloud Platform herzustellen.

Was ist eine typische Topologie eines S2S VPN?

mllp hl7 Wir haben zwei lokale Netzwerke, die über eine verschlüsselte VPN-Tunnelverbindung verbunden sind. Das sieht ziemlich einfach aus, oder? Aber der Einsatz virtueller Maschinen erhöht die Komplexität erheblich.

VPN steht für Virtual Private Network. Im Fall von S2S (Site-to-Site) werden zwei Netzwerke zu einem logischen Netzwerk zusammengeführt. Die Verbindung zwischen diesen beiden Netzwerken wird durch die Einrichtung eines Tunnels hergestellt (im Wesentlichen nur ein Paket verschlüsselter Daten). Wir senden unsere HL7-Nachricht über diesen Tunnel an das EHR.

Wie sieht eine typische Cloud-S2S-VPN-Verbindung aus? Spoiler: Es ist etwas komplizierter

Wie bereits erwähnt, haben wir bei Cloud-Netzwerken zusätzliche Komplexitätsebenen. Wir haben ein virtuelles Netzwerk mit einer virtuellen Maschine darin, und diese erreicht das äußere Internet irgendwie über eine öffentliche IP-Adresse. Das passiert in der Regel: mllp protocol Keine Sorge, wir erklären alles im Detail:

Anwendung

Unsere Anwendung ist lediglich ein K8S-Cluster-Pod mit einer privaten (virtuellen) IP-Adresse. Diese IP-Adresse existiert innerhalb des virtuellen Subnetzes.

Virtuelles Subnetz

Das virtuelle Subnetz ist ein Teil des gesamten virtuellen Netzwerks innerhalb unseres Kubernetes-Clusters. Wenn ein Cluster also viele IP-Adressen hat, verwendet das virtuelle Netzwerk wahrscheinlich die erforderliche Anzahl an Adressen aus diesem Netzwerk.

Virtuelles Netzwerk

Das virtuelle Netzwerk ist eine rein logische Einheit. Es handelt sich um ein Netzwerk mit einem bestimmten Bereich privater IP-Adressen. Alle Entitäten in solchen virtuellen Netzwerken sind über Software verbunden, nicht über reale Kabelverbindungen.

Wie stellt ein Pod in einem privaten Netzwerk Anfragen an das äußere Internet (und andere Netzwerke)?

Wie oben ersichtlich, geschieht dies über:

ein virtuelles privates Gateway (andere Netzwerke)
ein Internet-Gateway (Internet)

Wie entscheide ich, ob unsere Verbindung ins Internet oder in das lokale Netzwerk gehen soll?

Dies wird über Routing-Tabellen gesteuert.

Routing-Tabelle

Routing-Tabellen sind lediglich eine Reihe von Regeln, die festlegen, wohin der Datenverkehr gehen soll. In unserem Fall sind die Routing-Tabellen wie folgt konfiguriert:

alle Verbindungen zum EHR-Netzwerk werden an das EHR-Netzwerk weitergeleitet
alle anderen Verbindungen gehen ins Internet

Wie können äußere Netzwerke auf den Pod zugreifen?

Wenn äußere Netzwerke mit dem Pod-Netzwerk verbunden sind, kann auf den Pod über seine private IP-Adresse zugegriffen werden. Eine VPN-Verbindung erleichtert es tatsächlich, zwei Netzwerke zu einem zusammenzuführen.

Wie kann eine VPN-Verbindung hergestellt werden, wenn der Pod der Initiator ist?

Der Pod sendet eine Anfrage an die IP-Adresse des EHR-Netzwerks.
Die Anfrage geht zur Routing-Tabelle, die besagt, dass der nächste Hop der Verbindung ein VPG (Virtual Private Gateway) ist.
Das VPG initiiert den VPN-Tunnel mit der anderen Maschine.

Möchten Sie Ihre Einrichtung optimieren? Sprechen Sie mit unseren Spezialisten für maßgeschneiderte Lösungen. Kontakt aufnehmen

Wie funktioniert der VPN-Tunnel genau?

Hier erläutern wir, wie die IPSEC-Verbindung aufgebaut wird. Es gibt eine Reihe von VPN-Protokollen:

Layer 2 Tunneling Protocol (L2TP)
Point-to-Point Tunneling Protocol (PPTP)
SSL und TLS
Secure Shell (SSH)
OpenVPN
WireGuard

Unserer Erfahrung nach ist IPSEC die häufigste Methode zur Übertragung von HL7-Datenverkehr über MLLP.

IPSEC umfasst tatsächlich eine Gruppe von Protokollen, die zur Herstellung der Verbindung verwendet werden:

Internet Key Exchange (IKE)
Authentication Header (AH)
Encapsulating Security Payload (ESP)

Jedes der oben genannten Protokolle kann auch als ein Schritt zum Aufbau der Verbindung betrachtet werden:

wir stellen sicher, dass die Verbindung zwischen den richtigen Parteien hergestellt wird
wir einigen uns auf den Verschlüsselungstyp
wir stellen sicher, dass die Daten nicht abgefangen oder verändert wurden

Wie einigen wir uns auf den Verschlüsselungstyp?

Das zweiphasige IKE-Protokoll hilft dabei, einen sicheren und authentifizierten Kommunikationskanal aufzubauen. Die häufigsten Methoden zur Einigung auf Verschlüsselungsalgorithmen umfassen:

Austausch eines Pre-Shared Key (PSK)
signaturbasierte Authentifizierung
Public-Key-Verschlüsselung

Dies wird als IKE-Phase 1 bezeichnet. Es ist die Phase, in der beide Parteien sicher sind, dass die Verbindung von den richtigen Parteien initiiert wurde, und in der sie genau besprechen können, wie die Daten verschlüsselt werden.

Normalerweise sind drei Schritte erforderlich, um die IKE-Phase 1 zu durchlaufen:

Austausch anwendbarer Verschlüsselungsregeln (SHA, Diffie-Hellman usw.)
Austausch des offenen Teils der Diffie-Hellman-Daten (DH) und Hilfsdaten
Bestätigung der Ergebnisse des DH-Austauschs

Was ist IKE-Phase 2? IKE-Phase 2 ist die Hauptphase der Verbindung, in der die Benutzerdatenübertragung stattfindet.

Wir werden AH und ESP hier nicht im Detail behandeln, da sie nach denselben Prinzipien wie das IKE-Protokoll betrieben werden und demselben Zweck dienen. Es gibt jedoch noch einige Punkte, die man sich merken sollte:

Kommunikation ist lediglich ein Austausch von Datenpaketen (IP-Paketen).
Jedes Sicherheitsprotokoll fügt dem ursprünglichen IP-Paket zusätzliche Daten (Header) hinzu.
Dies geschieht, indem ein Datenelement durch Verschlüsselung in ein anderes eingebettet wird.
Die Entschlüsselung der Daten erfolgt auf der Empfängerseite.

Fazit

Zusammenfassend lässt sich sagen:

MLLP ist eine alte, aber lebensfähige Technologie zur Übertragung von HL7-Nachrichten über das Internet und lokale Netzwerke.
Sie müssen die Sicherheit bei der Übertragung von Nachrichten über MLLP berücksichtigen und Technologien einsetzen, um dieses Ziel zu erreichen (wie VPN oder SFTP).
VPN-Verbindungen können problemlos zwischen dem On-Premises-Netzwerk und der Cloud-Infrastruktur (AWS/GCP/Azure) mithilfe virtueller Entitäten hergestellt werden.
Aus Anwendungssicht unterscheidet sich die Datenübertragung über VPN nicht von jeder anderen Datenübertragung über TCP.

Für produktive HL7 v2-zu-FHIR-Pipelines, bei denen Sie eine dauerhafte Warteschlange, Mapping-as-Code und eine Dead-Letter-Queue zusätzlich zum oben beschriebenen MLLP-Transport benötigen, lesen Sie unseren Artikel zur Healthcare-Integrationsengine Interbox.

Wenn Sie versuchen, eine VPN-Verbindung für Ihren HL7-Feed in einer Cloud-Umgebung herzustellen und nicht weiterkommen, sprechen Sie uns an – wir zeigen Ihnen gerne, wie es funktioniert.

Um die Einrichtung von HL7-Messaging über MLLP mit einem VPN in Ihrer Umgebung zu erkunden, sollten Sie die kostenlose Version von Aidbox in Betracht ziehen. Sie bietet eine sichere und voll funktionsfähige Umgebung zum Testen dieser Konfigurationen und stellt alle notwendigen Werkzeuge ohne Einschränkungen zur Verfügung.

Autoren: Artem Alexeev, Viktor Gusakov

Möchten Sie die Übertragung und Speicherung Ihrer EHR-Daten auf die nächste Stufe heben? Wir empfehlen, unser steckbares Aidbox FHIR API-Modul zu nutzen. Es ist ONC-zertifiziert und bietet eine API zur nahtlosen Aufnahme und Verarbeitung von HL7® v2-Nachrichten. Aidbox ist bestens positioniert, um als nächste Instanz für HIPAA-Compliance zu dienen – und Ihre Mitbewerber haben diesen Schritt wahrscheinlich noch nicht vollzogen.

Siehe auch: Umgang mit der Integration von Legacy-Systemen und Aidbox und MatrixCare EHR-Integration.