Envoyer le flux de travail d’alerte du client

Le flux de travail d’envoi d’alertes permet aux services d’infrastructure d’enregistrer des alertes avec un service d’alerte. Le service d’alerte permet aux consommateurs alertés de demander ces alertes et de les envoyer aux clients (patients) dans le format approprié (SMS, e-mail, etc.).

Une alerte est conçue comme une communication essentiellement unilatérale vers un client du système. Les cas d’utilisation des alertes comprennent :

1. Réaction à une crise

En réaction à une crise ou à une situation d’urgence, telle que les épidémies d’Ebola de 2014 et 2015 en Afrique de l’Ouest, il est essentiel de communiquer avec les clients au sein d’un réseau de soins de santé particulier et de vérifier, dans la mesure du possible, la réception de l’alerte.

2. Rappels de soins

Une personne qui reçoit des soins peut recevoir des soins de plusieurs prestataires à travers plusieurs réseaux de soins de santé, et la coordination des soins entre les prestataires et les réseaux est difficile. Si un dossier médical électronique ou un dossier médical longitudinal/partagé existe, des alertes de rappel de soins peuvent être déclenchées par l’examen des dossiers cliniques concernant la personne qui reçoit les soins. Les alertes de rappel de soins sont envoyées à la personne qui reçoit les soins.

Bien que l’infrastructure du flux de travail d’alerte indiquée ci-dessous permette la communication de nombreux types de messages, d’alertes ou de notifications supplémentaires, il n’est pas prévu que ces messages aillent au-delà des cas d’utilisation précédents. Ils ne comprennent pas notamment les « conclusions critiques » ou d’autres types d’alertes qui nécessitent une action immédiate.

La norme IHE mACM sur laquelle repose ce flux de travail prévoit que d’autres profils IHE utilisant mACM seront développés afin de répondre à des flux de travail d’alerte plus vastes.

Échéance du flux de travail	Arriver à échéance	· Le flux de travail est défini et approuvé par ARB · Le flux de travail est pris en charge par la norme émergente IHE mACM dans la mise en œuvre d’essai
Normes*		1. Recherche FHIR DSTU2 sur l’emplacement, le fournisseur ou les ressources du patient/réponse de recherche groupée FHIR DSTU2 OU Demande ITI-73 Trouver des services CSD correspondants/ITI-73 Trouver une réponse des services correspondants 2. Recherche FHIR sur la demande de ressources du patient (PDQm)/Réponse de recherche groupée FHIR DSTU2 OU Demande PIX/PDQ - Réponse PIX/PDQ
Hypothèses et conditions préalables		Aucune
		Rapporteur d’alertes : le système de point de service qui enregistre les identifiants des patients, est responsable de l’envoi des identifiants à HIE. Un rapporteur d’alertes doit émettre ou relayer des alertes (une alarme, physiologique ou technique, ou un avis) à l’agrégateur d’alertes. Cet acteur peut éventuellement interroger un Acteur Agrégateur d’Alerte pour des statistiques liées à la diffusion de cette alerte au(x) destinataire(s) prévu(s) Dans le flux de travail ci-dessous, le rapporteur d’alertes est présenté comme un acteur générique. Les exemples comprennent : · Un système d’information de gestion de la santé (IHMS) remarque un indicateur de seuil sur le nombre de cas de choléra pour un district. Un HMIS pourrait agir en tant que rapporteur d’alertes en interrogeant un registre des professionnels de santé afin de déterminer une liste de tous les clients dans le district et de générer une alerte indiquant qu’ils devraient être informés du nombre accru de cas de choléra et fournir des informations sur la prévention des maladies. · Un médiateur dans la couche d’interopérabilité pourrait surveiller un dossier médical partagé et remarquer qu’un enfant a manqué une vaccination conformément à un protocole de soins établi. Le médiateur agirait en tant que rapporteur d’alertes et il enverrait un rappel par SMS à la mère ou à un autre tuteur désigné. · Un médiateur peut surveiller un système électronique central d’orientation et un dossier médical partagé afin de détecter si le patient a manqué son orientation en vérifiant si une rencontre a été reçue dans dossier médical longitudinal dans le délai indiqué dans l’orientation. Si une rencontre n’a pas été reçue, le médiateur agit en tant que rapporteur d’alertes et il envoie une alerte du rendez-vous manqué au client. Agrégateur d’alertes : un système chargé d’envoyer une alerte à un client. L’agrégateur d’alertes gère ces alertes en fonction du contexte commercial défini par la juridiction requise, par exemple en les envoyant sur une plateforme de communication pour une livraison à un destinataire prévu. L’agrégateur d’alertes peut éventuellement recueillir des statistiques liées à la diffusion de l’alerte telles que le statut de la livraison ou la valeur d’une réponse ou d’un accusé de réception SMS.
Acteurs

Description de l’interaction

N°	Interaction	Données/Remarques	Option de transaction
1	Constater une condition d’alerte (définie par les règles commerciales du rapporteur d’alertes)
2	Recherche du ou des identifiant(s) du patient		Recherche FHIR sur demande de ressources du patient (PDQm) OU Demande PIX/PDQ
3	Recherche du ou des identifiant(s) du patient
4/5	Identifiants de retour	Les transactions FHIR sont plus alignées sur la transaction mACM ITI-84 qui contient des références à l’organisation, à l’emplacement (par exemple, l’établissement) ou aux ressources du fournisseur	Réponse de recherche groupée FHIR DSTU2 OU Réponse PIX/PDQ
6	Rapport d’alertes	Identifiants des destinataires transmis soit en se référant à la ressource appropriée du FHIR (nécessite un serveur FHIR pour ces ressources) OU Identifiants des destinataires transmis en tant que référence intégrée aux ressources appropriées du FHIR (ne nécessite pas de serveur FHIR)	Rapport d’alertes mobile ITI 84 (mACM)
7	Rapport d’alertes		Rapport d’alertes mobile ITI 84 (mACM)
8	Recherche du ou des identifiant(s) du patient		Recherche FHIR sur demande de ressources du patient (PDQm) OU Demande PIX/PDQ
9	Identifiants de retour	La mise en œuvre de référence actuelle de ILR (OpenlnfoMan) prend en charge ces deux transactions. Les transactions FHIR sont plus alignées sur la transaction mACM ITI-84 qui contient des références à l’organisation, à l’emplacement (par exemple, l’établissement) ou aux ressources du prestataire	Réponse de recherche groupée FHIR DSTU2 OU Réponse PIX/PDQ
10	Diffuser une alerte		Diffuser la ou les alertes via les mécanismes de communication appropriés disponibles dans HIE (SMS, e-mail, système POC, etc.). Les transactions dépendent du canal de communication.
11	Réponse
12	Mettre à jour le statut de la diffusion		Les transactions ne sont pas spécifiées (actuellement) par la norme mACM. Remarque : RapidPro utilise un point de terminaison personnalisé conforme à FHIR « Communication/$response » et « Communication/$sent » à cet effet.
13	Demande du statut de l’alerte		Demande de requête du statut de l’alerte ITl-85 (mACM)
14	Demande du statut de l’alerte		Demande de requête du statut de l’alerte ITl-85 (mACM)
15	Demande du statut de l’alerte		Requête du statut de l’alerte ITl-85 (mACM) Réponse
16	Demande du statut de l’alerte		Requête du statut de l’alerte ITl-85 (mACM) Réponse