Aperçu du protocole HL7 MLLP

Dans les années 1990, nous avons assisté au passage des serveurs physiques au monde des machines virtuelles. Les serveurs physiques existent toujours, ce qui signifie que nous devons généralement encore prendre en charge les messages entrant et sortant de nos systèmes. Mais comment rendre ce processus un peu moins stressant?

Dans cet article, nous vous proposons un tour d'horizon expliquant comment connecter les réseaux locaux de DSÉ sur des serveurs physiques classiques aux applications de santé modernes hébergées dans le nuage, et comment établir des échanges de messages HL7 v2/v3 entre eux à l'aide du protocole MLLP.

Continuez la lecture pour découvrir :

Qu'est-ce que HL7 MLLP?
Comment fonctionne une connexion VPN en général?
Quels sont les principaux éléments nécessaires pour établir des connexions VPN S2S dans un environnement infonuagique?

Qu'est-ce que le protocole MLLP?

MLLP (Minimal Low Layer Protocol) est un protocole d'échange de messages HL7. Il est composé de deux éléments de base :

la transmission de messages HL7 via TCP/IP
le cadrage du début et de la fin d'un message HL7

La sécurité est formellement hors du périmètre du MLLP, mais tant que HIPAA n'est pas modifié, les développeurs doivent tenir compte des enjeux de sécurité. Cela rend le transport des messages HL7 via MLLP considérablement plus complexe.

Comment établir des connexions sécurisées avec MLLP?

Pour permettre une communication sécurisée, nous devons établir une connexion TCP/IP chiffrée entre l'expéditeur et le destinataire. Cela se fait par le biais d'une connexion VPN S2S (réseau privé virtuel de site à site).

Parmi les autres méthodes d'envoi de messages HL7 sur Internet (HTTPS), on trouve :

le protocole hybride de couche inférieure (HLLP), une variante du MLLP qui exige en plus la transmission d'une somme de contrôle
d'autres protocoles qui transmettent des données via TCP/IP : SOAP, SMTP, S/FTP (non conformes à HIPAA/RGPD par défaut)

Note historique sur de sérieux défis techniques

Le MLLP a été introduit dans les années 1990. C'était encore l'ère des serveurs physiques et des réseaux locaux avec de véritables machines et du matériel réseau réel. L'ère d'Internet n'était même pas encore arrivée.

Le problème, c'est qu'aujourd'hui nous avons tendance à utiliser des machines virtuelles. Nos applications sont déployées sur Azure/AWS/Google Cloud Platform à l'aide de technologies basées sur les conteneurs comme Kubernetes (K8S) et Docker, de sorte que nous devons littéralement établir une connexion VPN S2S depuis notre réseau K8S.

VPN S2S depuis un cluster Kubernetes : est-ce possible?

En bref, oui. Cependant, il faut noter que presque toutes les entités utilisées pour établir une connexion seront purement virtuelles (logiques). Chez Health Samurai, nous avons réussi à établir de telles connexions en utilisant Microsoft Azure, Amazon AWS et Google Cloud Platform.

Quelle est la topologie habituelle d'un VPN S2S?

mllp hl7 Nous avons deux réseaux locaux connectés via un tunnel VPN chiffré. Ça semble assez simple, non? Mais l'utilisation de machines virtuelles ajoute une certaine complexité.

VPN signifie réseau privé virtuel. Dans le cas du S2S (site à site), il fusionne deux réseaux en un seul réseau logique. La connexion entre ces deux réseaux est établie en créant un tunnel (qui n'est en réalité qu'un ensemble de données chiffrées). Nous enverrons notre message HL7 au DSÉ via ce tunnel.

À quoi ressemble une connexion VPN S2S infonuagique habituelle? Avertissement : c'est un peu plus compliqué

Comme nous l'avons mentionné précédemment, dans le cas des réseaux infonuagiques, nous avons des niveaux de complexité supplémentaires. Nous avons un réseau virtuel avec une machine virtuelle à l'intérieur, qui accède d'une façon ou d'une autre à Internet externe via une adresse IP publique. Voici ce qui se passe habituellement : mllp protocol Ne vous inquiétez pas, nous allons tout expliquer en détail :

Application

Notre application n'est qu'un pod de cluster K8S avec une adresse IP privée (virtuelle). Cette adresse IP existe à l'intérieur du sous-réseau virtuel.

Sous-réseau virtuel

Le sous-réseau virtuel fait partie du réseau virtuel global à l'intérieur de notre cluster Kubernetes. Ainsi, si un cluster dispose d'un grand nombre d'adresses IP, le réseau virtuel utilisera probablement le nombre requis d'adresses de ce réseau.

Réseau virtuel

Le réseau virtuel est une entité purement logique. C'est un réseau avec une certaine plage d'adresses IP privées. Toutes les entités à l'intérieur de ces réseaux virtuels sont connectées par logiciel, plutôt que par de vraies connexions filaires.

Comment un pod situé dans un réseau privé effectue-t-il des requêtes vers Internet externe (et d'autres réseaux)?

Comme vous pouvez le voir ci-dessus, cela se fait via :

une passerelle privée virtuelle (autres réseaux)
une passerelle Internet (Internet)

Comment décider si notre connexion doit aller vers Internet ou vers le réseau local?

Cela se fait via des tables de routage.

Table de routage

Les tables de routage sont simplement un ensemble de règles déterminant où le trafic doit se diriger. Dans notre cas, les tables de routage sont configurées comme suit :

toutes les connexions établies vers le réseau du DSÉ sont acheminées vers ce réseau
toutes les autres connexions sont acheminées vers Internet

Comment les réseaux externes peuvent-ils se connecter au pod?

Si des réseaux externes sont connectés au réseau du pod, le pod est accessible via son adresse IP privée. Une connexion VPN facilite effectivement la connexion de deux réseaux en un seul.

Comment établir une connexion VPN si le pod est l'initiateur?

Le pod envoie une requête à l'adresse IP du réseau du DSÉ.
La requête passe par la table de routage et indique que le prochain saut de la connexion est une VPG (passerelle privée virtuelle).
La VPG déclenche le tunnel VPN avec l'autre machine.

Vous souhaitez simplifier votre configuration? Parlez à nos spécialistes pour des solutions adaptées à vos besoins. Nous contacter

Comment fonctionne exactement le tunnel VPN?

Nous allons ici expliquer comment la connexion IPSEC est établie. Il existe un certain nombre de protocoles VPN :

Protocole de tunnelisation de couche 2 (L2TP)
Protocole de tunnelisation point à point (PPTP)
SSL et TLS
Secure Shell (SSH)
OpenVPN
WireGuard

D'après notre expérience, IPSEC est la méthode la plus courante pour transmettre du trafic HL7 via MLLP.

IPSEC comprend en réalité un groupe de protocoles utilisés pour établir la connexion :

Échange de clés Internet (IKE)
En-tête d'authentification (AH)
Charge utile de sécurité encapsulante (ESP)

Chacun des protocoles mentionnés ci-dessus peut également être considéré comme une étape pour établir la connexion :

nous nous assurons que la connexion est établie entre les bonnes parties
nous nous mettons d'accord sur le type de chiffrement
nous nous assurons que les données n'ont pas été interceptées ou modifiées

Comment nous mettons-nous d'accord sur le type de chiffrement?

Le protocole IKE en deux phases permet d'établir un canal de communication sécurisé et authentifié. Les méthodes les plus courantes pour s'entendre sur les algorithmes de chiffrement sont :

l'échange de clé prépartagée (PSK)
l'authentification par signature
le chiffrement à clé publique

C'est ce qu'on appelle la phase 1 d'IKE. C'est l'étape où les deux parties s'assurent que la connexion a été initiée par les bonnes parties et sont en mesure de discuter exactement de la façon dont les données seront chiffrées.

En général, trois étapes sont nécessaires pour passer la phase 1 d'IKE :

échange des règles de chiffrement applicables (SHA, Diffie-Hellman, etc.)
échange de la partie ouverte des données Diffie-Hellman (DH) et des données auxiliaires
confirmation des résultats de l'échange DH

Qu'est-ce que la phase 2 d'IKE? La phase 2 d'IKE est la phase principale de la connexion, durant laquelle la transmission des données utilisateur s'effectue.

Nous n'aborderons pas AH et ESP en détail ici, car ils fonctionnent selon les mêmes principes que le protocole IKE et servent le même objectif. Il y a tout de même plusieurs points à retenir :

La communication n'est qu'un échange de paquets de données (paquets IP).
Chaque protocole de sécurité ajoute des données supplémentaires (en-têtes) au paquet IP d'origine.
Cela se fait en encapsulant une donnée dans une autre par le biais du chiffrement.
Le déchiffrement des données s'effectue du côté du destinataire.

Conclusion

En résumé, on peut dire que :

Le MLLP est une technologie ancienne mais viable pour transmettre des messages HL7 sur Internet et les réseaux locaux.
Vous devez tenir compte de la sécurité lors de la transmission de messages via MLLP et utiliser des technologies pour atteindre cet objectif (comme VPN ou SFTP).
Les connexions VPN peuvent être facilement établies entre le réseau sur site et l'infrastructure infonuagique (AWS/GCP/Azure) à l'aide d'entités virtuelles.
Du point de vue de l'application, la transmission de données via VPN ne diffère pas d'une autre transmission de données utilisant TCP.

Pour les pipelines HL7 v2 vers FHIR en production où vous avez besoin d'une file d'attente durable, d'un mappage sous forme de code et d'une file de lettres mortes par-dessus le transport MLLP décrit ci-dessus, consultez notre moteur d'intégration en santé Interbox.

Si vous essayez d'établir une connexion VPN pour votre flux HL7 dans un environnement infonuagique et que vous êtes bloqué, contactez-nous et nous serons heureux de vous montrer comment cela fonctionne.

Pour explorer la configuration de la messagerie HL7 via MLLP avec un VPN dans votre environnement, envisagez d'utiliser la version gratuite d'Aidbox. Elle offre un environnement sécurisé et entièrement fonctionnel pour tester ces configurations, en fournissant tous les outils nécessaires sans aucune limitation.

Auteurs : Artem Alexeev, Viktor Gusakov

Vous souhaitez amener la transmission et le stockage de vos données de DSÉ à un niveau supérieur? Nous vous recommandons de profiter de notre module d'API FHIR Aidbox enfichable. Il est certifié ONC et fournit une API pour ingérer et traiter les messages HL7® v2 de façon transparente. Aidbox est bien positionné pour constituer la prochaine frontière de la conformité à HIPAA, et vos concurrents n'y sont probablement pas encore parvenus.

Voir aussi : Relever le défi de l'intégration des systèmes patrimoniaux et Intégration d'Aidbox et du DSÉ MatrixCare.