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
Last updated