Some content of this application is unavailable at the moment.
If this situation persist, please contact us atFeedback&Contact
12. (FR3067158) PROCEDE DE TRAITEMENT DE DONNEES NUMERIQUES HYBRIDES
Note: Text based on automatic Optical Character Recognition processes. Please use the PDF version for legal matters
PROCEDE DE TRAITEMENT DE DONNEES NUMERIQUES HYBRIDES
Domaine de 1'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 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, souvent soumis à un agrément préalable des autorités de la santé et prochainement à une certification.
Etat de la technique
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 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 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é 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 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 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 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.
Inconvénients de l'art antérieur
Les solutions de l'art antérieur impliquent des traitements lourds, avec des protocoles de transport de 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 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 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 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 coûteuse.
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 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 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 IDU 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 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 à 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 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 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 à des données de santé associées à l'IDu.
Selon un mode de mise en œuvre 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 IDU, idéalement stocké de façon persistante au sein du premier serveur de façon à pouvoir le retrouver ultérieurement, puis à commander la transmission par ledit premier serveur dudit identifiant unique IDU à 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é.
Selon une variante particulière, 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 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 IDU, 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.
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 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 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é 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 : une étape initiale de synchronisation entre un compte utilisateur enregistré sur un 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 IDU 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 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 à 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 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 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 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-dessus et comprenant : 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 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 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 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 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é 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 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é d'équipements locaux, commandant les traitements suivants : 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 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.
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 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 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 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 é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 l'action locale de confirmation ou d'infirmation d'alerte est mise en œuvre par un agent conversationnel pour la levée de doute.
Description détaillée d'un exemple non limitatif de 1'invention
La présente invention sera mieux comprise à la lecture de la description détaillée d'un exemple non limitatif de 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 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 santé.
En référence à la figure 2, qui illustre la collecte d'informations sensibles et/ou hors de portée du système 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 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.
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 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 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 (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.
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 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.
Ce procédé de traitement de données hybrides peut être mis en œuvre 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 à domicile de la personne en toute vigilance vis à vis de son é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.
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 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 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 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 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 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.
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 :
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 :
• 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
On liste ci-dessous les composants utilisés
Système d'exploitation Linux
Plate-forme Java 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 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),
• 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/).
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 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,
• 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 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 ». Cela permet d'éviter le syndrome du SPOF (Single Point of Failure).
• scalabilité. HAZELCAST détecte automatiquement les nouveaux nœuds et ceux-ci sont synchronisés
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 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. CELLAR utilise également HAZELCAST afin de synchroniser plusieurs instances. Cela permet d'assurer une haute disponibilité.
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 de problématiques d'entreprise sous forme de patron d'intégration.
CAS
Le CAS (Central Authentication Service) est un système 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 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. 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 multi-supports.
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.
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.
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 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.
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 une simple page L'ajout d'un framework graphique type bootstrap permet de réaliser des IHM ergonomique et sensible.
Serveur Web
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 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 :
• la gestion des droits d'accès aux API,
• la gestion de la bande passante.