Flujos de tareas con InterSystems IRIS Workflow Engine - Configuración

En nuestro artículo anterior presentábamos los conceptos generales así como la problemática que queríamos resolver mediante el uso del motor de tareas integrado en InterSystems IRIS, en el artículo de hoy veremos como configuramos una producción de interoperabilidad para proveer una solución.

Configuración del motor de Workflow

Primeramente vamos a definir los roles de las tareas que vamos a manejar, en nuestro ejemplo vamos a definir dos tipos:

• AutomaticBloodPressureRole: que utilizaremos para crear las tareas automáticas que no tendrán intervención por parte del usuario.
• ManualBloodPressureRole: para aquellas tareas que el usuario deberá validar.

No será necesario asignar a estos roles los usuarios ya que lo haremos posterior sobre la marcha conforme vayamos recibiendo mensajes de HL7 de diferentes pacientes.

Tampoco necesitamos añadir usuarios de IRIS al Workflow ya que lo haremos por código desde la producción.

Configuración de la producción

Para nuestro ejemplo vamos a crear una producción dentro de un NAMESPACE creado ad-hoc y al que hemos llamado WORKFLOW. Será en esta producción donde incluiremos los componentes del negocio que necesitemos.

Empecemos explicando los componentes más sencillos:

Business Services

• HL7_File_IN: encargado de recoger los archivos HL7 de una ruta específica del servidor que simularán la recepción de mensajería desde un dispositivo médico.

Business Operations

• AutomaticBloodPressureRole: componente de la clase EnsLib.Workflow.Operation, con el nombre de uno de los roles definidos y que usaremos para generar en nuestro Workflow las tareas que no implicarán interacción directa con el usuario.
• ManualBloodPressureRole: similiar al Business Operation anterior, pero en este caso las tareas que generemos requerirán que el usuario intervenga directamente para su cierre.

Veamos ahora en detalle el Business Process que gestionará el flujo de información y la creación y gestión de las tareas implicadas en nuestro ciclo.

Workflow.BP.BloodPressurePlan

Este Business Process es del tipo BPL y será el responsable de la creación de las tareas implicadas en el cuidado del paciente y en la captura de la respuesta, tanto del paciente como del dispositivo médico que remitirá la información relativa a los niveles de presión arterial.

Inicio del proceso:

En esta parte el flujo hace lo siguiente:

1. Checking user: comprueba el usuario recibido en el mensaje ADT^A08 recibido y si existe, continúa avanzando por el flujo, si no crea al usuario en IRIS y lo asigna a los roles definidos en el workflow. Para asignar los usuarios al rol ejecuta el siguiente comando:

   /// Workflow user creation
   set sc = ##class(EnsLib.Workflow.UserDefinition).CreateUser(username)
   /// Assigning Workflow user to the role
   set sc = ##class(EnsLib.Workflow.RoleDefinition).AddUserToRole(role, username)

2. Get automatic task: dado que en este flujo vamos a gestionar tareas tanto automáticas como manuales debemos comprobar si para el paciente recibido existen tareas automáticas pendientes para el usuario. Esto es relevante ya que si existen tareas automáticas pendientes significa que hemos tenido una lectura previa cuyos valores superan los niveles de normales. La comprobación la haremos directamente sobre la tabla de TaskResponse donde se guardan todas las tareas creadas, la consulta será la siguiente:

   &sql(SELECT ID INTO :taskId FROM EnsLib_Workflow.TaskResponse WHERE TaskStatus_AssignedTo = :username AND TaskStatus_IsComplete = 0 AND %RoleName = :role)

3. Getting count of OBX: recuperamos el número de segmentos OBX de nuestro mensaje de HL7.
4. Check OBX values: recorremos los segmentos OBX y extraemos únicamente los datos relativos a la presión arterial.
5. Pending tasks?: como hemos dicho en el punto 2, comprobamos si tenemos una tarea automática pendiente o no.

Primera lectura de presión arterial:

En esta parte del flujo trataremos aquellos mensajes que no vienen generados por una primera lectura que supere los niveles de presión arterial máximos definidos.

1. Check pressure: comprobamos si los niveles de presión arterial superan unos límites preestablecidos, si no lo superan el proceso concluirá sin necesidad de hacer nada más. En caso contrario será necesario crear las tareas necesarias.
2. Create manual task: la presión arterial ha superado los niveles de seguridad definidos por lo que será necesario crear una tarea manual en la que informaremos al paciente de la situación indicándole que deberá tomarte una segunda lectura, veamos la configuración de esta actividad.  
   1. Invocaremos al Business Operation ManualBloodPressureRole que será el encargado de generar la tarea pasándole un mensaje de tipo EnsLib.Workflow.TaskRequest.
   2. Definiremos las acciones que podrá realizar el paciente separadas por comas en callrequest.%Actions, en este caso sólo hemos definido la acción "Accept".
   3. Configuramos el mensaje que se mostrará al paciente en callrequest.%Message.
   4. Le asignamos al paciente la tarea creada definiendo su nombre de usuario en callrequest.%UserName.
   5. Finalmente le indicaremos un asunto o título en callequest.%Subject y una prioridad (entre 1 y 3) en callrequest.%Priority.
3. Create auto task: similar a la configuración de la actividad anterior, pero en esta ocasión lo enviaremos al Business Operation AutomaticBloodPressureRole. Esta tarea será la que se mantendrá a la espera de la segunda lectura de la presión arterial del paciente y será la que provoque que cualquier nuevo mensaje recibido por la producción para este paciente no genere nuevas tareas al obtener un false en la actividad de Pending task?
4. Wait for tasks: esta actividad mantendrá el flujo de tareas en espera hasta que la tarea y manual sean finalizadas, es decir, hasta que el paciente cierre la alarma creada por ManualBloodPressureRole y la producción de IRIS reciba un segundo mensaje por parte del dispositivo médico.
5. Check if warning: llegaremos a esta actividad una vez que se hayan cerrado las tareas pendientes anteriores. En este punto comprobaremos si el cierre de la tarea automática ha recibido una nueva lectura con niveles que superan los valores máximos de presión arterial configurados (la tarea se cerrará con una acción de warning) o no. En el caso de que la medida sea inferior a los valores máximos concluirá el proceso. Si las medidas superan los valores máximos pasará a la siguiente actividad.
6. Warning task for doctor: se crea una tarea manual para informar al médico asignado al paciente que este puede estar sufriendo una crisis.
7. Warning task for patient: informamos al paciente con una nueva tarea manual que su médico ha sido informado de la situación.

Segunda lectura de presión arterial

A esta parte del flujo sólo se accederá cuando exista una tarea automática previamente creada y que no haya sido finalizada. 

1. Check pressure: nuevamente validamos para el mensaje recibido si los valores de presión arterial superan o no el límite.
2. Close normal task: si los niveles no superan los valores máximos cerraremos la tarea pendiente con el método CompleteTask proporcionado por la clase EnsLib.Workflow.TaskResponse que nuestra tarea instancia. El parámetro usado indicará la acción tomada, en este caso indicaremos que es una falsa alarma pasando el valor FalseAlarm, podríamos definir cualquier otro que deseemos.
3. Close warning task: igual que en el caso anterior, con la diferencia de que en este caso la acción que le pasamos al motor de Workflow será Warning y que será el valor que la actividad "Check if warning" que hemos visto anteriormente comprobará.

Como veis en el siguiente diagrama (no es literal pero os podeis hacer una idea de como funcionará), nuestro flujo de tareas va a trabajar con 2 "hilos" o procesos:

El primer hilo/proceso se mantendrá abierto en caso de que sea necesario esperar a una segunda lectura y será el segundo hilo/proceso será el que provoque la reactivación del primer hilo abierto al recibir dicha segunda lectura, concluyendo así el flujo de tareas definido.

Conclusión

Como podéis ver la configuración de un flujo de tareas en un BPL es bastante sencillo, pudiendo simular tareas automáticas y manuales sin mucha complicación. En el próximo y último artículo veremos como pueden los usuarios interactuar con sus tareas desde una aplicación externa.

¡Gracias a todos por vuestra atención!