Connecting eHealth blog

Ejercicio 3: la gestión de errores con múltiples sistemas

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.

Otro error
Imagen cortesía de jesadaphorn / FreeDigitalPhotos.net

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.

Trabajadora alegre
Imagen cortesía de jesadaphorn en FreeDigitalPhotos.net

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.

Francisco J. CarrascoEjercicio 3: la gestión de errores con múltiples sistemas

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Resumen de la Política de Privacidad

Responsable: Caduceus Software S.L.
Finalidad: Atender tu solicitud de publicar un comentario en este artículo. Además, si marcas "Recibir nuevos artículos por correo electrónico", suscribirte a nuestra lista de correo, .
Legitimación: Para poder publicar el comentario a tu nombre necesitamos tu nombre, email, web (opcional). Para evitar spam, tus datos personales y otra información técnica pueden ser enviados a un sistema automático de reconocimiento de spam (Akismet). Para suscribirte a nuestra lista de correo necesitamos tu correo electrónico.
Destinatarios: Tus datos para el comentario no se compartirán ni se cederán a terceros. Si marcas "Recibir nuevos artículos por correo electrónico", añadiremos tu dirección de correo y tu nombre a nuestra lista en MailChimp, una compañía estadounidense que cumple y respeta la privacidad de datos. Podrás darte de baja en cualquier momento.
Derechos: Puedes ejercer tus derechos escribiendo a info@caduceus.es o en nuestro formulario de contacto (https://www.caduceus.es/contacto/).

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.