Mirth Connect es una herramienta increíblemente útil para ejecutar integraciones sanitarias. Sin embargo, para aprovechar al máximo sus capacidades y evitar los errores más comunes, es esencial tener cierta experiencia. En este artículo, te ofrecemos una serie de consejos y buenas prácticas para abordar la integración, con el objetivo de ayudarte a prevenir futuras dificultades y mejorar la mantenibilidad de tus integraciones.

Sin duda, estos consejos nos ahorrarán mucho tiempo, esfuerzo y dolores de cabeza.

Cuida la arquitectura de tu integración #

Ten el claro el flujo antes de empezar a desarrollar #

Al iniciar una integración, se tiende a lanzarse a desarrollar canales y conectores sin tener una visión completa de la arquitectura necesaria en Mirth Connect.

Es crucial tener una comprensión clara del flujo de información de la integración: tipos de información, sistemas destinatario y remitente, procesamiento, etc. Podemos reflejarlo utilizando diversos tipos de diagramas, como diagramas de flujo, diagramas de secuencia, casos de uso, etc. Utilizar diagramas nos ayudará a identificar las partes poco claras de nuestra integración y a reconsiderar los aspectos que podríamos mejorar.

Los diagramas pueden crearse con lápiz y papel o con sus equivalentes electrónicos, como Dia, yEd, Draw.io o Microsoft Visio.

Decide la funcionalidad de cada canal #

Los canales de Mirth Connect son potentes, pero es preferible tener más canales con funciones más pequeñas que menos canales que abarquen demasiado. Merece la pena encontrar el nivel adecuado de granularidad. Esta estrategia dotará a nuestro sistema de integración de mayor flexibilidad y escalabilidad.

Una buena estrategia consiste en agrupar los canales en distintas fases de procesamiento: los encargados de recibir de otros sistemas, de encaminar la información, de transformarla o de enviarla a otros sistemas.

Elige cómo implementar la funcionalidad #

Una vez que tengamos claro cómo funciona nuestra integración y cómo organizar su funcionalidad, podemos plantearnos cómo implementar estos flujos de comunicación.

Es importante que nos paremos a pensar en el diseño de los canales, los conectores y las comunicaciones entre ellos. Por ejemplo:

• Tipos de conectores y tipos de datos utilizados para cada canal.
• Conexiones a bases de datos y sistemas de archivos.
• Conexiones a sistemas externos.

No tengas miedo de volver al primer paso y reexaminar el flujo, la organización de los canales o cualquier otro aspecto de la integración. Revisar estos aspectos durante la fase de diseño es infinitamente más fácil que después de comenzar el desarrollo.

Separa el tratamiento específico del sistema integrado #

Es habitual necesitar un procesamiento de datos específico de la aplicación integrada, y una solución fácil podría ser modificar nuestro canal de Mirth Connect para gestionar este procesamiento específico. Sin embargo, no es una buena práctica, ya que provoca un acoplamiento estrecho entre el sistema integrado y el motor de integración. Un acoplamiento elevado provocará muchos quebraderos de cabeza en el futuro a la hora de actualizar, añadir funcionalidad o reutilizar partes del sistema.

Piensa que la aplicación integrada puede cambiar en el futuro y, si tenemos un procesamiento específico para ese sistema en nuestro canal Mirth Connect, no podremos reutilizarlo con facilidad.

Recomendamos que todo el procesamiento específico del sistema integrado se realice independientemente del motor de integración de Mirth Connect. Esto puede conseguirse, por ejemplo, mediante servicios web o procedimientos almacenados en bases de datos, tratándolo como si fuera otro sistema externo desde la perspectiva del motor de integración. Esto dará a nuestros desarrollos de Mirth Connect una mayor reutilización, ya que serán independientes de los sistemas integrados.

Utiliza el ConfigurationMap #

Como en otras áreas de la programación, otra mala práctica consiste en utilizar repetidamente determinados parámetros y configuraciones cuando desarrollamos canales y conectores.

Seguro que muchos hemos repetido las conexiones a bases de datos a lo largo de configuraciones de canales, filtros y transformadores. La estructura de Mirth Connect se presta a ello, y antes de que nos demos cuenta, el desarrollo está tan avanzado que es prácticamente imposible cambiar ninguna de estas configuraciones.

Una solución práctica para evitar la repetición de configuraciones es el uso del ConfigurationMap de Mirth Connect. Este mapa actúa como un repositorio centralizado para gestionar las variables globales y los parámetros de configuración que afectan a todos los canales. Utilizando el ConfigurationMap, podemos modificar fácilmente valores comunes en un solo lugar, simplificando la gestión y actualización de nuestras integraciones.

Este recurso es muy útil para establecer:

• Conexiones a bases de datos.
• Activación y desactivación de validaciones sintácticas o semánticas de mensajes.
• Niveles de log o alertas.
• Límites y frecuencias de polling para las consultas a la base de datos.
• Versiones HL7 utilizadas.
• Entornos de ejecución (debug, desarrollo y producción).
• Políticas comunes de reintento y garantías de entrega.
• Identificadores de pacientes para el sistema sanitario.
• Configuraciones para acuse de recibo y solicitud (ACK).
• Gestión de la notificación asíncrona de errores.
• Control de la inactividad en sistemas externos.
• Configuraciones para tareas propias de limpieza periódica.

Además, muchas de las configuraciones mencionadas deben estructurarse a nivel del sistema externo que se va a integrar. Esto se debe a que los distintos sistemas pueden utilizar distintas versiones de HL7, distintas gestiones de ACK o distintas políticas de reintento.

Utiliza Code Templates para funcionalidad repetida #

Al igual que las configuraciones, también es habitual y no aconsejable repetir fragmentos enteros de código en todos los canales y conectores conforme los vamos necesitando. Por ejemplo, validar los campos obligatorios en segmentos comunes de los mensajes H L7, como el MSH, o extraer la información del identificador del paciente a partir del PID en distintos tipos de mensajes HL7.

Para minimizar la repetición de código en Mirth Connect, los code templates (plantillas de código) son invaluables. Esta característica nos permite crear y almacenar fragmentos de código y funciones personalizadas para utilizarlos en múltiples canales. Al utilizar code templates, garantizamos la coherencia y reducimos los esfuerzos de mantenimiento, permitiendo el uso del mismo código parametrizado en diferentes etapas de procesamiento de la mensajería.

Algunos ejemplos de para qué podemos utilizarlos:

• Ejecuciones contra la base de datos.
• Validación de mensajes.
• Construcción de mensajes.
• Construcción de llamadas a servicios web.

Una estrategia inteligente aquí nos permite mantener el código bien organizado y estructurado a lo largo de todas las fases de procesamiento de nuestro sistema de integración. Esto no es fácil de conseguir cuando se empieza a trabajar con Mirth Connect.

Precaución con los canales de polling #

Mirth Connect tiene una categoría de readers para definir algunos tipos de conectores para fuentes, que se configuran en función de una frecuencia de rastreo (polling frequency) que determina cada cuanto tiempo se ejecuta el canal.

Pues bien, conviene seguir algunos consejos para evitar ciertos problemas que pueden causar este tipo de conectores.

Limita las consultas a la base de datos #

Un conector puede dejar de funcionar debido a un problema. Aunque Mirth Connect dispone de una gestión propia de colas, si no existe un límite de consultas a bases de datos, al activar el conector de nuevo puede llegar a saturarse con demasiada información y ocasionar algunos errores difíciles de solucionar en nuestra integración.

Para evitar estos casos, es importante establecer un límite en las consultas a la base de datos para este tipo de conectores.

Reutiliza las conexiones a bases de datos #

Hay casos en los que es necesario establecer una frecuencia de polling muy alta (menos de un segundo) para trabajar con sistemas en tiempo real.

En estos casos, Mirth Connect abre y cierra por defecto una conexión a la base de datos cada vez que sondeamos. Esto puede causar problemas con el pool de conexiones de la base de datos.

Para mejorar este comportamiento, es posible almacenar conexiones a bases de datos en variables de Mirth Connect para reutilizarlas en este tipo de conectores.

Gestiona las alertas con cuidado #

Es habitual incluir conectores de canales de polling en las alertas de Mirth Connect. Aunque esto parece lógico, puede tener graves consecuencias.

Si se produce un fallo en la base de datos o un cambio que provoque el fallo de la consulta con una frecuencia de sondeo elevada, el sistema activará una alerta cada vez que rastree. Además de las consecuencias en el propio servidor de Mirth Connect, esto puede sobrecargar el sistema de correo electrónico si las alertas se comunican por correo electrónico.

Para evitar estos casos, recomendamos gestionar las alertas externamente a Mirth Connect para este tipo de conectores.

Comprueba el orden de ejecución del script Run On-Update Statement #

Una funcionalidad muy utilizada en el conector fuente de los canales de polling es la Run On-Update Statement, que permite ejecutar una sentencia UPDATE en los registros de la base de datos afectados en la consulta principal, por ejemplo, para actualizar su estado.

Dependiendo de la versión de Mirth Connect, este script se ejecuta antes o después de los transformadores del conector. Suponer un orden de ejecución y equivocarse puede dar lugar a problemas inesperados cuando nuestra integración esté operativa. Por lo tanto, es crucial asegurarse de si este script se ejecuta antes o después de los transformadores.

Establece una estrategia para la configuración global de los canales #

Como ya se mencionó en el artículo sobre canales y conectores, la configuración global de cada canal (resumen), entre otras cosas, permite definir el estado inicial del canal tras su despliegue (parado o iniciado) y las características del almacenamiento de mensajes en la base de datos (no almacenar mensajes filtrados, sólo con errores, duración en días, etc.).

La configuración aconsejable varía en función de la fase de procesamiento en la que se encuentre el canal y del tipo de conector utilizado para el source. Estas configuraciones deben definirse al estructurar los canales de nuestro motor de integración y respetarse estrictamente.

Por ejemplo, una regla de oro para nosotros es:

Todos los canales con fuentes readers en una fase de enrutamiento deben iniciarse parados y sin almacenar información en la base de datos.

De este modo, no sobrecargaremos la base de datos de Mirth Connect si se producen errores en el rastreo a alta frecuencia y evitaremos situaciones peligrosas en caso de que el servicio Mirth Connect se reinicie inesperadamente. Al igual que las alertas, la gestión de este tipo de errores debe hacerse de forma externa y controlada.

Al establecer una estrategia, también debemos tener en cuenta otras buenas prácticas, como almacenar sólo los errores para un entorno de producción o establecer adecuadamente el número de días que se almacenarán los mensajes (los suficientes para corregirlos, pero no tantos como para desbordar el espacio de almacenamiento).

Todo ello dependerá del análisis inicial de la integración y de las características del servidor donde esté instalado Mirth Connect.

Utiliza clases de Java propias #

Otra potente característica de Mirth Connect es la posibilidad de incluir clases Java desarrolladas a medida. Esto es necesario en algunas integraciones para adaptar determinados conectores a circunstancias especiales en las que los conectores por defecto no sean los adecuados.

Este enlace a la wiki de Mirth Connect explica cómo hacerlo.

Versiona el código de Mirth Connect #

Mirth Connect permite exportar configuraciones, canales, alertas, scripts globales y code templates a formato XML. Estos archivos XML, cuando se estructuran adecuadamente, pueden utilizarse para mantener el control de versiones de nuestros desarrollos de Mirth Connect mediante herramientas de control de versiones como GIT.

Conclusión #

En resumen, seguir buenas prácticas y estrategias bien pensadas mejorará enormemente la eficacia y la sostenibilidad de las integraciones en Mirth Connect. Desde la estructuración clara de la arquitectura de integración hasta el uso de herramientas como ConfigurationMap y code templates, cada paso desempeña un papel crucial en la creación de soluciones sólidas y mantenibles.

Al adoptar estas prácticas, no sólo facilitamos el desarrollo y la gestión de nuestras integraciones, sino que también nos preparamos mejor para adaptarnos a futuros cambios y escalar eficazmente nuestras soluciones. Recuerda que invertir tiempo en planificar y organizar tus integraciones en Mirth Connect no sólo ahorra esfuerzo a largo plazo, sino que también garantiza la calidad y fiabilidad de tus sistemas sanitarios integrados.