Respuesta corta: Un motor de integración (interface engine) es un software intermedio diseñado para la mensajería en el ámbito de la salud. Escucha en múltiples protocolos (MLLP para HL7 v2, HTTP para FHIR y SOAP, archivos, bases de datos, colas), transforma mensajes (mapeo de campos, traducción de códigos, conversión de formatos como de HL7 v2 a FHIR), los enruta a uno o varios destinos con filtros, y mantiene colas, reintentos, registros y paneles de control para que ningún mensaje se pierda y todos los fallos sean visibles. Los hospitales utilizan uno para que cada sistema se conecte al motor una sola vez, en lugar de conectarse a todos los demás sistemas. Los productos conocidos son Mirth Connect (NextGen Connect, históricamente de código abierto), Rhapsody, InterSystems HealthShare / IRIS for Health, Infor Cloverleaf, Qvera QIE, Orion y una larga lista; los proveedores de servicios en la nube ofrecen equivalentes gestionados.
Los componentes básicos
Los componentes básicos de un motor de integración son los canales (un flujo desde un origen a sus destinos), conectores o escuchas de origen como MLLP y HTTP, filtros que deciden si un mensaje continúa, transformadores que mapean campos y códigos, conectores de destino, colas con reintentos, monitorización con alertas y un registro de auditoría de los cambios en los canales y el historial de mensajes.
Cada motor, independientemente del vocabulario, tiene las mismas partes:
- Canal (interfaz): un flujo desde un origen a uno o más destinos, con su propia configuración y estadísticas.
- Conector/escucha de origen: MLLP (TCP con encapsulación para HL7 v2), puntos de conexión HTTP(S), SFTP y sondeo de archivos, consultas a bases de datos, colas JMS u otras, DICOM en algunos productos.
- Filtro: una regla que decide si un mensaje continúa (solo ADT^A01 para esta clase de paciente).
- Transformador: scripts o mapeos que cambian el mensaje: renombrar campos, mapear códigos locales a LOINC a través de una tabla de consulta, construir una
Observationde FHIR a partir de un segmento OBX, añadir un segmento Z que un sistema heredado espera. - Conector de destino: a dónde va el resultado, con su propio protocolo y manejo de errores.
- Cola y reintento: los mensajes persisten hasta ser confirmados; los fallos se reintentan con retroceso; los mensajes "envenenados" van a una cola de errores para ser gestionados por humanos.
- Monitorización y alertas: contadores por canal, latencia, tasas de error, alertas cuando un canal se queda en silencio (la alerta más útil en integración sanitaria).
- Auditoría: quién cambió qué canal y el historial de mensajes para la resolución de problemas, con controles de retención y acceso porque son datos del paciente.
Tareas típicas
Las tareas típicas de un motor de integración sanitaria son la distribución de ADT desde el HIS a los departamentos, el enrutamiento de resultados de laboratorio a varios receptores, la traducción de códigos locales a LOINC, ATC y UCUM, la interconexión de formatos HL7 v2, FHIR, CDA y CSV, la exposición de una fachada FHIR sobre una base de datos heredada, la normalización de flujos de dispositivos y la adaptación de MLLP interno a HTTPS externo.
- Distribución ADT: recibir admisiones del HIS, filtrar y traducir por departamento, entregar a laboratorio, radiología, farmacia, gestión de camas y al portal del paciente.
- Enrutamiento de resultados: ORU del LIS al EHR, al sistema del médico prescriptor, al registro regional, al registro FHIR del paciente, cada uno con un subconjunto y formato diferente.
- Traducción de códigos: códigos de pruebas locales a LOINC, códigos de medicamentos locales a ATC, unidades de texto libre a UCUM, a través de tablas de consulta mantenidas (mapeo de códigos de laboratorio a LOINC).
- Puente de formatos: HL7 v2 a FHIR y viceversa, CDA a FHIR, CSV de un sistema antiguo a cualquier formato.
- Una fachada FHIR: el motor expone puntos de conexión FHIR y responde a ellos consultando la base de datos heredada o enviando consultas v2, de modo que las aplicaciones ven un servidor FHIR donde no existe.
- Integración de dispositivos: fuentes de monitorización propietarias normalizadas a observaciones IHE PCD.
- Adaptación de protocolos: MLLP dentro del edificio, HTTPS con OAuth hacia el exterior.
Elegir uno
La elección de un motor de integración se reduce a seis criterios: volumen de mensajes y la importancia de la latencia y las interrupciones, los protocolos y estándares soportados de fábrica (HL7 v2, FHIR R4, DICOM, formatos nacionales), la experiencia del desarrollador, las operaciones como la agrupación en clústeres y la conmutación por error, los términos de licencia, que cambiaron para algunos productos en 2025, y las habilidades disponibles para mantener los canales.
- Volumen y criticidad: mensajes por día, latencia aceptable y si una interrupción de dos minutos importa (sí, para ADT y resultados).
- Protocolos y estándares listos para usar: versiones y analizadores de HL7 v2, soporte de FHIR R4 con validación, DICOM, X12 en EE. UU., formatos nacionales.
- Experiencia del desarrollador: lenguaje de scripting (JavaScript en Mirth, propietario en otros), control de versiones de definiciones de canales, herramientas de prueba, despliegue en varios entornos.
- Operaciones: clustering, conmutación por error, integraciones de monitorización, ruta de actualización, modelo de soporte.
- Licencia: ediciones de código abierto o comunitarias, suscripción por canal o por núcleo, ofertas gestionadas en la nube; las licencias de algunos productos históricamente abiertos cambiaron en 2025, así que compruebe los términos actuales.
- Habilidades disponibles: el motor es tan bueno como las personas que mantienen los canales.
Ejecutar uno de forma segura
Ejecutar un motor de integración de forma segura significa tratar las definiciones de canal como código bajo control de versiones, probar con mensajes sintéticos antes de la producción, gobernar las tablas de búsqueda de código con propietarios designados, alertar cuando un canal se queda en silencio, restringir y purgar el historial de mensajes porque son datos del paciente, documentar el propósito de cada canal y nunca permitir que el motor se convierta en el sistema de registro.
Trate las definiciones de canales como código: en control de versiones, revisadas, desplegadas a través de entornos de prueba y staging con mensajes sintéticos. Mantenga las tablas de consulta (mapas de códigos) bajo gobernanza con propietarios. Establezca alertas por silencio, no solo por errores. Restrinja el acceso al historial de mensajes, que son datos del paciente, y purgarlo según un calendario. Documente el propósito y el propietario de cada canal; el canal no documentado es el que detiene a un departamento cuando su autor se va. Y nunca permita que el motor se convierta en el sistema de registro: mueve y transforma datos, no los posee.
Cuando no necesita uno
No se necesita un motor de integración cuando todos los socios de un sistema nuevo hablan FHIR, en cuyo caso un servidor FHIR con Subscriptions y una pasarela API cubren el enrutamiento y la autenticación, o cuando una única interfaz HL7 v2 puede ser manejada por una biblioteca como HAPI HL7v2 o hl7apy. El motor se gana su lugar con muchos sistemas y formatos.
Un sistema "greenfield" cuyos socios hablen todos FHIR puede usar un servidor FHIR con Subscriptions y una API gateway para autenticación, limitación de velocidad y enrutamiento, con transformaciones en servicios ordinarios. Una única interfaz HL7 v2 puede ser manejada por una pequeña biblioteca (HAPI HL7v2 en Java, hl7apy o python-hl7 en Python) dentro de la aplicación. El motor se justifica cuando hay muchos sistemas, muchos formatos y la necesidad de una consola de operaciones que los no desarrolladores puedan supervisar.
En Anpheros
Anpheros Platform está en el lado FHIR del motor: los hospitales enrutan los flujos que desean compartir (resultados, documentos, encuentros) a través de su motor o del conector de laboratorio, y leen de vuelta a través de APIs FHIR y webhooks. El sitio para desarrolladores muestra el mapeo de HL7 v2 a FHIR que aplica el conector.
Páginas relacionadas
- Integración de sistemas hospitalarios explicada
- Cómo integrar un sistema de laboratorio con un EHR
- Mensajes HL7 v2 explicados: ADT y ORU
- Cómo mapear códigos de laboratorio locales a LOINC
- Suscripciones FHIR explicadas
- Mapeo de HL7 v2 a FHIR (sitio para desarrolladores)
Fuentes
- NextGen Connect (Mirth Connect)
- Rhapsody Integration Engine
- InterSystems IRIS for Health
- Infor Cloverleaf
- Biblioteca HAPI HL7v2
- Guía de implementación de HL7 v2 a FHIR
Preguntas frecuentes
¿Es un motor de integración lo mismo que un ESB o un iPaaS?
Son de la misma familia, pero especializados: un motor de integración viene con soporte para HL7 v2, DICOM, CDA y FHIR, MLLP, monitorización específica para la salud y la integración de vocabularios que utilizan los equipos. Los ESB y iPaaS generales pueden hacer el trabajo con más esfuerzo.
¿Puede el motor convertir HL7 v2 a FHIR automáticamente?
Varios motores incluyen mapeos basados en la guía de HL7 v2 a FHIR, y manejan los segmentos comunes. Las convenciones locales, los segmentos Z y el mapeo de códigos siempre requieren trabajo de proyecto.
¿Almacena el motor datos del paciente?
Persiste mensajes en tránsito y mantiene el historial de mensajes para la resolución de problemas, lo que son datos del paciente y deben ser protegidos y purgados. No debe utilizarse como almacenamiento a largo plazo ni como sistema de registro.
¿Código abierto o comercial?
Ambos están en producción en grandes hospitales. La decisión suele depender del soporte, las habilidades, las necesidades de clustering y los términos de licencia actuales, que han cambiado para algunos productos; compruebe antes de comprometerse.
Pruébalo gratis en el sandbox
Tu primera llamada FHIR en 5 minutos. Una API HL7 FHIR R4 con el consentimiento del paciente integrado: pruébala en el sandbox y luego conecta tu propia app o sistema de clínica.
Gratis · 30 pacientes sintéticos · sin tarjeta
Anpheros crea un historial médico que el paciente controla y puede compartir con cualquier clínica, en una plataforma HL7 FHIR R4, con sede en la UE. Estas guías te ayudan a entender y organizar tu salud; no reemplazan a tu médico.
Sobre Anpheros →