En el artículo anterior recorrimos las características más importantes del panel de administración de Mirth Connect.

Para culminar esta serie de artículos sobre Mirth Connect, vamos a dar una serie de consejos y buenas prácticas a la hora de abordar una integración.

Sin duda nos ahorrarán mucho tiempo (¡y por tanto dinero!).

Serie de artículos sobre Mirth Connect:

• I: Introducción a la herramienta.
• II: Canales y conectores.
• III: El panel de administración.
• IV: Consejos útiles y buenas prácticas (i).
• V: Consejos útiles y buenas prácticas (ii).

Otros recursos en Caduceus:

• Descripción general de Mirth Connect.

Estructurar los canales de manera adecuada

Al realizar una integración desde el principio, existe la tendencia a comenzar el desarrollo de los canales y conectores antes de tener una visión global de la arquitectura que necesitamos montar sobre Mirth Connect.

Es importante que nos paremos a pensar y plasmemos en un diagrama todo lo relativo al diseño de los canales, los conectores y las comunicaciones entre ellos, estableciendo:

• Tipos de conectores y tipos de datos utilizados para cada canal.
• Conexiones a bases de datos y sistemas de ficheros.
• Conexiones a sistemas externos.
• Agrupación de los canales en distintas fases de procesamiento: según se encarguen de recibir de otros sistemas, de enrutar la información, de transformar la información o de enviar a otros sistemas.

El diagrama se puede realizar mediante un lápiz y un papel o cualquiera de sus versiones electrónicas como por ejemplo: Dia, Lucidchart, yed o Microsoft Visio.

Siempre es preferible tener más canales con funciones pequeñas que menos canales que abarquen demasiado. Merece la pena buscar el nivel de granularidad adecuado. Esta estrategia dotará a nuestro sistema de integración de mayor flexibilidad y escalabilidad.

Desacoplar el procesamiento específico de la aplicación integrada

Otra práctica no recomendable y muy habitual es realizar procesamiento específico de la aplicación que se quiere integrar a través de los canales de Mirth Connect encargados de gestionar la mensajería. Esta práctica provoca un gran acoplamiento entre la aplicación a integrar y el motor de integración. Un nivel alto de acoplamiento nos dará muchos quebraderos de cabeza en el futuro para actualizar, añadir funcionalidad o reutilizar partes del sistema.

Nosotros recomendamos que todo el procesamiento específico de la aplicación a integrar se realice de forma independiente al motor de integración de Mirth Connect. Esto se puede conseguir, por ejemplo, mediante servicios web o procedimientos almacenados de base de datos. Así,  es como si se tratase de otro sistema externo de cara al motor de integración. Esto dotará de mayor poder de reutilización a nuestros desarrollos con Mirth Connect.

Utilizar adecuadamente los scripts globales

Como ocurre en otros ámbitos de la programación, otra mala práctica consiste en repetir ciertos parámetros y configuraciones una y otra vez, conforme vamos desarrollando los 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 propia estructura de Mirth Connect da pie a ello y, cuando nos queremos dar cuenta, el desarrollo está tan avanzado que es prácticamente imposible cambiar una de estas configuraciones.

Existen varias soluciones válidas para este problema. Nuestra recomendación es utilizar los scripts globales de Mirth Connect para cargar un fichero de configuración en variables globales a todos los canales en cada despliegue.

Esta técnica 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 rastreo (polling) para las consultas de bases de datos.
• Versiones de HL7 utilizadas.
• Entornos de ejecución (debug, desarrollo y producción).
• Política común de reintentos y garantía de entrega.
• Identificadores de pacientes para el sistema sanitario.
• Configuraciones para los ACK de confirmación de recepción y de aplicación.
• Gestión de la notificación de errores asíncrona.
• Control de la inactividad de sistemas externos.
• Configuraciones para tareas periódicas de limpieza propias.

Además, es conveniente que muchas de las configuraciones anteriores se estructuren al nivel del sistema externo a integrar. Esto es así porque diferentes sistemas pueden utilizar distintas versiones de HL7, distintas gestiones de ACK o distintas políticas de reintentos, por ejemplo.

Utilizar adecuadamente los code templates

Al igual que con las configuraciones, también es típico y poco recomendable repetir trozos de código completos a través de los canales y conectores, conforme los vamos necesitando. Por ejemplo, para validar campos obligatorios en segmentos comunes de mensajes HL7 como el MSH, o extraer información de identificadores de pacientes del PID en diferentes tipos de mensaje HL7.

Para no tener que repetir el código, Mirth Connect permite definir snippets de código y funciones propias mediante la sección code templates. De este modo, se puede reutilizar el mismo código, debidamente parametrizado, en partes comunes del procesamiento de la mensajería, como pueden ser:

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

Una buena estrategia en este sentido nos permitirá tener el código siempre bien organizado y estructurado a lo largo de todas las fases de procesamiento de nuestro sistema de integración. Esto no es nada fácil de conseguir cuando se está comenzando a trabajar con Mirth Connect.

En la continuación de este artículo, hablaremos sobre los canales con frecuencia de rastreo (polling), las configuraciones globales para los canales, el uso de clases propias de Java y el uso del repositorio de código en Mirth Connect.