Flux de tâches avec le moteur InterSystems IRIS Workflow Engine - Configuration

Dans notre article précédent, nous avons présenté les concepts généraux ainsi que le problème que nous voulions résoudre en utilisant le moteur de tâches intégré dans InterSystems IRIS. Dans l'article d'aujourd'hui, nous verrons comment configurer une production d'interopérabilité pour fournir une solution.

Configuration du moteur de workflow

Tout d'abord, nous allons définir les rôles des tâches à gérer. Dans notre exemple, nous allons définir deux types de tâches:

• AutomaticBloodPressureRole: pour créer des tâches automatiques qui ne nécessitent aucune intervention de la part de l'utilisateur.
• ManualBloodPressureRole:ManualBloodPressureRole: pour créer les tâches à valider manuellement par l'utilisateur.

Il ne faudra pas assigner des utilisateurs à ces rôles puisque nous le ferons plus tard, au fur et à mesure que nous recevrons des messages HL7 de différents patients.

Nous n'avons pas non plus besoin d'ajouter les utilisateurs d'IRIS au Workflow puisque nous le ferons par code à partir de la production.

Configuration de la production

Pour notre exemple, nous allons créer une production dans un NAMESPACE (espace de noms) créé ad-hoc et que nous avons appelé WORKFLOW (flux de travail). C'est dans cette production que nous inclurons les éléments métier dont nous avons besoin.

Commençons par expliquer les composants les plus simples:

Services métier

• HL7_File_IN: responsable de la collecte des fichiers HL7 à partir d'un chemin d'accès spécifique au serveur qui simulera la réception de messages en provenance d'un dispositif médical.

Opérations métier

• AutomaticBloodPressureRole: composant de la classe EnsLib.Workflow.Operation, avec le nom d'un des rôles définis que nous utiliserons pour générer les tâches qui n'impliqueront pas d'interaction directe avec l'utilisateur dans notre Workflow.
• ManualBloodPressureRole: similaire à l'opération métier précédente, mais dans ce cas, les tâches que nous générons nécessiteront que l'utilisateur intervienne directement pour les achever.

Voyons maintenant en détail le processus opérationnel qui gérera le flux d'informations ainsi que la création et la gestion des tâches impliquées dans notre cycle.

Workflow.BP.BloodPressurePlan

Ce processus métier est de type BPL et sera responsable de la création des tâches liées aux soins du patient et de la saisie de la réponse, à la fois du patient et de l'appareil médical qui enverra les informations relatives aux niveaux de tension artérielle.

Début du processus:

Ici, le flux effectue les opérations suivantes:

1. Contrôle de l'utilisateur: vérifie l'utilisateur reçu dans le message ADT^A08 et, s'il existe, poursuit le flux, sinon crée l'utilisateur dans IRIS et l'affecte aux rôles définis dans le flux de travail. Pour assigner des utilisateurs au rôle, elle lance la commande suivante :
   

   /// Création d'utilisateurs de Workflow
   set sc = ##class(EnsLib.Workflow.UserDefinition).CreateUser(username)
   /// Assignation du rôle à l'utilisateur du Workflow
   set sc = ##class(EnsLib.Workflow.RoleDefinition).AddUserToRole(role, username)

2. Obtention d'une tâche automatique: Puisque dans ce flux nous allons gérer à la fois des tâches automatiques et manuelles, nous devons vérifier s'il y a des tâches automatiques en attente pour l'utilisateur concernant le patient reçu. Ce point est important car si des tâches automatiques sont en suspens, cela signifie que nous avons eu une lecture antérieure dont les valeurs dépassent les niveaux normaux. Nous effectuerons le contrôle directement dans la table TaskResponse où toutes les tâches créées sont sauvegardées, la requête sera la suivante:
   

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

3. Obtention du nombre d'OBX: nous récupérons le nombre de segments OBX à partir de notre message HL7.
4. Contrôle des valeurs OBX: nous parcourons les segments OBX et n'extrayons que les données relatives à la tension artérielle.
5. âches en attente?: Comme nous l'avons dit au point 2, nous vérifions si nous avons une tâche automatique en attente ou non.

Première lecture de la tension artérielle:

Dans cette partie du flux, nous traiterons les messages qui ne sont pas générés par une première lecture dépassant les niveaux maximums de tension artérielle définis.

1. Contrôle de la tension: Nous vérifions si les niveaux de tension artérielle dépassent les limites préétablies ; si ce n'est pas le cas, le processus s'achève sans qu'il soit nécessaire de faire quoi que ce soit d'autre. Sinon, il sera nécessaire de créer les tâches nécessaires.
2. Création d'une tâche manuelle: La tension artérielle a dépassé les niveaux de sécurité définis, il est donc nécessaire de créer une tâche manuelle qui informera le patient de la situation et lui indiquera qu'il doit effectuer une deuxième lecture. Voyons la configuration de cette activité. 
      
   1. Nous allons invoquer l'opération métier ManualBloodPressureRole qui sera responsable de la génération de la tâche en y passant un message de type EnsLib.Workflow.TaskRequest.
   2. Nous définirons les actions que le patient peut effectuer en les séparant par des virgules dans callrequest.%Actions, dans ce cas nous n'avons défini que l'action "Accepter".
   3. Nous configurons le message qui sera affiché au patient dans callrequest.%Message.
   4. Nous attribuons la tâche créée au patient en définissant son nom d'utilisateur dans callrequest.%UserName.
   5. Enfin, nous indiquerons un sujet ou un titre dans callequest.%Subject et une priorité (entre 1 et 3) dans callrequest.%Priority.
3. Création d'une tâche automatique: comme pour la configuration de l'activité précédente, sauf que cette fois-ci, nous l'enverrons à l'opération métier AutomaticBloodPressureRole. Cette tâche sera celle qui restera en attente de la deuxième mesure de la tension artérielle du patient et qui fera en sorte que tout nouveau message reçu par la production pour ce patient ne génère pas de nouvelles tâches en obtenant un faux dans l'activité Pending task? ("Tâche en attente").
4. Attente des tâches: Cette activité met le flux de tâches en attente jusqu'à ce que la tâche et le manuel soient achevés, c'est-à-dire jusqu'à ce que le patient supprime l'alarme créée par ManualBloodPressureRole et que la production IRIS reçoive un deuxième message du dispositif médical.
5. Contrôle en cas d'avertissement: Nous aborderons cette activité une fois que les tâches précédentes en attente auront été achevées. À ce stade, nous vérifions si l'achèvement de la tâche automatique a reçu une nouvelle lecture avec des niveaux qui dépassent les valeurs maximales de tension artérielle configurées (la tâche sera achevée avec une action d'avertissement) ou non. Si la mesure est inférieure aux valeurs maximales, le processus s'achève. Si les mesures dépassent les valeurs maximales, vous passerez à l'activité suivante.
6. Tâche d'avertissement pour le médecin: Une tâche manuelle est créée pour informer le médecin assigné au patient que ce dernier est peut-être en train de traverser une crise.
7. Tâche d'avertissement pour le patient: nous informons le patient, au moyen d'une nouvelle tâche manuelle, que son médecin est au courant de la situation.

Deuxième lecture de la tension artérielle

Cette partie du flux ne sera accessible que lorsqu'une tâche automatique précédemment créée n'a pas été achevée.

1. Contrôle de la tension: nous validons à nouveau le message reçu pour savoir si les valeurs de la tension artérielle dépassent la limite ou non.
2. Clôturer la tâche normale: Si les niveaux ne dépassent pas les valeurs maximales, nous allons achever la tâche en attente avec la méthode CompleteTask fournie par la classe EnsLib.Workflow.TaskResponse que notre tâche instancie. Le paramètre utilisé indiquera l'action entreprise, dans ce cas nous indiquerons qu'il s'agit d'une fausse alarme en passant la valeur FalseAlarm, nous pourrions définir n'importe quel autre valeur à notre guise.
3. Achevement de la tâche d'avertissement: Comme dans le cas précédent, sauf que dans ce cas l'action que nous transmettons au moteur de Workflow sera Avertissement et qu'il s'agira de la valeur que l'activité " Contrôle en cas d'avertissement " que nous avons vue précédemment vérifiera.

Comme vous pouvez le voir dans le diagramme suivant (il n'est pas littéral mais vous pouvez vous faire une idée de la manière dont il fonctionnera), notre flux de tâches fonctionnera avec deux "fils" ou "processus":

Le premier fil/processus restera ouvert au cas où il serait nécessaire d'attendre une seconde lecture et c'est le second fil/processus qui provoquera la réactivation du premier fil ouvert après réception de ladite seconde lecture, concluant ainsi le flux de tâches défini.

Conclusion

Comme vous pouvez le constater, la configuration d'un flux de tâches dans une BPL est assez simple et vous pouvez simuler des tâches automatiques et manuelles en toute facilité. Dans le prochain et dernier article, nous verrons comment les utilisateurs peuvent interagir avec leurs tâches à partir d'une application externe.

Merci à tous pour votre attention!