#Health Connect

InterSystems annonce la disponibilité générale d'InterSystems IRIS, InterSystems IRIS for Health et HealthShare Health Connect 2024.3

La version 2024.3 de la plateforme de données InterSystems IRIS®, InterSystems IRIS® for HealthTM et HealthShare® Health Connect est désormais généralement disponible (GA).

Points forts de la version

Dans cette version, vous pouvez vous attendre à une multitude de mises à jour intéressantes, notamment :

InterSystems IRIS for Health v2024.3 est déjà disponible en tant qu'aperçu pour les développeurs depuis un certain temps, et je voulais souligner la nouvelle prise en charge liée à la recherche FHIR qui a été introduite.

Il existe deux modificateurs dont la prise en charge a été ajoutée :

• not
• missing

L'accès à un stockage cloud Azure pour charger/télécharger des blobs est assez simple à l'aide des méthodes API de classe %Net.Cloud.Storage.Client désignées ou des adaptateurs entrants/sortants EnsLib.CloudStorage.*.

Notez que vous devez avoir le serveur de %JavaServer External Language opérationnel pour utiliser l'API ou les adaptateurs de stockage cloud, car ils utilisent tous deux le framework PEX à l'aide du serveur Java.

Voici un bref résumé :

L'accès à Azure Blob Storage s'effectue à l'aide d'une chaîne de connexion qui ressemble à celle-ci :

Alerte : corruption de base de données avec des bases de données multivolumes après troncation

InterSystems a corrigé un défaut qui peut entraîner une corruption de base de données ou des erreurs <DISKHARD> avec des bases de données multivolumes dans des circonstances extrêmement rares. Seules les bases de données qui ont été tronquées sont à risque.

Le défaut existe dans les produits suivants et dans toutes les offres InterSystems basées sur ceux-ci :

Parfois, nous devons convertir le message FHIR en HL7 V2, par exemple pour enregistrer un patient dans le système PACS.
Dans cet article, les étapes à suivre pour obtenir les résultats souhaités en utilisant la production du serveur IRIS FHIR seront expliquées.

Voici les étapes à suivre:

1. Assurez-vous que la production du serveur FHIR est démarrée.
2. Enregistrez le service métier avec le point de terminaison FHIRServer.
3. Définissez les processus métier pour convertir les messages FHIR en SDA, puis convertissez SDA en HL7 v2.
4. Publiez la ressource JSON sur le point de terminaison FHIRServer et obtenez la réponse HL7 V2.

Examinons les étapes en détail.
 

Étape 1. Assurez-vous que la production du serveur FHIR est démarrée

Ouvrez la page de production et assurez-vous que la Production est démarrée. À l'étape suivante, nous devons nous assurer que le service commercial HS.FHIRServer.Interop.Service est enregistré auprès de FHIRServer

Step 2. Étape 2. Enregistrez le service métier avec le point de terminaison FHIRServer.

Depuis le portail de gestion, cliquez sur l'onglet Health (Santé)

Cliquez ensuite sur Configuration FHIR dans la liste, puis cliquez sur Server Configuration (configuration du serveur)

Sélectionnez le point de terminaison et assurez-vous que HS.FHIRServer.Interop.Service (service commercial défini dans la production) est défini sous le nom Service Config Name.

Étape 3. Définissez les processus métier pour convertir les messages FHIR en SDA, puis convertissez SDA en HL7 v2.

Définissez le rpocessus métier (le processus Solution.BP.Process est déjà défini dans l'application).
Veuillez noter que nous appliquons ici une condition selon laquelle le point de terminaison doit contenir une augmentation hl7 pour procéder à la conversion, sinon il est considéré comme une demande FHIR normale.

Transmettez ensuite le message au processus FHIR_SDA qui le convertira en SDA.
FHIR_SDA est dérivé d'une classe Solution.BP.Process définie par l'utilisateur.
Après conversion FHIR_SDA, le processus transmet le message au processus SDA_HL7
Le processus SDA_HL7 est dérivé d'une classe Solution.BP.SDATransformProcess définied  par l'utilisateur qui convertit le message SDA en message HL7 V2.

Définissez les processus de production comme suit:

Étape 4. Publiez la ressource JSON sur le point de terminaison FHIRServer et obtenez la réponse HL7 V2.

Depuis Postman, appelez le point de terminaison FHIRServer à l'aide de la méthode Post.
Notre point de terminaison FHIRServer est ci-dessous:
http://localhost:32783/csp/fhirserver/fhir/r4/hl7

REMARQUE:Notre point de terminaison FHIRServer est http://localhost:32783/csp/fhirserver/fhir/r4/, mais nous passons hl7 comme argument pour détecter à partir du processus métier de production qu'il ne s'agit pas d'une demande Post FHIR normale mais d'une demande de transformation du message FHIR.

Il s'agit de la même fonctionnalité que celle que nous pouvons utiliser à partir de nos applications Web. 
Sélectionnez la ressource patient, puis cliquez sur la ressource dans la liste, sélectionnez l'onglet HL7 FHIR ou Détails de la ressource, et cliquez sur le bouton "Transformer FHIR en HL7 V2"

L'application obtiendra le message de transformation HL7 V2 à l'aide de la production du serveur FHIR.

Transformation de HL7 V2 à FHIR

Sélectionnez "HL7 to FHIR" dans le menu et entrez les données HL7 V2. Cliquez sur le bouton de conversion pour transformer le message HL7 en message FHIR

La transformation de HL7 en FHIR utilise également la production pour convertir le message HL7 V2 en message FHIR.

Le service métier HL7_Http_Service envoie le message HL7 au processus HL7_SDA, puis HL7_SDA envoie les données SDA au processus SDA_FHIR, qui les convertit finalement en FHIR

Pour plus de détails et une révision du code, veuillez visiter la page d'application de l'échange ouvert iris-fhir-lab .
Merci!

Je me suis retrouvé dans la situation peu confortable de travailler avec un système Linux sur lequel quelqu'un avait accidentellement désactivé l'accès utilisateur au shell Linux. HealthConnect était en cours d'exécution, assurant la maintenance de centaines d'interfaces. Pour résoudre le problème d'accès, cependant, nous devions arrêter l'hôte pour l'application d'un correctif.

Sans le shell, la commande iris n'est pas disponible pour contrôler l'instance, nous étions donc confrontés au risque d'arrêter le serveur de manière inélégante. Nous voulions éviter cela si possible...

Enfin et avec un peu de retard, nous concluons cette série d'articles sur notre moteur de Workflow en montrant un exemple de connexion que nous pourrions établir à partir d'une application mobile.

Dans l'article précédent, nous avons présenté un exemple d'application permettant un contrôle détaillé d'une pathologie chronique telle que l'hypertension, tant pour le patient que pour son médecin associé. Dans cet exemple, le patient pourra accéder à une application web à partir de son téléphone portable (en fait, à une page web conçue pour s'adapter à cet appareil) dans laquelle il recevra des notifications basées sur les mesures que le tensiomètre portable envoie à l'instance IRIS.

Par conséquent, nous aurons deux accès différents à notre instance IRIS:

• Accès utilisateur à partir d'une application mobile.
• Accès à l'appareil pour soumettre les lectures de tension artérielle.

Dans cet article, nous verrons le premier d'entre eux qui permet aux patients de gérer les tâches que leurs lectures génèrent.

Application mobile de connexion - IRIS

Pour réaliser cette connexion, le plus simple est de configurer une application web dans IRIS et pour ce faire, nous y accéderons à partir du portail de gestion, System Administration -> Security -> Applications -> Web Applications (Administration du système > Sécurité > Applications > Applications web):

Ensuite, dans la liste affichée, nous cliquerons sur Create new application (Créer une nouvelle application), ce qui ouvrira un écran comme le suivant:

Sur cet écran, configurons les champs suivants:

• Nom: dans ce champ, nous définirons l'URL à publier pour donner accès à notre fonctionnalité déployée dans IRIS.
• Espace de Noms: l'espace de noms auquel nous voulons que l'application web soit associée, ce qui nous permettra plus tard de profiter des fonctionnalités des productions d'interopérabilité.
• REST: Nous sélectionnerons cette option car ce que nous allons publier est une API REST pour autoriser les connexions HTTP.
• Classe de répartition: Classe ObjectScript qui recevra l'appel HTTP et décidera quoi en faire.
• Utilisation de l'authentification JWT: en cochant cette option, les points de terminaison /login et /logout seront activés sur l'URL que nous avons définie pour notre application, ce qui nous permettra d'obtenir un jeton Web JSON afin d'authentifier nos appels via IRIS.
• Paramètres de sécurité -> Méthodes d'authentification autorisées: nous allons définir un mot de passe pour sécuriser nos appels.

Jetons un coup d'œil à notre classe Workflow.WS.Service:

Class Workflow.WS.Service Extends%CSP.REST
{
Parameter HandleCorsRequest = 0;Parameter CHARSET = "utf-8";
XData UrlMap [ XMLNamespace = "https://www.intersystems.com/urlmap" ]
{
<Routes>
<Route Url="/getTasks" Method="GET" Call="GetTasks" />
<Route Url="/saveTask" Method="POST" Call="SaveTask" />
</Routes>
}
ClassMethod OnHandleCorsRequest(url As%String) As%Status
{
set url = %request.GetCgiEnv("HTTP_REFERER")
set origin = $p(url,"/",1,3) // origin = "http(s)://origin.com:port"// ici vous pouvez vérifier les origines spécifiques// sinon, toutes les origines seront autorisées (utile uniquement lors du développement)do%response.SetHeader("Access-Control-Allow-Credentials","true")
do%response.SetHeader("Access-Control-Allow-Methods","GET,POST,PUT,DELETE,OPTIONS")
do%response.SetHeader("Access-Control-Allow-Origin",origin)
do%response.SetHeader("Access-Control-Allow-Headers","Access-Control-Allow-Origin, Origin, X-Requested-With, Content-Type, Accept, Authorization, Cache-Control")
quit$$$OK
}
ClassMethod GetTasks() As%Status
{
Try {
Do##class(%REST.Impl).%SetContentType("application/json")
If '##class(%REST.Impl).%CheckAccepts("application/json") Do##class(%REST.Impl).%ReportRESTError(..#HTTP406NOTACCEPTABLE,$$$ERROR($$$RESTBadAccepts)) QuitDo##class(%REST.Impl).%SetStatusCode("200")
set sql = "SELECT %Actions, %Message, %Priority, %Subject, TaskStatus_TimeCreated, ID FROM EnsLib_Workflow.TaskResponse WHERE TaskStatus_AssignedTo = ? AND TaskStatus_IsComplete = 0"set statement = ##class(%SQL.Statement).%New(), statement.%ObjectSelectMode = 1set status = statement.%Prepare(sql)
if ($$$ISOK(status)) {
set resultSet = statement.%Execute($USERNAME)
if (resultSet.%SQLCODE = 0) {
set tasks = []
while (resultSet.%Next() '= 0) {
set task = {"actions": "", "message": "", "priority": "", "subject": "", "creation": "", "id": ""}
set task.actions = resultSet.%GetData(1)
set task.message = resultSet.%GetData(2)
set task.priority = resultSet.%GetData(3)
set task.subject = resultSet.%GetData(4)
set task.creation = resultSet.%GetData(5)
set task.id = resultSet.%GetData(6)
do tasks.%Push(task)
}

}
}
set result = {"username": ""}
set result.username = $USERNAMEDo##class(%REST.Impl).%WriteResponse(tasks)
} <span class="hljs-keyword">Catch</span> (ex) {
    <span class="hljs-keyword">Do</span> <span class="hljs-keyword">##class</span>(<span class="hljs-built_in">%REST.Impl</span>).<span class="hljs-built_in">%SetStatusCode</span>(<span class="hljs-string">"400"</span>)
    <span class="hljs-keyword">return</span> ex.DisplayString()
}

<span class="hljs-keyword">Quit</span> <span class="hljs-built_in">$$$OK</span>
}
ClassMethod SaveTask() As%Status
{
Try {
Do##class(%REST.Impl).%SetContentType("application/json")
If '##class(%REST.Impl).%CheckAccepts("application/json") Do##class(%REST.Impl).%ReportRESTError(..#HTTP406NOTACCEPTABLE,$$$ERROR($$$RESTBadAccepts)) Quit// Lecture du corps de l'appel http avec les données relatives à la personneset dynamicBody = {}.%FromJSON(%request.Content)
    <span class="hljs-keyword">set</span> task = <span class="hljs-keyword">##class</span>(EnsLib.Workflow.TaskResponse).<span class="hljs-built_in">%OpenId</span>(dynamicBody.<span class="hljs-built_in">%Get</span>(<span class="hljs-string">"id"</span>))
    <span class="hljs-keyword">set</span> sc = task.CompleteTask(dynamicBody.action)

    <span class="hljs-keyword">if</span> <span class="hljs-built_in">$$$ISOK</span>(sc) {	        
        <span class="hljs-keyword">Do</span> <span class="hljs-keyword">##class</span>(<span class="hljs-built_in">%REST.Impl</span>).<span class="hljs-built_in">%SetStatusCode</span>(<span class="hljs-string">"200"</span>)
        <span class="hljs-keyword">Do</span> <span class="hljs-keyword">##class</span>(<span class="hljs-built_in">%REST.Impl</span>).<span class="hljs-built_in">%WriteResponse</span>({<span class="hljs-string">"result"</span>: <span class="hljs-string">"success"</span>})         
	}	
    
} <span class="hljs-keyword">Catch</span> (ex) {
    <span class="hljs-keyword">Do</span> <span class="hljs-keyword">##class</span>(<span class="hljs-built_in">%REST.Impl</span>).<span class="hljs-built_in">%SetStatusCode</span>(<span class="hljs-string">"400"</span>)
    <span class="hljs-keyword">Do</span> <span class="hljs-keyword">##class</span>(<span class="hljs-built_in">%REST.Impl</span>).<span class="hljs-built_in">%WriteResponse</span>({<span class="hljs-string">"result"</span>: <span class="hljs-string">"error"</span>})
}

<span class="hljs-keyword">Quit</span> <span class="hljs-built_in">$$$OK</span>
}
}

Comme vous pouvez le voir, nous résoudrons toute la logique dont nous avons besoin à partir de notre WS, mais je ne recommande pas de procéder de cette manière, car nous perdons la traçabilité possible en envoyant les requêtes reçues à la production configurée dans l'espace de noms Namespace.

En jetant un coup d'œil à la section URLMap, nous verrons que nous avons 2 points de terminaison configurés dans notre WS:

• getTasks: pour récupérer toutes les tâches en attente de l'utilisateur (si vous voyez le SQL utilisé, nous passons le nom d'utilisateur directement à partir de la variable générée lors de la connexion).
• saveTask: pour recevoir la réponse de l'utilisateur à la tâche et la terminer en exécutant la méthode CompleteTaks de la classe EnsLib.Workflow.TaskResponse.

De la part d'IRIS, tout serait déjà configuré pour que l'application externe se connecte.

Test de l'application externe avec le moteur de Workflow

Tout d'abord nous allons simuler l'envoi d'un message de HL7 vers notre production en copiant le fichier /shared/hl7/message_1_1.hl7 vers le chemin /shared/in, examinons donc le message que nous envoyons:

MSH|^~\&|HIS|HULP|EMPI||20240402111716||ADT^A08|346831|P|2.5.1
EVN|A08|20240402111716
PID|||07751332X^^^MI^NI~900263^^^HULP^PI||LÓPEZ CABEZUELA^ÁLVARO^^^||19560121|F|||PASEO MARIO FERNÁNDEZ 2581 DERECHA^^MADRID^MADRID^28627^SPAIN||555819817^PRN^^ALVARO.LOPEZ@VODAFONE.COM|||||||||||||||||N|
PV1||N
OBX|1|NM|162986007^Pulso^SNM||72|^bpm|||||F|||20240402111716
OBX|2|NM|105723007^Temperatura^SNM||37|^Celsius|||||F|||20240402111716
OBX|3|NM|163030003^Presión sanguínea sistólica^SNM||142|^mmHg|||||F|||20240402111716
OBX|4|NM|163031004^Presión sanguínea diastólica^SNM||83|^mmHg|||||F|||20240402111716

Pour ceux d'entre vous qui ne se rappellent pas les articles précédents, nous avions défini dans notre BPL qu'une alerte serait générée lorsque la pression systolique dépassait 140 ou la pression diastolique dépassait 90, par conséquent, ce message devrait générer une tâche d'alerte pour notre patient avec DNI (Document National d'Identification) 07751332X et une autre tâche automatique qui restera ouverte jusqu'à ce qu'IRIS reçoive le nouveau message.

Vérifions notre application mobile:

Deux tâches sont générées : la première est définie comme manuelle et dépend de l'utilisateur ; la seconde est définie comme automatique et, pour qu'elle disparaisse, l'utilisateur doit effectuer une nouvelle lecture avec son tensiomètre . Si nous examinons l'appel HTTP, nous pouvons voir comment nous y avons inclus le JWT:

Si l'utilisateur clique sur le bouton Accepter de la tâche en attente, le flux restera en attente de la lecture du tensiomètre et ne passera pas aux étapes suivantes. Une fois que la tâche manuelle est acceptée et qu'une nouvelle lecture du tensiomètre est reçue, dans laquelle les limites marquées sont à nouveau dépassées, le système génère deux nouvelles tâches d'avertissement, l'une pour le patient et l'autre pour le médecin associé, afin de l'avertir d'une crise possible:

Parfait! Nous avons déjà mis en place notre système de notification des patients de manière simple et rapide.

Conclusion

Comme vous l'avez vu dans cette série d'articles, la fonctionnalité du moteur de Workflow ainsi que les capacités d'interopérabilité d'InterSystems IRIS offrent un potentiel incroyable pour la mise en œuvre de processus métier que peu d'autres solutions métier peuvent fournir. Il est vrai que certaines connaissances techniques peuvent être nécessaires pour en tirer le maximum, mais le jeu en vaut vraiment la chandelle.

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 Workflowset sc = ##class(EnsLib.Workflow.UserDefinition).CreateUser(username)
   /// Assignation du rôle à l'utilisateur du Workflowset 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(SELECTIDINTO :taskId FROM EnsLib_Workflow.TaskResponse WHERE TaskStatus_AssignedTo = :username AND TaskStatus_IsComplete = 0AND %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!

Cela fait un certain temps que j'ai l'intention de faire une sorte de démonstration de concept avec la fonctionnalité Workflow (flux de travail), qui, comme beaucoup d'autres fonctionnalités disponibles dans IRIS, tend à passer inaperçue aux yeux de nos clients (et je fais ici mon mea culpa). C'est pourquoi j'ai décidé il y a quelques jours de développer un exemple de configuration et d'exploitation de cette fonctionnalité en la connectant à une interface utilisateur développée en Angular.

Pour ne pas faire un article trop long et le rendre plus accessible, je vais le diviser en 3 parties. Dans ce premier article, je présenterai la fonctionnalité de Workflow ainsi que l'exemple que nous allons résoudre. Le deuxième article détaillera la configuration et l'implémentation de la production qui sera responsable de la gestion du Workflow. Enfin, nous montrerons comment accéder aux informations disponibles dans notre Workflow via une application Web.

Moteur de Workflow dans InterSystems IRIS

Pour expliquer ce qu'est cette fonctionnalité de Workflow, rien de mieux que de copier la description qui en est faite dans la documentation d'IRIS.

Un système de gestion des flux de travail automatise la répartition des tâches entre les utilisateurs. L'automatisation de la distribution des tâches selon une stratégie prédéfinie rend l'attribution des tâches plus efficace et l'exécution des tâches plus responsable. Un exemple typique est celui d'une application de service d'assistance qui reçoit des rapports de problèmes de la part des clients, envoie ces rapports aux membres des organisations appropriées pour qu'ils prennent des mesures et, une fois le problème résolu, communique les résultats au client.

Le moteur de workflow dans InterSystems IRIS offre un niveau de fonctionnalité bien plus élevé que les systèmes de gestion de workflow traditionnels et autonomes.

Où trouvons - nous les fonctionnalités de Workflow dans notre IRIS? Très simple, depuis le Portail de Gestion:

Expliquons brièvement chacune des options disponibles avant d'entrer dans l'exemple de projet.

Les rôles de Workflow

Cette option fait référence aux rôles dans lesquels nous classerons les utilisateurs qui utiliseront la fonctionnalité. La définition du rôle est quelque peu confuse, je préfère la voir plutôt comme des types de tâches que nous pouvons créer à partir de notre production. Le nom attribué à ces rôles doit correspondre aux noms des Opérations Métier que nous déclarerons plus tard dans notre production pour créer les tâches associées à ces rôles.

Utilisateurs de Workflow

Les utilisateurs IRIS qui peuvent être assignés à différentes tâches seront associés à un ou plusieurs rôles. Les utilisateurs doivent être enregistrés auprès d'IRIS.

Les tâches de Workflow

Liste des tâches créées dans le système avec leurs informations associées. À partir de cette fenêtre, des tâches peuvent être attribuées aux différents utilisateurs correspondant au rôle de tâche.

Quelles sont ces tâches? C'est très simple, les tâches sont des instances de la classe EnsLib.Workflow.TaskRequest, l'objet de ce type sera envoyé depuis le Processus Métier dans lequel il a été généré vers une Opération Métier de la classe EnsLib.Workflow.Operation et avec le nom du rôle que nous avons précédemment créé. Cette action créera à son tour une instance de la classe EnsLib.Workflow.TaskResponse. L'Opération Métier ne renverra pas de réponse tant que la méthode CompleteTask de l'instance de classe TaskResponse n'aura pas été exécutée.

Liste de travail de Workflow

Semblable à la fonctionnalité précédente, il nous montre également une liste de tâches avec les informations qui leur sont associées.

Exemple de Workflow

Le projet que vous trouverez associé à cet article présente un exemple simplifié de solution à un problème typique des organisations de santé tel que le traitement des patients chroniques. Ces types de patients nécessitent un contrôle continu et une surveillance stricte pour lesquels, dans de nombreux cas, les professionnels impliqués dans les soins ne disposent pas des moyens les plus appropriés.

Dans l'exemple, nous allons voir comment nous pouvons surveiller les patients souffrant d'hypertension. Nous supposerons que les patients prennent leur tension artérielle quotidiennement avec un tensiomètre qui enverra la lecture au serveur où notre InterSystems IRIS est installé. Si la tension artérielle dépasse 140 pour la systolique et 90 pour la diastolique, le patient est informé qu'il faudra reprendre la tension artérielle après un certain temps et, si la tension dépasse à nouveau les limites, le patient et le médecin sont informés de la situation afin qu'ils puissent décider des mesures à prendre.

Pour ce faire, nous allons diviser ce flux de tâches en deux étapes:

Étape 1: Prise quotidienne de la tension artérielle.

1. Réception dans la production de messages HL7 avec des mesures de la pression artérielle.
2. Vérifier l'existence de l'utilisateur dans le système (et le créer s'il n'existe pas), puis enregistrer l'utilisateur dans les rôles impliqués dans le workflow.
3. Extraction des données de tension artérielle et comparaison avec le critère d'alerte.
4. Si les données dépassent les critères d'alerte:
   1. Création d'une tâche pour informer le patient de la situation et lui demander une nouvelle mesure de la tension artérielle.
   2. Création d'une tâche automatique pour gérer la deuxième lecture de la tension artérielle.
5. Si les données ne dépassent pas les critères d'alerte, le processus est clôturé jusqu'à la réception de la prochaine lecture le lendemain.

Étape 2: Réception de la deuxième lecture après que la première lecture dépasse les valeurs d'alerte.

1. Réception du message HL7 avec la deuxième lecture de données.
2. En attente d'une récupération automatique des tâches.
3. Si les niveaux de tension artérielle dépassent les critères d'alerte:
   1. La tâche automatique est clôturée en indiquant l'état d'alerte.
   2. Une tâche manuelle est créée pour le médecin qui signale la situation du patient.
   3. Une tâche manuelle est créée pour le patient, l'avertissant de la situation et du fait que son médecin a été informé.
4. Si les niveaux ne dépassent pas les critères d'alerte:
   1. La tâche automatique est clôturée indiquant qu'il n'y a pas de danger.

Dans le prochain article, nous entrerons dans les détails de la conception de notre organigramme afin de refléter ce qui a été dit plus haut.

Interface utilisateur

Comme vous l'avez vu dans les captures d'écran ci-jointes, l'interface utilisateur fournie par InterSystems IRIS pour la gestion des tâches est, pour le moins, assez spartiate, mais l'un des avantages que nous avons avec IRIS est que nous pouvons créer notre propre API REST pour gérer notre flux de tâches d'une manière très simple, nous discuterons de ce point dans notre dernier article.

Pour offrir une interface conviviale aux utilisateurs, nous avons développé une petite application web en Angular en utilisant Angular Material qui nous permettra de créer une interface qui simule une application mobile.

Cette application mobile se connectera à InterSystems IRIS à l'aide de JSON Web Tokens (jetons Web JSON) et effectuera des requêtes HTTP vers une application web spécifique publiée dans IRIS, de manière à ce que les actions entreprises par les différents acteurs sur les tâches soient reflétées dans le flux de tâches défini.

Dans le chapitre suivant...

Après cette introduction à la fonctionnalité Workflow, dans notre prochain article nous montrerons comment implémenter le flux de tâches nécessaire pour traiter l'exemple que nous avons présenté en utilisant une BPL, nous configurerons l'ensemble de la production et nous verrons quelles sont les principales classes impliquées dans le Workflow (EnsLib.Workflow.TaskRequest et EnsLib.Workflow.TaskResponse).

Merci à tous pour votre attention!

InterSystems a le plaisir d'annoncer la disponibilité générale de :

• Plateforme de données InterSystems IRIS 2024.1.0.267.2
• InterSystems IRIS for Health 2024.1.0.267.2
• HealthShare Health Connect 2024.1.0.267.2

Cette version ajoute la prise en charge du système d'exploitation Ubuntu 24.04. Ubuntu 24.04 inclut le noyau Linux 6.8, des améliorations de sécurité, ainsi que des améliorations du programme d'installation et de l'interface utilisateur. InterSystems IRIS IntegratedML n'est pas encore disponible sur Ubuntu 24.04.

De plus, cette version corrige deux défauts pour toutes les plateformes :

InterSystems a travaillé en étroite collaboration avec l'équipe Red Hat Insights pour mettre en œuvre un ensemble de recommandations destinées aux administrateurs de systèmes afin de garantir une expérience optimale de l'utilisation d'InterSystems IRIS sur Red Hat Enterprise Linux (RHEL). Inclus dans tous les abonnements RHEL, le service Insights identifie de façon proactive les problèmes potentiels des plateformes et applications surveillées fonctionnant sur RHEL. Grâce à notre collaboration conjointe, le service Insights surveille désormais les scénarios courants qui diminuent les performances de l'IRIS dans la plupart des cas et propose une recommandation approuvée par InterSystems à prendre en compte.  

Dix recommandations sont actuellement mises en œuvre et peuvent être trouvées sous le titre "InterSystems" dans le service Insights Advisor.  Les recommandations d'Advisor apportent une aide dans les domaines suivants:

1. Guide d'optimisation des performances. Nous fournissons les meilleures pratiques pour configurer les HugePages, les Transparent HugePages (THP), le swappiness, les paramètres du noyau shmmax, et plus encore.
2. Compatibilité des produits. Compatibilité des produits. Le service Insights met en évidence les versions des produits InterSystems dont l'utilisation est encouragée afin d'offrir la meilleure expérience possible.
3. Journalisation et suggestions de configuration de haute disponibilité, comme le mappage des lecteurs de Write Image Journaling (WIJ), l'identification d'un arbitre pour prendre en charge la défaillance automatique, ou l'activation de FreezeOnError pour améliorer l'intégrité et la capacité de récupération de la base de données InterSystems IRIS.

Chaque recommandation contient des détails sur la version RHEL détectée, des informations sur l'instance IRIS d'InterSystems et des instructions étape par étape spécifiques au système pour remédier au problème détecté.  Des liens vers la documentation d'InterSystems sont également fournis à titre de référence.

Activation immédiate d'Insights avec InterSystems.

L'enregistrement de vos systèmes avec Red Hat Insights est très simple et ne nécessite généralement que l'exécution d'une seule commande. Alternativement, l'application de l'assistant d'enregistrement de Red Hat peut être utilisée pour compléter les étapes nécessaires en fonction de votre configuration. L'analyse des charges de travail d'InterSystems IRIS ne nécessite pas d'étapes supplémentaires et est activée une fois que les systèmes sont enregistrés dans Insights. Des recommandations spécifiques peuvent être facilement désactivées si elles ne s'appliquent pas à votre environnement.  

Rendez-vous sur Red Hat Insights pour en savoir plus sur le service et commencer à utiliser l'assistant d'enregistrement.

Discutez avec les experts de Red Hat lors de l'InterSystems Global Summit 2024.

Red Hat sera présent à sommet mondial InterSystems Global Summit du 9 au 12 juin et sera disponible pour discuter d'Insights et d'autres fonctionnalités de Red Hat.

Alerte : la requête SQL utilisant « NOT %INLIST » ne parvient pas à renvoyer les résultats

InterSystems a corrigé un problème qui pouvait entraîner le renvoi de résultats incorrects par un petit nombre de requêtes SQL. Voir ci-dessous pour les détails des requêtes concernées.

Ce problème existe dans les versions répertoriées des produits suivants :

• Plateforme de données InterSystems IRIS®
• InterSystems IRIS for Health™
• HealthShare® Health Connect

Ainsi que:

• Autres produits InterSystems basés sur les produits ci-dessus.

Versions concernées :

Les versions de maintenance 2022.1.5 et 2023.1.4 d'InterSystems IRIS, IRIS for Health et HealthShare HealthConnect sont désormais disponible

Deux versions de maintenance étendue d'InterSystems IRIS, InterSystems IRIS for Health et HealthShare Health Connect sont désormais disponibles.

✅ 2022.1.5

La version 2022.1.5 fournit des corrections de bogues pour toutes les versions 2022.1.x précédentes.

Vous pouvez trouver les listes de modifications détaillées et les listes de contrôle de mise à niveau sur ces pages :

• InterSystems IRIS
• InterSystems IRIS for Health
• HealthShare Health Connect

✅ 2023.1.4

Bonjour la Communauté,

Cliquez sur play et plongez-vous dans notre nouvelle vidéo sur InterSystems Developers YouTube:

⏯ HealthShare Health Connect - Upgrade Automation with Production Validator @ Global Summit 2023