Visión general del protocolo HL7 MLLP
En la década de 1990, asistimos al salto de los servidores físicos al mundo de las máquinas virtuales. Los servidores físicos siguen existiendo, por lo que normalmente se nos sigue exigiendo que demos soporte a los mensajes que entran y salen de nuestro sistema. Pero, ¿cómo podemos hacer que este proceso resulte un poco menos estresante?
En este artículo le ofrecemos un breve recorrido que explica cómo conectar las antiguas redes locales EHR en servidores físicos con las modernas aplicaciones sanitarias basadas en la nube, y cómo establecer intercambios de mensajes HL7 v2/v3 entre ellas mediante MLLP.
Siga leyendo para descubrir:
- ¿Qué es HL7 MLLP?
- ¿Cómo funciona en general una conexión VPN?
- ¿Cuáles son las unidades principales necesarias para establecer conexiones VPN S2S en un entorno cloud?
¿Qué es el protocolo MLLP?
MLLP (Minimal Low Layer Protocol) es un protocolo para el intercambio de mensajes HL7. Está compuesto por dos elementos básicos:
- transmisión de mensajes HL7 a través de TCP/IP
- delimitación del inicio y el fin de un mensaje HL7
La seguridad queda formalmente fuera del alcance de MLLP, pero mientras HIPAA no sea modificada, los implementadores deben tener en cuenta los problemas de seguridad. Esto hace que el transporte de mensajes HL7 mediante MLLP sea considerablemente más complejo.
¿Cómo establecemos conexiones seguras usando MLLP?
Para habilitar una comunicación segura, es necesario establecer una conexión TCP/IP cifrada entre el emisor y el receptor. Esto se realiza mediante una conexión VPN S2S (red privada virtual de sitio a sitio).
Otras formas de enviar mensajes HL7 a través de internet (HTTPS) incluyen:
- Hybrid Lower Layer Protocol (HLLP), una variante de MLLP que además requiere la transmisión de una suma de verificación
- otros protocolos que transmiten datos sobre TCP/IP: SOAP, SMTP, S/FTP (no conformes con HIPAA/GDPR por defecto)
Nota histórica sobre los desafíos técnicos más importantes
MLLP se introdujo en la década de 1990. Era todavía la era de los servidores físicos y las redes locales con máquinas y hardware de red reales. La era de internet aún no había llegado.
El problema es que hoy en día tendemos a usar máquinas virtuales. Nuestras aplicaciones se despliegan en Azure/AWS/Google Cloud Platform con tecnologías basadas en contenedores como Kubernetes (K8S) y Docker, por lo que literalmente tenemos que establecer una conexión VPN S2S desde nuestra red K8S.
VPN S2S desde un clúster de Kubernetes: ¿Es posible?
En resumen, sí lo es. No obstante, hay que señalar que casi todas las entidades utilizadas para establecer una conexión serán puramente virtuales (lógicas). En Health Samurai hemos logrado establecer dichas conexiones utilizando Microsoft Azure, Amazon AWS y Google Cloud Platform.
¿Cuál es la topología habitual de una VPN S2S?
Tenemos dos redes locales conectadas mediante una conexión de túnel VPN cifrado. Parece bastante sencillo, ¿verdad? Sin embargo, el uso de máquinas virtuales añade cierta complejidad.
VPN son las siglas de red privada virtual. En el caso de S2S (sitio a sitio), fusiona dos redes en una única red lógica. La conexión entre estas dos redes se establece creando un túnel (en la práctica, simplemente un paquete de datos cifrados). Enviaremos nuestro mensaje HL7 al EHR a través de este túnel.
¿Cómo es una conexión VPN S2S cloud habitual? Adelanto: es un poco más complicada
Como mencionamos antes, en el caso de las redes cloud tenemos niveles adicionales de complejidad. Disponemos de una red virtual con una máquina virtual en su interior que, de algún modo, accede a internet exterior mediante una dirección IP pública. Esto es lo que suele ocurrir:
No se preocupe, explicaremos todo en detalle:
Aplicación
Nuestra aplicación es simplemente un pod de un clúster K8S con una dirección IP privada (virtual). Esta dirección IP existe dentro de la subred virtual.
Subred virtual
La subred virtual es una parte de toda la red virtual dentro de nuestro clúster de Kubernetes. Por tanto, si un clúster dispone de muchas direcciones IP, la red virtual probablemente utilizará la cantidad de direcciones necesarias de esa red.
Red virtual
La red virtual es una entidad puramente lógica. Es una red con un determinado rango de direcciones IP privadas. Todas las entidades dentro de dichas redes virtuales están conectadas mediante software, en lugar de conexiones físicas por cable.
¿Cómo realiza un pod ubicado en una red privada solicitudes hacia internet exterior (y otras redes)?
Como puede ver anteriormente, esto se realiza a través de:
- una puerta de enlace privada virtual (otras redes)
- una puerta de enlace de internet (internet)
¿Cómo decido si nuestra conexión debe ir a internet o a la red local?
Esto se gestiona mediante tablas de rutas.
Tabla de rutas
Las tablas de rutas son simplemente un conjunto de reglas que determinan a dónde debe dirigirse el tráfico. En nuestro caso, las tablas de rutas se configuran de la siguiente manera:
- todas las conexiones realizadas hacia la red del EHR se dirigen a la red del EHR
- todas las demás conexiones se dirigen a internet
¿Cómo pueden las redes externas conectarse al pod?
Si las redes externas están conectadas a la red del pod, se puede acceder al pod mediante su dirección IP privada. Una conexión VPN facilita en la práctica la unión de dos redes en una sola.
¿Cómo puede establecerse una conexión VPN si el pod es el iniciador?
- El pod envía una solicitud a la dirección IP de la red del EHR.
- La solicitud llega a la tabla de rutas, que indica que el siguiente salto de la conexión es un VPG (virtual private gateway).
- El VPG invoca el túnel VPN con el otro equipo.
¿Desea optimizar su configuración? Hable con nuestros especialistas para obtener soluciones personalizadas. Contáctenos
¿Cómo funciona exactamente el túnel VPN?
A continuación explicaremos cómo se establece la conexión IPSEC. Existen varios protocolos VPN:
- Layer 2 Tunneling Protocol (L2TP)
- Point–to–Point Tunneling Protocol (PPTP)
- SSL y TLS
- Secure Shell (SSH)
- OpenVPN
- WireGuard
En nuestra experiencia, IPSEC es la forma más habitual de transmitir tráfico HL7 mediante MLLP.
IPSEC comprende en realidad un grupo de protocolos utilizados para establecer la conexión:
- Internet Key Exchange (IKE)
- Authentication Header (AH)
- Encapsulating Security Payload (ESP)
Cada uno de los protocolos mencionados puede tratarse también como un paso para establecer la conexión:
- garantizamos que la conexión se establece entre las partes correctas
- llegamos a un acuerdo sobre el tipo de cifrado
- garantizamos que los datos no han sido interceptados ni modificados
¿Cómo llegamos a un acuerdo sobre el tipo de cifrado?
El protocolo IKE de dos fases ayuda a configurar un canal de comunicación seguro y autenticado. Las formas más habituales de llegar a un acuerdo sobre los algoritmos de cifrado incluyen:
- intercambio de clave precompartida (PSK)
- autenticación basada en firma
- cifrado de clave pública
Esto se denomina fase 1 de IKE. Es la etapa en la que ambas partes tienen la certeza de que la conexión fue iniciada por las partes correctas y pueden acordar exactamente cómo se cifrarán los datos.
Por lo general, son necesarios tres pasos para superar la fase 1 de IKE:
- intercambio de las reglas de cifrado aplicables (SHA, Diffie–Hellman, etc.)
- intercambio de la parte pública de los datos Diffie–Hellman (DH) y datos auxiliares
- confirmación de los resultados del intercambio DH
¿Qué es la fase 2 de IKE? La fase 2 de IKE es la fase principal de la conexión, en la que se produce la transmisión de datos del usuario.
No abordaremos AH y ESP en detalle aquí, ya que operan siguiendo los mismos principios que el protocolo IKE y sirven al mismo propósito. Aun así, hay varios puntos que conviene recordar:
- La comunicación es simplemente un intercambio de paquetes de datos (paquetes IP).
- Cada protocolo de seguridad añade datos adicionales (cabeceras) al paquete IP original.
- Esto se realiza envolviendo un fragmento de datos dentro de otro mediante cifrado.
- El descifrado de los datos se produce en el lado del receptor.
Conclusión
En resumen, podemos afirmar que:
- MLLP es una tecnología antigua pero viable para transmitir mensajes HL7 a través de internet y redes locales.
- Es necesario tener en cuenta la seguridad al transmitir mensajes mediante MLLP y utilizar tecnologías para lograr ese objetivo (como VPN o SFTP).
- Las conexiones VPN pueden establecerse fácilmente entre la red local y la infraestructura cloud (AWS/GCP/Azure) mediante entidades virtuales.
- Desde el punto de vista de la aplicación, la transmisión de datos sobre VPN no difiere de cualquier otra transmisión de datos mediante TCP.
Para pipelines de producción de HL7 v2 a FHIR donde se necesite una cola duradera, mapeo como código y una cola de mensajes fallidos sobre el transporte MLLP descrito anteriormente, consulte nuestro motor de integración sanitaria Interbox.
Si está intentando establecer una conexión VPN para su flujo HL7 en un entorno cloud y se encuentra con dificultades, hable con nosotros y estaremos encantados de mostrarle cómo funciona.
Para explorar la configuración de mensajería HL7 sobre MLLP con una VPN en su entorno, considere utilizar la versión gratuita de Aidbox. Proporciona un entorno seguro y totalmente funcional para probar estas configuraciones, ofreciendo todas las herramientas necesarias sin ninguna limitación.
Autores: Artem Alexeev, Viktor Gusakov
¿Desea llevar la transmisión y el almacenamiento de datos de su EHR al siguiente nivel? Le recomendamos aprovechar nuestro módulo Aidbox FHIR API conectable. Cuenta con certificación ONC y proporciona una API para ingerir y procesar mensajes HL7® v2 de forma fluida. Aidbox está bien posicionado para convertirse en la próxima frontera del cumplimiento de HIPAA, y es probable que sus competidores aún no hayan llegado hasta ahí.
Véase también: Abordando la integración de sistemas heredados y Integración de Aidbox con MatrixCare EHR.
