Brevet FR3067158A1 — publié le 20181207

PROCEDE DE TRAITEMENT DE DONNEES NUMERIQUES HYBRIDES Domaine de l'invention La présente invention concerne le domaine de la gestion des données hybrides, comportant des données techniques, des données personnelles et des données de santé, et plus généralement des données susceptibles d'améliorer le suivi et l'aide à distance de personnes fragiles telles que des personnes âgées. Le traitement de ces données implique le respect de contraintes particulières pour celles qui entrent dans le cadre réglementaire des données de santé, et notamment l'utilisation de ressources informatiques particulières. Les données de santé concernent les données médicales et/ou relatives aux déterminants généraux de santé, et à la santé d'une personne, d'un groupe de personnes (couple, famille, quartier, ville, région, ethnie, pays, etc.) ou de populations. Le traitement informatique de ces données sensibles 20 implique des choix techniques permettant de garantir l'anonymat et l'absence de risque de ré-identification des patients. Pour ces raisons, l'hébergement des données de santé nécessite des infrastructures et des protocoles dédiés, 25 souvent soumis à un agrément préalable des autorités de la santé et prochainement à une certification. Etat de la technique 30 On connaît dans l'état de la technique le brevet européen EP1994484 qui décrit un exemple de système de plate-forme d'échange de données de soins de santé interopérable pour 3067158 - 2 - rassembler des dossiers médicaux de patients depuis une pluralité d'emplacements disparates. Ce système de plate-forme comprend : - un service de gestion de messages pour demander et 5 recevoir les dossiers médicaux en temps réel et assurant la conversion des dossiers médicaux en un protocole standard ; - un moteur de mise en correspondance qui reçoit les dossiers médicaux convertis et met en correspondance les dossiers médicaux convertis avec une terminologie de santé 10 standard ; - un espace de stockage de données pour recevoir et stocker les dossiers médicaux convertis mis en correspondance, et comprenant plusieurs composants centraux incluant un index patients maître, un annuaire de fournisseurs ou un service 15 localisateur de dossiers, et des informations codées avec un identifiant spécifié pour chaque patient. Cet index patients maître inclut un processus de contrôle de changement strict pour les informations concernant les patients pour lier des informations disparates concernant des 20 patients reçues de systèmes externes dans un fichier. La demande de brevet EP 3129925 décrit une autre solution destinée à la collecte et la gestion de données de patients délivrées par des appareils de mesure. Un tel système comporte une plateforme collectant et assurant la gestion desdites 25 données et coopérant avec un serveur de dossiers patients informatisés et avec une pluralité de dispositifs communicants. La plateforme élabore et transmet au serveur des requêtes en mise à jour de dossiers patients informatisés pertinentes et complètes. 30 Inconvénients de l'art antérieur Les solutions de l'art antérieur impliquent des traitements lourds, avec des protocoles de transport de 3067158 -3 - données fortement sécurisés, des moyens d'anonymisation des données dès la génération de ces données par une interface humaine ou un équipement connecté, et des traitements techniques très contraignants au niveau de la production des 5 données. Dans des environnements non spécialisés, l'application de ces solutions connues est difficilement compatible avec des équipements connectés qui n'ont pas été conçus pour respecter les impératifs d'anonymisation et de sécurisation, alors même qu'une adresse IP voire une adresse 10 IP partiellement masquée peut être considérée comme ne protégeant pas suffisamment les obligations en matière de traitement de données personnelles ou de données de santé. La démarche normale de l'homme du métier serait d'exploiter une plateforme adaptée au traitement de données de 15 santé, pour la gestion de tous les échanges entre chacun des équipements de l'utilisateur et la plateforme de traitement. Cela se traduirait par une solution complexe et couteuse. Une autre démarche normale pour l'homme du métier consisterait à distinguer les applications susceptibles de transmettre des données de santé, et de réserver la communication avec une plateforme de traitement de données de santé, et les autres applications et équipements, qui communiqueraient avec un serveur de manière habituelle et simplifiée. Se poserait alors des problèmes de traitement globaux des données d'un utilisateur et de synchronisation des données entre les différentes plateformes, ainsi que de portabilité de ces données de l'utilisateur. Solution apportée par l'invention Afin de remédier à ces inconvénients, la présente invention concerne selon son acception la plus générale un procédé de traitement de données numériques comprenant des 3067158 - 4 - données numériques soumises aux contraintes applicables aux données de santé, comprenant : une étape initiale de synchronisation entre un compte utilisateur enregistré sur un premier serveur et 5 un compte de santé enregistré sur une plateforme de traitement de données de santé par l'intermédiaire d'un identifiant numérique unique ID u ne comportant aucune information associée à l'identité de l'utilisateur et lors de la transmission par un utilisateur 10 d'informations, o une étape d'ouverture d'une session sécurisée entre un équipement de l'utilisateur et ledit premier serveur, o une étape de transmission d'une séquence 15 numérique par ledit équipement audit serveur et d'enregistrement dans une mémoire vive dynamique à l'exclusion de tout enregistrement dans une mémoire permanente, o une étape d'analyse par le calculateur du 20 serveur du contenu de ladite séquence numérique transmises par ledit équipement et - d'enregistrement local dans une mémoire permanente des informations numériques extraites de ladite séquence numérique ne 25 correspondant pas à des données de santé - de transmission à ladite plateforme de santé et d'effacement de ladite mémoire vive dynamique des informations numériques extraites de ladite séquence numérique correspondant à 30 des données de santé associées à l'IDu. Selon un mode de mise en oeuvre avantageux, ladite étape initiale consiste, lors de l'enregistrement d'un nouveau compte, à enregistrer sur un premier serveur des informations numériques relatives au nouveau compte et à générer un identifiant unique ID, idéalement stocké de façon persistante 3067158 - 5 - au sein du premier serveur de façon à pouvoir le retrouver ultérieurement, puis à commander la transmission par ledit premier serveur dudit identifiant unique ID u à une plateforme de traitement de données de santé, puis à commander la 5 création d'un compte sur ladite plateforme de traitement de données de santé. Selon une variante particulière, la transmission à la plateforme de traitement de données de santé des informations 10 numériques extraites comporte une étape d'ouverture d'une session sécurisée entre ledit premier serveur et ladite plateforme, avec un jeton de transaction dont la durée de validité est idéalement limitée dans le temps et calculé en fonction de l'identifiant unique de l'utilisation ID, 15 l'ouverture d'un accès au service de gestion de l'espace de stockage sécurisé et l'enregistrement des données de santé transmises par ledit premier serveur, puis la destruction dudit jeton de transaction et la suppression des informations de la mémoire vive dynamique du premier serveur. 20 Selon une variante, les séquences numériques transmises par un équipement de l'utilisateur comportent un marqueur numérique des données de santé. Ce marqueur permet de 25 faciliter l'identification des données qui relèvent du serveur HDS de celles qui n'en relèvent pas. Selon une variante particulière, lesdites séquences numériques proviennent d'un équipement local connecté d'un système d'aide à distance de personnes fragiles ou 30 potentiellement fragiles. L'invention concerne aussi un système de traitement de données numériques comprenant des données numériques soumises aux contraintes applicables aux données de santé, comprenant une plateforme de traitement de données de santé caractérisé 35 en ce qu'il comporte en outre un serveur comportant des moyens 3067158 -6 - de communication avec les équipements informatiques des utilisateurs et commandé par un programme commandant : une étape initiale de synchronisation entre un compte utilisateur enregistré sur un ledit serveur et un 5 compte de santé enregistré sur une plateforme de traitement de données de santé par l'intermédiaire d'un identifiant numérique unique ID u ne comportant aucune information associée à l'identité de l'utilisateur et lors de la transmission par un utilisateur 10 d'informations, o une étape d'ouverture d'une session sécurisée entre un équipement de l'utilisateur et ledit premier serveur, o une étape de transmission d'une séquence 15 numérique par ledit équipement audit serveur et d'enregistrement dans une mémoire vive dynamique à l'exclusion de tout enregistrement dans une mémoire permanente, o une étape d'analyse par le calculateur du 20 serveur du contenu de ladite séquence numérique transmises par ledit équipement et - suite à récupération préalable de l'IDu, d'enregistrement local dans une mémoire permanente des informations numériques 25 extraites de ladite séquence numérique ne correspondant pas à des données de santé - de transmission à ladite plateforme de santé et d'effacement de ladite mémoire vive dynamique des informations numériques extraites 30 de ladite séquence numérique correspondant à des données de santé avec adjonction de l'IDu. L'invention concerne également un système d'aide à distance de personnes fragiles ou potentiellement fragiles, utilisant le système de traitement de données numériques ci-35 dessus et comprenant : 3067158 - 7 - A. une pluralité d'équipements locaux répartis dans différents logements individuels de différentes personnes comportant chacun : a. une pluralité de ports de communication locaux pour 5 l'échange d'informations : i. avec au moins un capteur de surveillance d'un paramètre physique ou biologique de la personne ii. avec un périphérique comportant une interface de dialogue homme-machine locale 10 b. des moyens d'enregistrement de données historisées sur une période donnée, issues de chaque capteur, dans une mémoire locale sous la forme d'au moins un profil de référence c. un moyen de communication de type Internet, avec le serveur distant ainsi qu'un moyen de communication secondaire 15 de type GSM pour l'envoi de messages d'alerte d. un calculateur exécutant des traitements suivants : i. l'activation d'un processus de confirmation d'alerte locale en fonction des données locales recueillies, requérant une action locale de confirmation ou d'infirmation 20 conditionnant l'émission d'une alerte locale ou la clôture de la séquence et ii. le déclenchement de l'envoi d'un processus d'alerte distant en fonction de l'action locale intervenue dans un intervalle de temps prédéterminé 25 iii. un traitement de marquage des informations transmises par chaque capteur, consistant à associer un identifiant de la personne et une information d'horodatage aux données numériques délivrées par le capteur, de manière conditionnelle en fonction du résultat d'un traitement local préalable 30 iv. un traitement de télétransmission audit serveur distant des données marquées de manière conditionnelle d'une part, et des données historisées anonymisées de manière inconditionnelle d'autre part B. le serveur distant, commun à une pluralité 35 d'équipements locaux, commandant les traitements suivants : 3067158 - 8 - a. des séquences d'actions en fonction des données marquées transmises par un équipement local, et transmises à l'équipement local correspondant et/ou à au moins un périphérique d'un tiers associé à l'équipement local 5 b. des séquences d'envoi de messages locaux à une pluralité d'équipements locaux en fonction de données génériques et/ou en fonction des données émises par ces équipements locaux et/ou en fonction des actions locales effectuées sur les équipements locaux. 10 Ce système d'aide à distance peut par ailleurs présenter l'une et/ou l'autre des caractéristiques suivantes : - les données locales recueillies pour l'activation du 15 processus de confirmation d'alerte locale comprennent les données recueillies par les capteurs associés à l'équipement local - les données locales recueillies pour l'activation du 20 processus de confirmation d'alerte locale comprennent des données issues d'un agent conversationnel - les données locales recueillies pour l'activation du processus de confirmation d'alerte locale comprennent des 25 données issues de moyens de reconnaissance d'un message vocal prédé fini -le calculateur exécute un traitement de désactivation du processus de confirmation d'alerte sur détection d'un 30 événement déclencheur d'autorité tel que l'activation d'un médaillon de sécurité, et exécute le déclenchement d'une alerte locale et d'une alerte distante 3067158 - 9 - - l'action locale de confirmation ou d'infirmation d'alerte est mise en oeuvre par un agent conversationnel pour la levée de doute. 5 Description détaillée d'un exemple non limitatif de l'invention La présente invention sera mieux comprise à la lecture de la description détaillée d'un exemple non limitatif de 10 l'invention qui suit, se référant aux dessins annexés où : - la figure 1 représente une vue schématique de l'architecture système d'une solution selon l'invention - la figure 2 représente une vue schématique du flux d'information lors de la collecte de données 15 la figure 3 représente une vue schématique du flux d'information lors du requêtage d'une donnée non sensible la figure 4 représente une vue schématique du flux d'information lors du requêtage d'une donnée de 20 santé. En référence à la figure 2, qui illustre la collecte d'informations sensibles et/ou hors de portée du système 25 principal et gérées en HDS, l'utilisateur saisit un formulaire contenant plusieurs informations (repère 1): de nature sensible / HDS de nature standard. Conformément au repère 2, les données transmises sont 30 interprétées et seules celles de nature standard et gérées par le système principal, sont stockées dans le système principal. En retour, conformément au repère 2', l'identifiant de stockage propre au système HDS est récupéré. Il est unique et anonyme. 3067158 - 10 - Conformément au repère 3, les autres données dites sensibles et/ou hors portée du système principal, sont transmises au système partenaire dédié pour les héberger (sensible ou autre)) en HDS, système partenaire auprès duquel 5 le système principal est authentifié. En référence à la figure 3 qui illustre la récupération d'une information non sensible auprès d'un partenaire HDS par un utilisateur le désirant, l'utilisateur fait une demande 10 auprès du système principal conformément au repère 4. Le système principal récupère l'identifiant anonyme de l'utilisateur dans le système HDS conformément aux repères 5 et 5'. Le système principal requiert l'information non sensible 15 (exemple : conseil bien-être) auprès du système HDS qui la gère conformément aux repères 6 et 6'. L'information est restituée et mise en forme par le système principal conformément au repère 7. 20 En référence à la figure 4 qui illustre la récupération d'une information sensible auprès d'un partenaire HDS par un utilisateur le désirant, le système principal fournit l'affichage d'une fonctionnalité conformément au repère 8. Tout lien ou interaction mettant en jeu la restitution d'une 25 donnée sensible est réalisé en référençant directement le système HDS en charge. Conformément aux repères 9 et 9', l'utilisateur sélectionne une fonctionnalité sensible qui est directement prise en compte par le système HDS qui répond. 30 Ce procédé de traitement de données hybrides peut être mis en oeuvre au sein d'une architecture telle que présentée sur la figure 1, pour former un système d'aide à distance pour personnes fragiles conçu pour participer au maintien à 35 domicile de la personne en toute vigilance vis à vis de son 3067158 état de santé et dans le plus grand respect de sa personne et de ses aptitudes sociales et mentales, de façon à emporter son adhésion et à favoriser sa prise en charge. 5 Un tel système utilise des équipements locaux répartis chez les différents utilisateurs à aider à distance, et qui recueillent des données les concernant par le biais de différents capteurs. Chaque équipement local ou box comprend en outre un moyen 10 de communication de type Internet, avec un serveur distant (par exemple serveur API) ainsi qu'un moyen de communication secondaire de type GSM pour l'envoi de messages d'alerte à ce même serveur. Conformément à la figure 1, le serveur API est en outre en 15 communication avec différents serveurs et/ou terminaux de différentes entités partenaires du système selon l'invention tels qu'un partenaire médical de gestion du carnet de liaison médical contenant des données personnelles confidentielles et sensibles, un partenaire de gestion des informations portant 20 sur le Bien-être de la personne ne contenant pas de données dites sensibles. Les serveurs des partenaires de ce type pourront être amenés à stocker localement dans leur propre serveur des données ou certaines des données concernant les personnes 25 aidées à distance par le système selon l'invention, à modifier ces données, modifications dont tout ou partie sera retransmise au serveur API par le serveur du partenaire considéré, et redistribuées par le serveur API aux serveurs des partenaires pertinents relativement à la donnée modifiée 30 en fonction des accords prédéfinis entre les partenaires. Le traitement de ces données hybrides recueillies par la box ou l'un ou l'autre des serveurs partenaires sera effectué conformément au procédé de traitement de ces données exposé précédemment. 35 3067158 - 12 - Présentation d'une architecture générale d'un système faisant intervenir le procédé de traitement de données numériques ci-dessus, en référence à la figure 1 : 5 Les boîtes X, Y et Z matérialisent trois partenaires distincts amenés à gérer des données de santé et/ des données non santé d'un ou de plusieurs utilisateurs. Pour chaque partenaire, l'intégration entre le portail et un serveur du partenaire est réalisée sous deux formes : 10 - Une intégration avec une API Rest/Json permettant d'échanger entre les systèmes (ex : création d'un compte). - Une intégration par IHM pour l'utilisateur pour qu'il puisse disposer des fonctionnalités spécifiques du partenaire 15 On liste ci-dessous les composants utilisés Système d'exploitation Linux Plate-forme Java 20 OSGi OSGi est une norme (https://www.osgi.org/) qui définit un socle technique reposant sur le langage Java et fournissant une approche modulaire. Ce socle spécifie également un 25 ensemble de fonctionnalités répondant à des problématiques d'entreprise telles que : - la journalisation, - le paramétrage et sa modification à chaud, - un cycle de vie des modules (bundle), 30 - la capacité de gérer plusieurs versions d'un module. Apache FELIX FELIX est une implémentation opensource de la norme OSGi. Il est développé et maintenu par la fondation Apache. (https://felix.apache.org/). 35 3067158 - 13 - Apache KARAF KARAF est un produit opensource développé par la fondation Apache. Il s'agit d'un conteneur moderne et polymorphe. Il s'appuie sur un conteneur OSGi et propose des 5 fonctionnalités supplémentaires telles que : - la configuration dynamique, - le provisionnement : Karaf introduit la notion de « feature » permettant de regrouper des modules et déclarer des dépendances entre modules, 10 - le management : Karaf fournit un ensemble de métriques et d'opérations via JMX afin de s'intégrer dans un environnement d'entreprise. HAZELCAST 15 HAZELCAST est une implémentation de cache en mémoire distribué. Il est développé en Java et offre de nombreuses fonctionnalités telles que : - utilisation du mode pair à pair « peer to peer ». 20 Cela permet d'éviter le syndrome du SPOF (Single Point of Failure). - scalabilité. HAZELCAST détecte automatiquement les nouveaux noeuds et ceux-ci sont synchronisés 25 Apache KARAF CELLAR (repéré par « C » sur la figure 1) CELLAR (http://karaf.apache.org/manual/cellar/latest-4/) est un composant de KARAF permettant d'intégrer des instances Karaf dans un environnement clusterisé. CELLAR offre des fonctions de management pour piloter plusieurs instances 30 telles que : - déploiement d'un module sur toutes les instances KARAF d'un cluster, - paramétrage à chaud sur toutes les instances KARAF d'un cluster. 3067158 - 14 - CELLAR utilise également HAZELCAST afin de synchroniser plusieurs instances. Cela permet d'assurer une haute disponibilité. 5 Apache Camel Camel est un framework de médiation et de routage. C'est un projet opensource développé et maintenu par la fondation apache. L'architecture de camel permet de répondre à un ensemble 10 de problématiques d'entreprise sous forme de patron d'intégration. CAS Le CAS (Central Authentication Service) est un système 15 d'authentification unifiée (SSO). Il est opensource et permet d'intégrer plusieurs sources d'authentification (base de données, annuaire, réseaux sociaux, ...) - CAS utilise également HAZELCAST afin de synchroniser 20 plusieurs instance CAS. Cela permet d'assurer une haute disponibilité. Selon un exemple de réalisation, le CAS est utilisé dans le périmètre Care Captain où le portail e-Santé porte les fonctionnalités d'authentification et de gestion du SSO. 25 KONY (repéré par « K » sur la figure 1) KONY est une plate-forme de développement mobile permettant de développer des applications mobiles multisupports. 30 MongoDB MongoDB est une base de données orientée document. Le terme « document » signifie un ensemble de données structurées et regroupées entre elle. 3067158 - 15 - Il n'est pas nécessaire de définir de schémas, ce qui permet d'adapter la base de données aux besoins spécifique de chaque sous-système. 5 Artifactory Artifactory est un gestionnaire de dépôts. Il permet de gérer les déploiements des packages applicatifs. Apache Karaf peut s'appuyer sur Artifactory afin de gérer les dépendances de bundle lors du déploiement d'un nouveau 10 composant logiciel. Ce composant doit être partagé avec tous les environnements afin de centraliser le déploiement et l'installation d'une nouvelle version d'un composant. 15 Angular Angular un framework Web permettant le développement Web du portail. Il sert de socle technique. Une application Angular permet d'avoir une application sur 20 une simple page L'ajout d'un framework graphique type bootstrap permet de réaliser des IHM ergonomique et sensible. Serveur Web 25 Le serveur Web permet de stocker les ressources statiques ainsi que l'application Angular que l'utilisateur va charger sur son navigateur au début de sa session. API-Gateway 30 L'API-Gateway est un service fourni par AXWAY. Il permet de faire la médiation des interactions entre le système central, les systèmes externes et les applications clientes mobiles et Web. Ce service fournit un ensemble de fonctionnalités dont : 35 - la gestion des droits d'accès aux API, REVENDICATIONS1 - Procédé de traitement de données numériques comprenant des données numériques soumises aux contraintes applicables 5 aux données de santé, comprenant : une étape initiale de synchronisation entre un compte utilisateur enregistré sur un premier serveur et un compte de santé enregistré sur une plateforme de traitement de données de santé par l'intermédiaire d'un 10 identifiant numérique unique ID a ne comportant aucune information associée à l'identité de l'utilisateur et lors de la transmission par un utilisateur d'informations, o une étape d'ouverture d'une session 15 sécurisée entre un équipement de l'utilisateur et ledit premier serveur, o une étape de transmission d'une séquence numérique par ledit équipement audit serveur et d'enregistrement dans une mémoire vive dynamique à 20 l'exclusion de tout enregistrement dans une mémoire permanente, o une étape d'analyse par le calculateur du serveur du contenu de ladite séquence numérique transmise par ledit équipement et 25 d'enregistrement local dans une mémoire permanente des informations numériques extraites de ladite séquence numérique ne correspondant pas à des données de santé de transmission à ladite plateforme de 30 santé et d'effacement de ladite mémoire vive dynamique des informations numériques extraites de ladite séquence numérique correspondant à des données de santé associées à l'IDu. 3067158 - 18 - 2 - Procédé de traitement de données numériques comprenant des données numériques soumises aux contraintes applicables aux données de santé selon la revendication 1 caractérisé en ce que ladite étape initiale consiste,de lors l'enregistrement d'un nouveau compte, à enregistrer sur un premier serveur des informations numériques relatives au nouveau compte et à générer un identifiant unique IDE, puis à commander la transmission par ledit premier serveur dudit identifiant unique ID u à une plateforme de traitement de données de santé, puis à commander la création d'un compte sur ladite plateforme de traitement de données de santé 3 - Procédé de traitement de données numériques comprenant des données numériques soumises aux contraintes applicables aux données de santé selon la revendication 1 ou 2 caractérisé en ce que la transmission à la plateforme de traitement de données de santé des informations numériques extraites comporte une étape d'ouverture d'une session sécurisée entre ledit premier serveur et ladite plateforme, avec un jeton de transaction calculé en fonction de l'identifiant unique de l'utilisation ID, l'ouverture d'un accès à l'espace de stockage sécurisé et l'enregistrement des données de santé transmise par ledit premier serveur, puis la destruction dudit jeton de transaction et la suppression des informations de la mémoire vive dynamique du premier serveur. 4 - Procédé de traitement de données numériques comprenant des données numériques soumises aux contraintes applicables aux données de santé selon l'une des revendications précédentes, caractérisé en ce que les séquences numériques transmises par un équipement de l'utilisateur comportent un marqueur numérique des données de santé. 3067158 19 -- 5 - Procédé de traitement de données numériques comprenant des données numériques soumises aux contraintes applicables aux données de santé selon la revendication 1 caractérisé en ce que lesdites séquences numériques proviennent d'un 5 équipement local connecté d'un système d'aide à distance de personnes fragiles ou potentiellement fragiles. 6 - Système de traitement de données numériques comprenant des données numériques soumises aux contraintes applicables 10 aux données de santé, comprenant une plateforme de traitement de données de santé caractérisé en ce qu'il comporte en outre un serveur comportant des moyens de communication avec les équipements informatiques des utilisateurs et commandé par un programme commandant : 15 une étape initiale de synchronisation entre un compte utilisateur enregistré sur ledit serveur et un compte de santé enregistré sur une plateforme de traitement de données de santé par l'intermédiaire d'un identifiant numérique unique ID u ne comportant aucune 20 information associée à l'identité de l'utilisateur et lors de la transmission par un utilisateur d'informations, o une étape d'ouverture d'une session sécurisée entre un équipement de l'utilisateur et 25 ledit premier serveur, o une étape de transmission d'une séquence numérique par ledit équipement audit serveur et d'enregistrement dans une mémoire vive dynamique à l'exclusion de tout enregistrement dans une mémoire 30 permanente, o une étape d'analyse par le calculateur du serveur du contenu de ladite séquence numérique transmises par ledit équipement et - d'enregistrement local dans une mémoire permanente des informations numériques 3067158 20 - extraites de ladite séquence numérique ne correspondant pas à des données de santé de transmission à ladite plateforme de santé et d'effacement de ladite mémoire vive 5 dynamique des informations numériques extraites de ladite séquence numérique correspondant à des données de santé associées à l'IDu. 7 - Système d'aide à distance de personnes fragiles ou 10 potentiellement fragiles, utilisant le système de traitement de données numériques selon la revendication précédente, comprenant : A. une pluralité d'équipements locaux répartis dans différents logements individuels de différentes personnes 15 comportant chacun : a. une pluralité de ports de communication locaux pour l'échange d'informations : j. avec au moins un capteur de surveillance d'un paramètre physique ou biologique de la personne 20 ii. avec un périphérique comportant une interface de dialogue homme-machine locale b. des moyens d'enregistrement de données historisées sur une période donnée, issues de chaque capteur, dans une mémoire locale sous la forme d'au moins un profil de référence 25 c. un moyen de communication de type Internet, avec le serveur distant ainsi qu'un moyen de communication secondaire de type GSM pour l'envoi de messages d'alerte d. un calculateur exécutant des traitements suivants : i. l'activation d'un processus de confirmation d'alerte 30 locale en fonction des données locales recueillies, requérant une action locale de confirmation ou d'infirmation conditionnant l'émission d'une alerte locale ou la clôture de la séquence et 3067158 - 21 - ii. le déclenchement de l'envoi d'un processus d'alerte distant en fonction de l'action locale intervenue dans un intervalle de temps prédéterminé iii. un traitement de marquage des informations transmises 5 par chaque capteur, consistant à associer un identifiant de la personne et une information d'horodatage aux données numériques délivrées par le capteur, de manière conditionnelle en fonction du résultat d'un traitement local préalable iv. un traitement de télétransmission audit serveur 10 distant des données marquées de manière conditionnelle d'une part, et des données historisées anonymisées de manière inconditionnelle d'autre part B. le serveur distant, commun à une pluralité d'équipements locaux, commandant les traitements suivants : 15 a. des séquences d'actions en fonction des données marquées transmises par un équipement local, et transmises à l'équipement local correspondant et/ou à au moins un périphérique d'un tiers associé à l'équipement local b. des séquences d'envoi de messages locaux à une 20 pluralité d'équipements locaux en fonction de données génériques et/ou en fonction des données émises par ces équipements locaux et/ou en fonction des actions locales effectuées sur les équipements locaux. 25 8 - Système selon la revendication précédente, dans lequel les données locales recueillies pour l'activation du processus de confirmation d'alerte locale comprennent les données recueillies par les capteurs associés à l'équipement local 30 9 - Système selon la revendication 7 ou 8, dans lequel les données locales recueillies pour l'activation du processus de confirmation d'alerte locale comprennent des données issues d'un agent conversationnel 35 3067158 - 22 - 10 - Système selon l'une des revendications 7 à 9, dans lequel les données locales recueillies pour l'activation du processus de confirmation d'alerte locale comprennent des données issues de moyens de reconnaissance d'un message vocal 5 prédéfini 11 - Système selon l'une des revendications 7 à 10, dans lequel le calculateur exécute un traitement de désactivation du processus de confirmation d'alerte sur 10 détection d'un événement déclencheur d'autorité tel que l'activation d'un médaillon de sécurité, et exécute le déclenchement d'une alerte locale et d'une alerte distante 12 - Système selon l'une des revendications 7 à 10, 15 dans lequel l'action locale de confirmation ou d'infirmation d'alerte est mise en oeuvre par un agent conversationnel pour la levée de doute.