Descripció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 generalmente aún se nos exige dar soporte a los mensajes que entran y salen de nuestro sistema. Pero ¿cómo podemos hacer que este proceso resulte algo menos estresante?
En este artículo le ofrecemos un breve recorrido que explica cómo conectar las antiguas redes locales de EHR sobre hardware físico con las aplicaciones sanitarias modernas 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 una conexión VPN en términos generales?
- ¿Cuáles son los componentes principales necesarios 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 ámbito de MLLP, pero mientras HIPAA no sea modificado, 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 con MLLP?
Para habilitar la 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 (site-to-site virtual private network).
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 un checksum
- 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. Aún era la era de los servidores físicos y las redes locales con máquinas reales y hardware de red real. La era de internet ni siquiera había llegado todavía.
El problema es que hoy en día tendemos a utilizar máquinas virtuales. Nuestras aplicaciones se despliegan en Azure/AWS/Google Cloud Platform con el uso de 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 pocas palabras, sí lo es. No obstante, conviene señalar que casi todas las entidades utilizadas para establecer la conexión serán puramente virtuales (lógicas). Aquí en Health Samurai hemos conseguido establecer este tipo de conexiones usando Microsoft Azure, Amazon AWS y Google Cloud Platform.
¿Cuál es la topología habitual de una VPN S2S?
Tenemos dos redes locales conectadas a través de una conexión de túnel VPN cifrado. Parece bastante sencillo, ¿verdad? Pero el uso de máquinas virtuales añade cierta complejidad.
VPN significa red privada virtual. En el caso de S2S (site-to-site), fusiona dos redes en una única red lógica. La conexión entre estas dos redes se realiza estableciendo un túnel (en la práctica, simplemente un conjunto de datos cifrados). Enviaremos nuestro mensaje HL7 al EHR a través de este túnel.
¿Cómo es una conexión VPN S2S en la nube habitual? Avance: es un poco más complicada
Como mencionamos antes, en el caso de las redes en la nube tenemos niveles adicionales de complejidad. Tenemos una red virtual con una máquina virtual en su interior que, de algún modo, alcanza el exterior de internet utilizando 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 tiene muchas direcciones IP, la red virtual probablemente utilizará la cantidad de direcciones necesaria de dicha red.
Red virtual
La red virtual es una entidad puramente lógica. Es una red con un rango determinado 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 se puede ver arriba, esto se realiza a través de:
- una pasarela privada virtual (otras redes)
- una pasarela de internet (internet)
¿Cómo determino si nuestra conexión debe ir a internet o a la red local?
Esto se realiza mediante tablas de rutas.
Tabla de rutas
Las tablas de rutas son simplemente un conjunto de reglas que gobiernan hacia dónde debe dirigirse el tráfico. En nuestro caso, las tablas de rutas están configuradas 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 a través de su dirección IP privada. Una conexión VPN facilita considerablemente 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 una VPG (pasarela privada virtual).
- La VPG invoca el túnel VPN con la otra máquina.
¿Desea simplificar su configuración? Hable con nuestros especialistas para obtener soluciones a medida. Póngase en contacto
¿Cómo funciona exactamente el túnel VPN?
Aquí 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 utilizando 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:
- verificamos que la conexión se establece entre las partes correctas
- alcanzamos un acuerdo sobre el tipo de cifrado
- verificamos 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 establecer 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 discutir exactamente cómo se cifrarán los datos.
Normalmente, se necesitan tres pasos para superar la fase 1 de IKE:
- intercambio de 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, cuando tiene lugar la transmisión de datos del usuario.
No cubriremos AH y ESP en detalle aquí, ya que operan con los mismos principios que el protocolo IKE y sirven al mismo propósito. Sin embargo, conviene recordar varios puntos:
- La comunicación no es más que un intercambio de paquetes de datos (paquetes IP).
- Cada protocolo de seguridad añade datos adicionales (cabeceras) al paquete IP original.
- Esto se realiza encapsulando un fragmento de datos dentro de otro mediante cifrado.
- El descifrado de los datos tiene lugar 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 sobre MLLP y utilizar tecnologías para alcanzar este objetivo (como VPN o SFTP).
- Las conexiones VPN pueden establecerse fácilmente entre la red local y la infraestructura en la nube (AWS/GCP/Azure) utilizando 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.
Si está intentando establecer una conexión VPN para su flujo HL7 en un entorno cloud y se ha quedado bloqueado, escríbanos y estaremos encantados de mostrarle cómo funciona.
Para explorar la configuración de mensajería HL7 sobre MLLP con VPN en su entorno, considere utilizar la versión gratuita de Aidbox. Proporciona un entorno seguro y completamente 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 de API FHIR de Aidbox conectable. Está certificado por ONC y proporciona una API para ingerir y procesar mensajes HL7® v2 de forma fluida. Aidbox está bien posicionado para servir como 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.








