Nous sommes nouveaux pour utiliser HL7. Actuellement, nous échangeons des messages HL7 via TCP / IP avec un écoute / expéditeur / expéditeur HL7 TCP / IP standard. Tout cela fonctionne bien et ne pose aucun problème, mais nous sommes un EMR hébergé, nous devons créer et gérer des VPN sur nos serveurs pour le faire. P>
Ma question est-ce. N'y a-t-il aucun moyen de contourner le VPN et d'échanger des messages HL7 sur Internet (HTTPS) vers et depuis nos services Web ??? P>
J'ai cherché et recherché mais je ne trouve aucune réponse d'une manière ou d'une autre. Et s'il vous plaît rien à propos de HL7 version 3 car personne ne semble en fait l'utiliser. Mes clients utilisent tous des versions HL7 2.3 à 2.5, ont pour des années et ne montrent aucune inclinaison à changer. P>
7 Réponses :
HL7 sur Internet est assez nouveau pour la plupart des organisations de soins de santé. Si vous souhaitez réduire la complexité et rester complètement indépendant du système client et / ou de l'infrastructure, j'ai bien peur que VPN soit votre meilleure option. Les gens font confiance à cela et c'est assez facile à déployer. P>
Si vous souhaitez vous éloigner d'une stratégie VPN, le système qui vous envoie des messages HL7 doit avoir la capacité de les envelopper dans les demandes HTTPS (ou dans un autre protocole sécurisé). Très peu de systèmes cliniques ont de telles capacités de médiation de protocole hors tension. Si vous ajoutez un moteur d'intégration dans l'équation, cela vous aiderait à traduire TCP et LLP en communication HTTPS. Vous pouvez déployer cette capacité d'intégration en tant que composant de solution sur le site client, mais cela introduit souvent une nouvelle complexité et des coûts. P>
Si vous trouvez des alternatives viables, laissez-moi savoir ...; -) p>
Oui, il existe une solution disponible pour que vous puissiez utiliser aujourd'hui. L'autre réponse est juste sur l'argent, le problème de l'échange de HL7 sur Internet n'est pas parce que c'est difficile, c'est parce que a) il n'y a pas (et ne sera jamais) un Internet "standard" pour hl7 version 2.xx et b) HL7 est une conversation à deux sens et vous ne contrôlez pas les deux côtés. Cela signifie que si vous concevez votre service Web et que cela fonctionne magnifiquement et si vous avez trouvé une personne disposée à échanger HL7 avec vous, les chances sont probablement même qu'ils auraient conçu leur propre service Web qui souhaiterait que vous vous adaptiez à et utiliser. p>
La solution doit être une solution que vous pouvez mettre en œuvre unilatéralement, sans que votre partenaire commercial HL7 modifie quoi que ce soit en dehors de leurs méthodes d'interfaçage HL7 habituelles. P>
Regardez le Ultraport HL7 Postmaster P>
Cela résout le problème en implémentant une double interface. L'une est une interface TCP / IP standard de pointage intérieure HL7 et la seconde est une interface personnalisée "pointant vers l'extérieur" qui interagit directement avec votre service Web HL7. Ils vous fourniront même des modèles ASP.NET Shell pour la construction de la "porte d'entrée" à votre service Web. J'ai travaillé avec deux clients à ce sujet et ils ont pu compiler et publier le service Web de démonstration fourni par le fournisseur à leur serveur de test et le faire courir dans moins de 20 minutes. P>
Il est montré plus en détail dans l'aide en ligne Cliquez ici . p>
J'espère que cela aide. P>
Vous pourriez peut-être utiliser deux instances de Mirth, en tant que "relais" HTTPS. HL7 entrant dans le système A, sortant thru https. Alors l'inverse. Il devrait être possible de faire cette configuration assez transparente aux systèmes concernés. P>
Je vous recommanderais de configurer un serveur SFTP dans une distribution de Linux pour télécharger les messages. En deux ans, un protocole crypté est nécessaire pour avoir un logiciel compatible HIPPA. P>
Cloak Labs possède un logiciel Solution de sécurité HL7 au problème de Passer les messages HL7 entre entreprises. Nous prenons fondamentalement des messages HL7 et les chiffrons à l'extrémité d'envoi (à l'aide de l'AES256 avec la clé protégée par RSA, le tout signé avec RSA / SHA). Les messages sont transmis de manière redondante via CloudPrime et acheminés vers le récepteur en tant que message de magasin et d'avance afin que la messagerie puisse devenir asynchrone au lieu de synchrone. Ceci élimine de nombreuses sources d'erreurs communes (le VPN étant en panne ou le côté de la réception). P>
L'intégration avec HL7 est effectuée via un connecteur HL7 spécifique à un protocole, nécessitant très peu de temps. Aucune règle de pare-feu entrant supplémentaire n'a besoin d'être ajoutée. Les clés n'existent que sur les points finaux de sorte que personne, mais que l'expéditeur et le récepteur, pas même des ingénieurs de Cape-labons ou des admins SYS ne peuvent lire les messages. Les points de terminaison ne peuvent communiquer que avec d'autres éléments de confiance pour aluminer tout type d'exploits DNS. P>
Essentiellement Les applications de deux entreprises différentes peuvent faire un message en toute sécurité mutuellement sans nécessiter de modifications réseau ou de nouveaux VPN. Cloak Labs signera un accord BAA pour ses services. P>
Divulgation complète, je suis PDG à Cloak Labs. J'espère que vous trouverez cela utile. P>
Il existe une initiative récente dans la communauté HAPI / HL7 afin de préciser comment les messages HL7 V2 doivent être passés sur http (s). S'il vous plaît voir http://hl7api.sourceforge.net/hapi-hl7overhttp/ Pour plus d'informations. p>
Notre Security Guy a suggéré un transfert de port SSH sur le client et le destinataire. Pas de moyen lisse de déployer sur un moteur d'interface typique. Besoin de partager la clé RSA publique du côté de l'écoute des expéditeurs HL7 TCP et d'utiliser la connexion SSH résultante pour appuyer sur la charge utile HL7 (avec cryptage). Aurait besoin de beaucoup de démons de SSH de transfert de port sur les côtés de l'expéditeur et de l'auditeur pour cela. P>
Phil - Médecine de l'Université de Chicago. P>
J'utilise l'interconnexion épique => HL7 sur https => pa SIIS et c'est assez persistant et échoue en sécurité; Cependant, le dépannage est un problème. Nous prenons parfois AE et n'avons aucune idée de la cause de la cause. Également, expérimenter avec la mise en œuvre de l'ensemble de l'ensemble intersemations, hapi et jirth. Curieux s'il y a eu d'autres efforts réussis aussi, à ce moment-là?