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, si bien que nous devons généralement encore prendre en charge les messages entrants et sortants de notre système. Mais comment rendre ce processus un peu moins contraignant?

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

Continuez à lire pour découvrir :

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

Qu'est-ce que le protocole MLLP?

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

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 de la portée du MLLP, mais tant que HIPAA n'est pas modifié, les implémenteurs doivent tenir compte des enjeux de sécurité. Cela rend le transport des messages HL7 via MLLP beaucoup 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 via une connexion VPN S2S (réseau privé virtuel de site à site).

Parmi les autres façons d'envoyer des messages HL7 sur Internet (HTTPS), on trouve :

le Hybrid Lower Layer Protocol (HLLP), une variante du MLLP qui exige en outre 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 les défis techniques majeurs

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 vraies machines et du vrai matériel réseau. 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 des conteneurs comme Kubernetes (K8S) et Docker, ce qui nous oblige 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 convient de 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 courante 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 d'un VPN 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 (en réalité, simplement un paquet de données chiffrées). Nous enverrons notre message HL7 vers l'EHR via ce tunnel.

À quoi ressemble habituellement une connexion VPN S2S dans le nuage? En aparté : c'est un peu plus compliqué

Comme nous l'avons mentionné, dans le cas des réseaux infonuagiques, nous avons des niveaux de complexité supplémentaires. Nous disposons d'un réseau virtuel avec une machine virtuelle à l'intérieur, qui accède d'une manière ou d'une autre à Internet 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 est simplement 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 est une partie de l'ensemble du réseau virtuel à l'intérieur de notre cluster Kubernetes. Ainsi, si un cluster dispose de nombreuses 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. Il s'agit d'un réseau avec une plage d'adresses IP privées déterminée. Toutes les entités à l'intérieur de ces réseaux virtuels sont connectées par logiciel, plutôt que par de vraies connexions câblées.

Comment un pod situé dans un réseau privé effectue-t-il des requêtes vers Internet (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éterminer si notre connexion doit passer par Internet ou 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 être acheminé. Dans notre cas, les tables de routage sont configurées comme suit :

toutes les connexions destinées au réseau EHR sont acheminées vers le réseau EHR
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 en fait la fusion de deux réseaux en un seul.

Comment une connexion VPN peut-elle être établie si le pod est l'initiateur?

Le pod envoie une requête à l'adresse IP du réseau EHR.
La requête passe par la table de routage, qui 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 voulez simplifier votre configuration? Parlez à nos spécialistes pour des solutions adaptées à vos besoins. Nous contacter

Comment fonctionne exactement le tunnel VPN?

Ici, nous expliquerons comment la connexion IPSEC est établie. Il existe un certain nombre de protocoles VPN :

Layer 2 Tunneling Protocol (L2TP)
Point–to–Point Tunneling Protocol (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 :

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

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

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

Comment se mettre d'accord sur le type de chiffrement?

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

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

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

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

échange des règles de chiffrement applicables (SHA, Diffie–Hellman, etc.)
échange de la partie publique 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, au cours de laquelle la transmission des données utilisateur s'effectue.

Nous ne couvrirons 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 quelques points importants à 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é, nous pouvons dire que :

Le MLLP est une technologie ancienne mais viable pour la transmission de 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 le VPN ou le SFTP).
Les connexions VPN peuvent facilement être é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 des autres transmissions de données utilisant TCP.

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 ça 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, 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 EHR à un niveau supérieur? Nous vous recommandons de tirer parti de notre module 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 servir de prochaine frontière en matière de conformité HIPAA, et vos concurrents n'y sont probablement pas encore parvenus.

Voir aussi : Relever les défis de l'intégration des systèmes patrimoniaux et Intégration d'Aidbox et de MatrixCare EHR.