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 in unser System ein- und ausgehen. Doch wie lässt sich dieser Prozess etwas weniger aufwendig gestalten?

In diesem Artikel geben wir Ihnen einen kurzen Überblick darüber, wie sich veraltete Bare-Metal-EHR-Lokalnetzwerke mit modernen cloudbasierten Gesundheitsanwendungen verbinden lassen und wie HL7 v2/v3-Nachrichtenaustausche zwischen diesen mithilfe von MLLP eingerichtet 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 setzt sich aus zwei grundlegenden Elementen zusammen:

Übertragung von HL7-Nachrichten über TCP/IP
Rahmenbildung für den Anfang und das Ende einer HL7-Nachricht

Sicherheit liegt formal außerhalb des Geltungsbereichs von MLLP. Solange HIPAA jedoch nicht geändert wird, sollten Implementierende die Sicherheitsaspekte berücksichtigen. Dies macht die Übertragung 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 aufbauen. Dies geschieht über eine S2S-VPN-Verbindung (Site-to-Site Virtual Private Network).

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 ernsten technischen Herausforderungen

MLLP wurde in den 1990er Jahren eingeführt. Es war noch die Ära der Bare-Metal-Server und Lokalnetzwerke mit realen Maschinen und echter Netzwerkhardware. Das Internetzeitalter hatte noch nicht einmal begonnen.

Das Problem besteht darin, dass wir heutzutage virtuelle Maschinen verwenden. Unsere Anwendungen werden auf Azure/AWS/Google Cloud Platform mithilfe containerbasierter Technologien wie Kubernetes (K8S) und Docker bereitgestellt, 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 ist zu beachten, dass nahezu alle Komponenten, die zum Aufbau 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.

Wie sieht eine typische S2S-VPN-Topologie aus?

mllp hl7 Wir haben zwei Lokalnetzwerke, die über eine verschlüsselte VPN-Tunnelverbindung miteinander verbunden sind. Das sieht recht einfach aus, nicht wahr? Die Verwendung virtueller Maschinen erhöht jedoch die Komplexität.

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 den Aufbau eines Tunnels hergestellt (im Grunde genommen 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: Sie ist etwas komplexer

Wie bereits erwähnt, haben wir im Fall von Cloud-Netzwerken zusätzliche Komplexitätsstufen. Wir verfügen über ein virtuelles Netzwerk mit einer virtuellen Maschine darin, und diese erreicht das externe 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 über viele IP-Adressen verfügt, wird das virtuelle Netzwerk wahrscheinlich die erforderliche Anzahl an Adressen aus diesem Netzwerk verwenden.

Virtuelles Netzwerk

Das virtuelle Netzwerk ist eine rein logische Einheit. Es handelt sich um ein Netzwerk mit einem bestimmten Bereich privater IP-Adressen. Alle Einheiten innerhalb solcher virtuellen Netzwerke sind über Software verbunden, anstatt über echte kabelgebundene Verbindungen.

Wie kann ein Pod in einem privaten Netzwerk Anfragen an das externe Internet (und andere Netzwerke) stellen?

Wie oben zu sehen ist, erfolgt dies über:

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

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

Dies wird über Routentabellen gesteuert.

Routentabelle

Routentabellen sind lediglich eine Reihe von Regeln, die festlegen, wohin der Datenverkehr geleitet werden soll. In unserem Fall sind die Routentabellen wie folgt konfiguriert:

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

Wie können externe Netzwerke auf den Pod zugreifen?

Wenn externe Netzwerke mit dem Pod-Netzwerk verbunden sind, kann auf den Pod über seine private IP-Adresse zugegriffen werden. Eine VPN-Verbindung erleichtert tatsächlich die Zusammenführung zweier Netzwerke zu einem.

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

Der Pod sendet eine Anfrage an die IP-Adresse des EHR-Netzwerks.
Die Anfrage geht an die Routentabelle und gibt an, 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

Nach unserer Erfahrung ist IPSEC die gängigste Methode zur Übertragung von HL7-Datenverkehr über MLLP.

IPSEC umfasst tatsächlich eine Gruppe von Protokollen, die zum Aufbau 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 beim Verbindungsaufbau betrachtet werden:

wir stellen sicher, dass die Verbindung zwischen den richtigen Parteien aufgebaut 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 beim Aufbau eines sicheren und authentifizierten Kommunikationskanals. Die gängigsten Methoden zur Einigung auf Verschlüsselungsalgorithmen umfassen:

Austausch von Pre-Shared Keys (PSK)
signaturbasierte Authentifizierung
Verschlüsselung mit öffentlichem Schlüssel

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

In der Regel sind drei Schritte erforderlich, um IKE-Phase 1 abzuschließen:

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

Was ist IKE-Phase 2? IKE-Phase 2 ist die Hauptphase der Verbindung, in der die Nutzerdatenü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 einige Punkte, die man im Gedächtnis behalten 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 durch das Einschließen eines Datenelements in ein anderes mittels Verschlüsselung.
Die Entschlüsselung der Daten erfolgt auf der Empfängerseite.

Fazit

Zusammenfassend lässt sich sagen:

MLLP ist eine alte, aber funktionsfähige Technologie zur Übertragung von HL7-Nachrichten über das Internet und lokale Netzwerke.
Bei der Übertragung von Nachrichten über MLLP müssen Sie Sicherheitsaspekte berücksichtigen und entsprechende Technologien einsetzen (wie VPN oder SFTP).
VPN-Verbindungen lassen sich mithilfe virtueller Einheiten problemlos zwischen einem On-Premises-Netzwerk und einer Cloud-Infrastruktur (AWS/GCP/Azure) herstellen.
Aus Anwendungssicht unterscheidet sich die Datenübertragung über VPN nicht von jeder anderen Datenübertragung über TCP.

Wenn Sie versuchen, eine VPN-Verbindung für Ihren HL7-Feed in einer Cloud-Umgebung einzurichten, 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, empfehlen wir die Verwendung der kostenlosen Version von Aidbox. Sie bietet eine sichere und voll funktionsfähige Umgebung zum Testen dieser Konfigurationen und stellt alle erforderlichen Werkzeuge ohne Einschränkungen zur Verfügung.

Autoren: Artem Alexeev, Viktor Gusakov

Möchten Sie Ihre EHR-Datenübertragung und -speicherung auf die nächste Stufe heben? Wir empfehlen, unser einbettbares Aidbox FHIR API-Modul zu nutzen. Es ist ONC-zertifiziert und stellt eine API zur nahtlosen Aufnahme und Verarbeitung von HL7® v2-Nachrichten bereit. Aidbox ist bestens positioniert, um als nächste Stufe der 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.