Mirth Connect 4.7.1 y Mirth Command Center para clientes internacionales: lo que salió de las Office Hours de NextGen
NextGen celebró el 17 de junio una nueva sesión de su serie «Between Two Channels: Mirth Connect Office Hours». El formato es el habitual: una hora con el equipo de producto, novedades técnicas y espacio para preguntas. Esta entrega trajo dos anuncios concretos que merecen atención para quienes operan entornos Mirth Connect en producción.
No fue una sesión de grandes titulares. Tampoco pretendía serlo. Las Office Hours tienen un carácter más de actualización técnica y comunidad que de presentación de producto. Pero eso no significa que lo anunciado sea irrelevante; al contrario, para equipos que gestionan plataformas de integración sanitaria críticas, los detalles importan.
Mirth Connect 4.7.1: mantenimiento bien hecho
NextGen publicó Mirth Connect 4.7.1 el mismo día 17 de junio. No es una versión que traiga grandes funcionalidades nuevas. Es, fundamentalmente, una actualización de mantenimiento, seguridad y estabilidad. Y eso, en entornos sanitarios, tiene más valor del que a veces se le reconoce.
Actualización de dependencias y librerías
El grueso de los cambios en esta versión afecta a las dependencias internas del motor. Se han actualizado las librerías de AWS a la versión 2.42.34, el driver JDBC de PostgreSQL de la 42.6.0 a la 42.6.2, Mozilla Rhino a la 1.7.15.1, Thymeleaf —usado en el soporte FHIR— a la 3.1.5, y las librerías Jetty han recibido parches. También se actualiza HAPI HL7 v2 de la versión 2.3 a la 2.4.1, y la librería JavaScript Handlebars a la 4.7.8.
Para quien lleva tiempo trabajando con Mirth, estos nombres son conocidos. Y la pregunta relevante no es si son cambios espectaculares —no lo son— sino qué implica no tenerlos. Dependencias desactualizadas en un motor de integración que maneja mensajes clínicos, conecta con sistemas HIS o publica recursos FHIR son un riesgo real. Las vulnerabilidades conocidas en librerías como Jetty o en el driver JDBC no son hipotéticas; están catalogadas, y los equipos de seguridad de muchas organizaciones sanitarias las detectan en sus revisiones periódicas. Mantener Mirth en una versión que incorpora estos parches es, simplemente, operar con más control sobre la superficie de exposición.
La actualización de HAPI HL7 v2 tiene también implicaciones de compatibilidad para quienes procesan mensajes v2 complejos o utilizan funcionalidades específicas de parsing. Vale la pena revisar el changelog de HAPI entre las versiones 2.3 y 2.4.1 si hay lógica de transformación que dependa de comportamientos específicos del parser.
Corrección de defectos relevantes
Hay varios bugs corregidos que merecen atención según el contexto de cada instalación:
- Entornos macOS: se resuelve un problema que impedía seleccionar inicialmente un canal en versiones recientes del sistema operativo. Afecta a equipos de desarrollo o administración que trabajan desde Mac.
- AWS S3 con IAM Roles: se corrige un problema de conexión en File Readers y File Writers cuando la autenticación se realiza mediante roles IAM en lugar de credenciales directas. Para integraciones con almacenamiento en nube dentro de flujos sanitarios, esto puede haber sido un bloqueante real.
- Vulnerabilidad XXE en el transformador XSLT: este es quizás el fix más relevante desde el punto de vista de seguridad. Un transformador XSLT que no bloqueaba correctamente inyecciones XXE (XML External Entity) es un vector de ataque conocido. En entornos que procesan XML de terceros —HL7 v2 wrapeado en XML, CDA, mensajes FHIR en formato XML—, esta corrección no es menor.
- Importación de propiedades SSL en versiones 4.6+: se resuelve un problema que afectaba a la importación de configuraciones SSL en versiones recientes. Para quienes migraron desde versiones anteriores, esto puede explicar comportamientos inesperados en canales con TLS configurado.
- Advanced Alerting: los periodos de «Do Not Disturb» no se guardaban correctamente. Para equipos que gestionan alertas operativas y tienen ventanas de mantenimiento definidas, este fix tiene impacto directo en la operación.
En el plano cosmético, se han actualizado colores de fuente para mejorar el contraste en la interfaz y el logo de marca en la pantalla de login. También se incorpora la creación automática de la tabla de recursos OAuth durante el arranque si no existe, lo que simplifica ciertas configuraciones iniciales.
Aviso sobre deprecaciones en 4.8
NextGen ha comunicado que en la futura versión 4.8 quedarán obsoletas dos APIs:
/users/_checkPassword/users/{userId}/password
La versión 4.8 no tiene fecha cerrada. La estimación que manejaba el equipo de producto en la sesión apunta al último trimestre de 2026, pero se presentó como previsión, no como compromiso. Dicho esto, si algún proceso interno, script de automatización o integración externa consume estas APIs, ahora es el momento de identificarlo y planificar la migración. Dejarlo para cuando salga la versión suele generar urgencias innecesarias.
Mirth Command Center 1.14: analítica centralizada sin restricciones regionales
El segundo anuncio de la sesión fue la disponibilidad general de Mirth Command Center 1.14 para clientes internacionales a partir del 17 de junio. Hasta ahora, su acceso tenía limitaciones geográficas; a partir de esta versión, cualquier cliente fuera de Norteamérica puede utilizarlo.
Los requisitos de entrada son claros: necesita Mirth Connect 4.6.1 o superior como base. La herramienta se aloja en la nube de NextGen, sobre AWS, y actualmente está orientada exclusivamente a funcionalidades de analítica. No es una solución instalable en infraestructura propia.
Para equipos de soporte e integración, la propuesta es interesante: visibilidad centralizada y analítica sobre el comportamiento de los entornos Mirth, sin tener que construir esa capa desde cero. En organizaciones con múltiples instancias, o con arquitecturas distribuidas entre diferentes hospitales o sistemas, contar con una vista agregada tiene valor operativo real.
Ahora bien, hay que ser directo sobre sus limitaciones actuales. El alcance está restringido a analítica. No es una herramienta de gestión de canales, no permite operar ni desplegar configuraciones de forma remota, y no sustituye la administración directa de la instancia. Es una capa de observabilidad, no una plataforma de control.
El modelo cloud plantea también preguntas que cada organización debe responder según su contexto. En entornos sanitarios con datos sometidos al RGPD, a normativas nacionales de protección de datos o a políticas de arquitectura que restringen el envío de información operativa a infraestructuras externas, el análisis de viabilidad requiere más que una decisión técnica. Depende del tipo de datos que la herramienta transmite hacia los servidores de AWS, de los acuerdos de tratamiento de datos con NextGen y de si esa arquitectura encaja con los requisitos del departamento de seguridad y el DPO de la organización.
NextGen ha anunciado webinars específicos para clientes. Será una buena oportunidad para resolver estas preguntas antes de tomar decisiones de adopción.
Qué debería hacer tu equipo ahora
Si trabajas con Mirth Connect en producción, la lectura práctica de esta sesión es bastante concreta:
Sobre 4.7.1: revisar la versión instalada y evaluar la actualización. No es urgente en el sentido de un hotfix crítico, pero sí conveniente a corto plazo por los parches de seguridad incluidos. Antes de actualizar en producción, validar en un entorno PRE, especialmente si se usan File Readers/Writers con S3 o transformadores XSLT. Revisar también si alguna extensión instalada —Alerting, clustering— tiene comportamientos que podrían verse afectados por los cambios en dependencias.
Sobre las APIs deprecadas: identificar si algún proceso o integración las consume. Si es así, priorizar la migración. La ventana hasta 4.8 existe, pero no es infinita.
Sobre Mirth Command Center: si la organización opera en cloud o tiene arquitecturas híbridas con menor fricción normativa, vale la pena explorar la herramienta y asistir a las sesiones de NextGen. Si el entorno es estrictamente on-premise con restricciones de seguridad estrictas, el análisis previo de viabilidad es obligatorio antes de considerar cualquier adopción.
Cierre
Las Office Hours de NextGen no suelen traer anuncios que cambien la hoja de ruta de nadie. Su valor está en otro lugar: en la proximidad con el equipo de producto, en la posibilidad de hacer preguntas directas y en mantener el pulso sobre hacia dónde va la plataforma. La sesión del 17 de junio fue un buen ejemplo de eso. Actualizaciones necesarias, un paso adelante en la disponibilidad internacional de Command Center y señales claras sobre lo que viene en 4.8. Suficiente para tener la agenda técnica de los próximos meses un poco más ordenada.
¿Utilizas Mirth Connect en tu organización y tienes dudas sobre la actualización o el encaje de Command Center en tu arquitectura? Puedes contactarnos para una valoración técnica sin compromiso.
