En los ejercicios anteriores, resolvimos los típicos problemas relacionados con la implantación de un nuevo HIS y con la necesidad de validar la mensajería HL7.

En el mismo escenario vamos a plantear el último ejercicio para tratar otro problema muy común en el mundo de las integraciones en salud: la gestión de errores.

Este artículo es parte de la serie del tutorial de Mirth Connect.

Necesidad

Tras solucionar el problema de la validación de la mensajería, que tenía en cuenta los problemas relativos al formato de los mensajes HL7, NewModernHIS se encuentra con un nuevo problema: cada consumidor realiza su propia gestión de errores funcionales.

Los errores funcionales hacen referencia a los errores propios de aplicación, y son ajenos al formato de los mensajes HL7. Errores funcionales comunes son, por ejemplo, paciente no encontrado o no existe la cama.

Al igual que ocurría con la validación de la mensajería, NewModernHIS nota que se está invirtiendo demasiado tiempo en resolver los errores particulares de cada sistema que consume su mensajería HL7, por lo que, de nuevo, se ve obligado a unificar este comportamiento.

Se analiza la gestión de errores de los diferentes sistemas y se observan varios comportamientos diferentes:

• Sistemas que no usan una codificación de errores y tan sólo ofrecen una descripción del error que en ocasiones es ambigua.
• Sistemas que usan su propia codificación específica de errores y por tanto NewModernHIS no los entiende.
• Sistemas que usan una clasificación demasiado genérica para de errores.
• Sistemas que no clasifican los errores y siempre devuelven errores generales e inesperados, sin especificar qué es lo que ha fallado exactamente (por ejemplo, ocurrió un error fatal inesperado).

Cada uno de estos errores probablemente será expresado de forma diferente por cada sistema. Y, además, cada aplicación comunica el error de forma diferente (por ejemplo mediante una plataforma de incidencias, correo electrónico, vía telefónica, …).

Esta heterogeneidad en la gestión de errores hace que se convierta en una misión casi imposible dar soporte para las incidencias reportadas por cada uno de los sistemas.

Solución propuesta por NewModernHIS

NewModernHIS se da cuenta de que los errores se pueden agrupar en categorías, aunque en cada sistema tengan múltiples representaciones. Además, piensa que todos ellos podrían comunicar los errores de la misma forma.

Así, NewModernHIS propone lo siguiente:

1. Elaborar un catálogo de errores funcionales, con una codificación que todos los sistemas consumidores deben seguir para poder notificar sus errores.
2. Publicar un servicio web de notificación asíncrona de errores, para que los sistemas consumidores puedan notificar sus errores.

Una vez adoptada la nueva estrategia, las aplicaciones tendrán que mapear sus errores con los del catálogo e informar de los mismos mediante el uso del nuevo servicio web SOAP.

Por simplicidad, supondremos que tan sólo se requieren el código del error, la fecha y hora a la que ocurrió, y el nombre de la aplicación que lo generó. También supondremos que podemos informar de más de un error en la misma llamada.

Podemos indicar toda esta información mediante un único argumento en la petición SOAP:

...
<arg0>
  <![CDATA[
    <errs>
      <err>code|datetime|application</err>
      <err>code|datetime|application</err>
     ...
    </errs>
  ]]>
</arg0>
...

Asimismo, a lo largo del tiempo las aplicaciones podrán contribuir a mejorar el catálogo de errores, principalmente, para la creación de nuevos errores que también pudiesen ocurrir en otros sistemas.

Respecto al catálogo de errores funcionales, es responsabilidad de cada sistema sanitario especificarlo y mantenerlo. Su definición se sale del ámbito de lo que queremos explicar, por tanto sólo trabajaremos con 2 errores para poder probar el caso práctico.

Una posible solución utilizando Mirth Connect

Volvamos a nuestra aplicación consumidora, PharmaCoolX 1.0.

Tras la implantación de la nueva estrategia, antes de informar a NewModernHIS de un error mediante el nuevo servicio web, PharmaCoolX 1.0 tendrá que mapearlo conforme al catálogo de errores propuesto.

De nuevo, PharmaCoolX 1.0 prefiere desentenderse de todo esto y delegar en los integradores que le solucionaron los problemas anteriores.

Para solucionar este problema, propondremos un desarrollo sencillo en Mirth Connect.

Aprovecharemos que PharmaCoolX 1.0 dispone de un fichero de log para registrar sus errores de la siguiente forma:

...
tipo,”fecha hora”,codigo_error_local
tipo,”fecha hora”,codigo_error_local
...

Donde el tipo puede ser F (Fatal Error), E (Error), , W (Warning) o I (Info).

Crearemos un nuevo canal en Mirth Connect que:

1. Rastree periódicamente el contenido del fichero de log en busca de errores (sólo nos interesan los tipos E y F, así que ignoraremos el resto).
2. Convierta los errores locales en errores válidos dentro del catálogo de errores.
3. Construya las peticiones SOAP con la información requerida.
4. Realice las notificaciones al nuevo servicio web SOAP.

Al igual que hicimos con el servicio web de validación de la mensajería, simularemos el servicio web de notificación asíncrona de errores mediante otro canal en Mirth Connect.

Todo esto lo veremos en el próximo artículo.