FR3041128B1 - Suivi et prise en charge d'un patient a risque - Google Patents

Abstract

La présente invention concerne un système informatique de surveillance (100) d'un patient (P) susceptible d'être atteint d'une pathologie déterminée, comprenant notamment : - un processeur informatique (11, 21) configuré pour comparer au moins une donnée clinique (DC1, DC2) collectée à un instant t par un terminal de communication (10) avec au moins une autre donnée clinique (DC1, DC2) précédemment collectées à un instant t-1, pour évaluer un degré de risque (SC) que le patient (P) soit atteint de ladite pathologie en fonction de ladite comparaison entre lesdites données cliniques collectées (DC1, DC2), et pour générer un signal d'avertissement (AV) lorsque le degré de risque (SC) est supérieur à un seuil prédéterminé, - une serveur central (20) configuré pour émettre à destination dudit deuxième terminal de communication (30) une requête pour solliciter un rendez-vous auprès dudit praticien, ladite requête (RQ) contenant au moins une information relative au degré de risque (SC).

Description

SUIVI ET PRISE EN CHARGE D’UN PATIENT A RISQUE

Domaine technique et art antérieur

La présente invention concerne le domaine de la santé, et porte plus particulièrement sur la détection de l’apparition d’une complication aiguë d’un cancer (embolie pulmonaire, infection, etc.) ou d’une rechute (ou récidive) d’une pathologie chez une personne ou un patient, dit à risque, pour une prise en charge rapide et efficace.

La présente invention propose à cet effet un système informatique permettant à un patient à risque de détecter de façon précoce l’apparition de symptômes relatifs à une pathologie déterminée pour une prise en charge optimisée.

La présente invention trouve ainsi de nombreuses applications avantageuses notamment pour le suivi de patients en rémission d’une pathologie du type cancer comme par exemple le cancer bronchique.

La présente invention permet également de nombreuses autres applications pour le suivi de patients ayant subi d’autres pathologies chroniques (cancéreuse ou non), comme par exemple le lymphome ou le myélome.

Bien évidemment, on comprendra dans la suite de la description que d’autres applications peuvent être envisagées dans le cadre de la présente invention, comme par exemple la détection de l’apparition d’une maladie pulmonaire ou cardio-vasculaire chez une personne à risque telle qu’un fumeur.

Bien évidemment, ces exemples d’application ne présentent en aucun cas un caractère limitatif ; ces exemples sont purement illustratifs et l’homme du métier comprend ici que l’application de l’invention pour le suivi d’autres pathologies peut être envisagée ici.

Prenons ici l’exemple du cancer bronchique.

Le cancer bronchique, ou cancer du poumon, est l’un des cancers les plus meurtriers ; il touche à travers le monde plusieurs millions de personnes sans distinction entre les sexes. L’une des principales causes de ce cancer est le tabagisme.

En Lrance, malgré les très nombreuses campagnes de prévention anti-tabac, plus de 30 000 nouveaux cas sont recensés chaque année, soit plus de 10 % de l’ensemble des nouveaux cas de cancers.

Malgré les progrès de la médecine, le cancer broncho-pulmonaire présente toujours un taux de survie après 5 ans de Tordre de 15 %, ce qui reste faible.

Une fois ce type de cancer détecté, le pronostic vital du patent est généralement compromis : environ 70 à 75 % de ces cancers sont diagnostiqués à des stades avancés, voire très avancés.

Par ailleurs, les rechutes pour ce genre de cancers sont très fréquentes et sont rarement curables.

Mettre en place un système de surveillance post-thérapeutique et de prise en charge efficace pour le patient représente donc un enjeu très important pour la communauté scientifique, notamment lorsque le patient présente un risque de rechute élevé.

Au moins 75 % des rechutes sont symptomatiques.

Or, il n’existe pas à ce jour de protocole standard de suivi après traitement à visée curative ou non.

Le Demandeur soumet qu’actuellement la stratégie de surveillance la plus commune consiste à planifier un examen clinique tous les 3 à 6 mois avec le patient. Généralement, cet examen clinique est associé à une imagerie de type radiographie thoracique ou scanner.

Le suivi clinique par imagerie n’a pas démontré de réels avantages sur le plan thérapeutique.

Par ailleurs, le suivi clinique par imagerie demeure une prise en charge non personnalisée, qui est une véritable source de stress et d’anxiété pour le patient, ceci notamment à l’approche de la date du bilan d’imagerie qui a lieu plusieurs semaines après examen.

Le Demandeur observe qu’un tel stress et une telle anxiété sont bien souvent inutiles, notamment en l’absence de rechute.

Inversement, cette prise en charge peut laisser des patients symptomatiques avec une récidive non traitée pendant plusieurs semaines : beaucoup de patients symptomatiques attendent la date du bilan pour consulter le médecin.

Or, une prise en charge tardive et/ou une dégradation, parfois rapide, de l’état général du patient symptomatique peuvent réduire l’accès à des thérapies spécifiques et compromettre le pronostic à court ou moyen terme.

Les premières études approfondies semblent en effet démontrer scientifiquement qu’une détection précoce de la rechute apporte un bénéfice sur le taux de survie.

Une prise en charge rapide et efficace semble donc préférable pour le patient.

De surcroît, le suivi régulier des symptômes semble avoir un avantage médico-économique important par rapport au suivi par imagerie en évitant des examens et des voyages coûteux (et le plus souvent inutiles) pour le patient qui ne rechutent pas.

Le Demandeur soumet qu’il n’existe pas à ce jour dans l’état de la technique de solution permettant à la fois une détection précoce et personnalisée d’une rechute améliorant le pronostic par rapport au suivi classique par imagerie. Résumé et objet de la présente invention

La présente invention vise à améliorer la situation actuelle décrite ci-dessus.

La présente invention propose ainsi une solution informatique remédiant aux différents inconvénients de l’état de la technique mentionnés ci-dessous et permettant le suivi personnalisé d’un patient en temps réel ainsi que la prise en charge rapide de celui-ci par un médecin.

Un des objectifs de la présente invention est de permettre une auto-surveillance des symptômes susceptibles d’être à l’origine de l’apparition ou d’une rechute d’une pathologie chez un patient à risque.

Un des autres objectifs de la présente invention est de gérer efficacement la prise en charge de ce patient une fois qu’une complication potentiellement grave (embolie pulmonaire, infection, etc.) ou qu’une rechute a été détectée. A cet effet, l’objet de la présente invention concerne selon un premier aspect un procédé de surveillance d’un patient ou d’une personne à risque.

Par patient ou personne à risque, on entend dans toute la présente description qui suit une personne qui est susceptible d’être atteinte d’une pathologie déterminée. H peut s’agir par exemple d’une personne en rémission qui a déjà subi un traitement, et dont la pathologie peut réapparaître. On parle dans ce cas de rechute ou de récidive. H peut également s’agir d’une personne qui a un comportement à risque et qui est donc susceptible de développer une maladie, par exemple le cancer du poumon pour un fumeur.

Enfin, il peut aussi s’agir d’une personne qui a des prédispositions pour développer une maladie, ceci par exemple pour des raisons médicales ou génétiques (par exemple une personne diabétique).

Dans la suite de la description, on parlera indifféremment de patient à risque ou de personne à risque pour désigner un même individu qui utilise la solution logicielle proposée dans le cadre de la présente invention.

Selon la présente invention, le patient est donc muni d’un premier terminal de communication, par exemple un « Smartphone ».

On notera ici que ce terminal peut être, sous certaines conditions, considérées comme un dispositif médical logiciel.

On comprend qu’une application logicielle dédiée au suivi du patient et la prise en charge de celui-ci est installée sur le terminal de communication ; cette application est configurée pour mettre en œuvre certaines des fonctionnalités logicielles qui seront décrites dans ce qui va suivre.

Selon l’invention, le procédé est donc mis en œuvre par des moyens informatiques et comprend les étapes suivantes.

Plus particulièrement, le procédé selon la présente invention comprend une étape de collecte ; au cours de cette étape, est collectée à un instant déterminé, par exemple à un instant t, à l’aide du premier terminal de communication au moins une donnée clinique.

De préférence, cette donnée clinique contient au moins une information physiologique relative au patient.

Le procédé selon la présente invention comprend en outre une étape de comparaison ; au cours de cette étape, un processeur informatique compare la donnée clinique collectée à un instant déterminé, par exemple à l’instant t, avec au moins une autre donnée clinique précédemment collectées, par exemple à un instant t-1.

Suite à cette comparaison, le procédé selon la présente invention comprend une étape d’analyse au cours de laquelle le processeur met en œuvre une loi de détection, associée à la pathologie, pour évaluer en fonction de la comparaison un degré de risque que le patient soit atteint de la pathologie.

Le degré de risque ainsi évalué peut se présenter par exemple sous la forme d’un score qui donne une indication sur le niveau de risque encouru par le patient ; ce score suggère ou non une alerte de récidive ou de complication.

Ce « scoring » a fait l’objet de nombreuses phases d’étude et présente un très haut degré de fiabilité.

Ensuite, le procédé selon l’invention prévoit une étape de génération au cours de laquelle un signal d’avertissement est généré lorsque le degré de risque est supérieur à un seuil prédéterminé ; on comprend ainsi qu’un signal peut être généré lorsque par exemple le degré de risque est supérieur à 70%.

En dessous de ce seuil, on peut prévoir qu’aucun avertissement ne sera émis.

Le paramétrage de ce seuil est déterminé en fonction de la sensibilité recherchée.

Ainsi, grâce à cette combinaison d’étapes techniques, caractéristique de la présente invention, le patient dispose d’un outil portatif et simple d’utilisation lui permettant par exemple d’alerter son médecin traitant que des symptômes pouvant être à l’origine d’une rechute ou de l’apparition d’une pathologie semblent apparaître.

Cet outil ne s’apparente en aucune manière à un outil de diagnostic, mais se présente comme un outil d’accompagnement et de suivi permettant de détecter précocement un potentiel risque de rechute et le cas échéant de prendre contact avec un médecin pour accélérer le processus de prise en charge.

En effet, la détection précoce d’un potentiel risque de rechute ou de maladie ainsi que l’avertissement rapide du patient de ce risque garantissent une prise en charge plus rapide et plus efficace du patient.

Avantageusement, l’étape de collecte peut comprendre la collecte simultanée de plusieurs données cliniques, par exemple au moins une première donnée clinique, dite subjective, et/ou au moins une deuxième donnée clinique, dite objective et/ou mesurable.

De préférence, la première donnée clinique est une valeur relative à un indice représentatif d’un état physiologique perçue par l’individu, cette valeur étant comprise sur une échelle de valeurs déterminées (par exemple de 1 à 3, de 1 à 10 ou encore de 1 à 20). H s’agit par exemple d’une valeur renseignée par le patient par l’intermédiaire du premier terminal de communication. A titre d’exemple, cet indice représentatif de l’état physiologique perçu par l’individu peut être un indice parmi les suivants : l’appétit, l’essoufflement, l’asthénie, la toux, les douleurs.

Elles peuvent aussi concerner l’existence ou non de crachats hémoptoïques, de nodules sous-cutanés, d’une dysphonie et d’un syndrome cave supérieur.

Ces indices sont donc autoévalués régulièrement par le patient (par exemple chaque jour, chaque semaine ou encore toutes les deux semaines ou tous les mois), puis sont collectés par le terminal de communication.

Cette collecte peut être réalisée par exemple à l’aide d’un écran tactile. Il s’agit dans ce cas d’une simple saisie de ces indices par le patient, via par exemple une interface dédiée.

Alternativement, cette collecte des données peut être réalisée avec l’aide d’un microphone et de moyens de traitement des signaux audio du type « speech récognition ».

On peut également prévoir une caméra et des moyens de traitement d’images pour détecter dans l’image la présence d’un nodule sous-cutané ou d’une trace de sang dans un crachat.

Avantageusement, la deuxième donnée clinique est une valeur issue d’une mesure représentative d’un paramètre physiologique du patient.

On comprend ici qu’il peut s’agir d’un paramètre mesurable tel que la tension artérielle, le taux glycémique, la température corporelle, le rythme cardiaque, le rythme respiratoire, des résultats de prises de sang (PSA, taux de plaquettes, de globules blancs, etc.) ou encore le poids du patient.

Les paramètres mentionnés ci-dessus sont des exemples parmi d’autres. Ils ne présentent en aucun cas un caractère limitatif.

Dans un mode de réalisation avantageux, la deuxième donnée clinique est collectée à l’aide d’un équipement de mesure connecté au premier terminal de communication.

En d’autres termes, l’équipement de mesure et le premier terminal de communication comprennent chacun des moyens de communication pour communiquer entre eux. Il s’agit le plus souvent d’une communication unilatérale avec un transfert des données de l’équipement de mesure vers le terminal de communication.

De préférence, les moyens de communication utilisés sont du type sans fil (par exemple NFC ou « Bluetooth® »).

Il est en outre préférable pour des raisons de sécurité et de confidentialité que la collecte des données comprenne une étape préalable de synchronisation entre le terminal de communication et l’équipement de mesure, et que les données transmises d’un dispositif à l’autre soient cryptées ou chiffrées.

De préférence, cet équipement de mesure comporte un objet connecté comprenant au moins un capteur configuré par exemple pour mesurer au moins l’un des paramètres physiologiques suivants : une tension artérielle, et/ou un taux glycémique, et/ou une température corporelle, et/ou un rythme cardiaque, et/ou un rythme respiratoire dudit patient. D’autres capteurs spécifiques sont également envisageables si nécessaire.

De préférence, on peut prévoir que l’équipement de mesure est du type montre connectée.

Cet équipement de mesure peut également être une balance, dite intelligente, apte à mesurer le poids du patient. Dans cette variante, la balance est donc configurée pour transmettre au terminal une information contenant le poids mesuré.

Cet équipement de mesure peut également être un thermomètre infrarouge.

Dans un mode de réalisation avantageux, le procédé selon l’invention comprend une étape de planification au cours de laquelle, sur réception du signal d’avertissement, un serveur central émet à destination d’un deuxième terminal de communication appartenant à un praticien déterminé une requête pour solliciter un rendez-vous auprès du praticien.

De préférence, la requête contient au moins une information relative au degré de risque évalué, et éventuellement aux données cliniques collectées. Dès que le praticien reçoit l’information, il peut prendre connaissances des données cliniques collectées et contacter le cas échéant le patient pour une prise de rendez-vous rapide.

Il pourra également poser un premier diagnostic à la lecture des données cliniques reçues. Le système mis en place se présente donc pour le praticien comme un outil d’aide à la décision permettant de réaliser un premier diagnostic de façon précoce et/ou de convoquer rapidement son patient si besoin.

Par praticien, on entend dans toute la présente description qui suit une personne qui suit le patient et qui assure le traitement des alertes remontées par le système. H peut avoir déjà rencontré le patient ou non. Il peut s’agir par exemple d’un médecin (par exemple un médecin traitant ou le spécialiste qui suit le patient pour une pathologie spécifique) ou d’un autre membre du corps médical (par exemple une infirmière ou une aide-soignante) capable de prendre contact avec le patient pour infirmer ou confirmer les alertes générés par le système.

Dans un mode de réalisation avantageux, le deuxième terminal de communication a accès à un agenda électronique du praticien. On doit comprendre ici que cet agenda est enregistré dans le deuxième terminal ou que cet agenda est enregistré sur une autre entité informatique et que le deuxième terminal de communication est autorisé à consulter à distance cet agenda pour déterminer des rendez-vous disponibles. L’homme du métier comprendra ici qu’un rendez-vous doit être entendu comme une date et un créneau horaire disponible dans le calendrier de consultation du praticien.

Dans ce mode, il est prévu de préférence que, lors de l’étape de planification, le deuxième terminal de communication détermine, sur réception de la requête, une voire plusieurs dates de rendez-vous en consultant l’agenda électronique.

Le terminal de communication contient donc des moyens informatiques permettant de déterminer à partir de l’agenda électronique du praticien les disponibilités de celui-ci pour fournir au moins une date de rendez-vous.

De préférence, cette date de rendez-vous est émise à destination du premier terminal de communication pour validation.

Ceci peut être réalisé par mail, par SMS ou directement via l’application logicielle dédiée installée sur le terminal.

Le patient qui reçoit le message peut donc soit appeler directement le praticien ou le secrétariat du médecin qui le suit, soit valider via son interface logicielle le rendez-vous qui lui convient le mieux.

On peut prévoir qu’un mail de confirmation est alors adressé au patient.

Alternativement, c’est le serveur central qui est adapté pour consulter l’agenda électronique du praticien et pour déterminer une ou plusieurs dates de rendez-vous.

Cet accès à distance de l’agenda par un serveur externe nécessite de préférence la mise en place de moyens de sécurisation adaptés. On peut prévoir un jeu de clés d’authentification avec clé privée et clé publique pour accéder à cet agenda.

Prendre en charge rapidement efficacement le patient si un risque est détecté est un des objectifs de la présente invention.

Ainsi, il est prévu dans une variante que l’étape de planification comprend une sélection par le serveur central d’un autre praticien si la date de rendez-vous nécessite une attente supérieure à une période d’attente déterminée ; on comprend ici que cette période d’attente est fonction du degré de risque évalué.

En d’autres termes, si le risque de rechute est très fort, il est important que le rendez-vous soit proposé par exemple dans la semaine. Si le praticien n’est pas disponible dans la semaine (par exemple si son agenda indique qu’il est en congrès à l’étranger), l’invention prévoit la sélection d’un autre praticien.

De préférence, cette sélection d’un autre praticien est réalisée par le serveur central en fonction des agendas électroniques des autres praticiens, du degré de risque évalué et éventuellement de la donnée de localisation associée au patient tel que par exemple celle fournie par des moyens de géolocalisation intégrés dans le premier terminal de communication.

Il est donc possible de prévoir la mise en place d’un serveur central, intelligent, qui est capable de sélectionner un autre praticien si les dates de rendez-vous disponibles ne sont pas suffisamment proches dans le temps par rapport au degré d’urgence requis par le degré de risque évalué.

Cette sélection intelligente est donc multicritère : elle prend en considération les disponibilités des autres praticiens, éventuellement leur localisation, ainsi que le degré de risque évalué.

Elle peut également prendre en considération d’autres critères comme par exemple la spécialité du praticien, l’historique des consultations du patient, etc.

Corrélativement, l’objet de la présente invention concerne selon un deuxième aspect un programme d’ordinateur qui comporte des instructions adaptées pour l’exécution des étapes du procédé tel que décrit ci-dessus, ceci notamment lorsque ledit programme d’ordinateur est exécuté par au moins un processeur.

Un tel programme d’ordinateur peut utiliser n’importe quel langage de programmation, et être sous la forme d’un code source, d’un code objet, ou d’un code intermédiaire entre un code source et un code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.

De même, l’objet de la présente invention concerne selon un troisième aspect un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes du procédé tel que décrit ci-dessus. D’une part, le support d’enregistrement peut être n'importe quel entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une mémoire ROM, par exemple un CD-ROM ou une mémoire ROM de type circuit microélectronique, ou encore un moyen d'enregistrement magnétique ou un disque dur. D'autre part, ce support d’enregistrement peut également être un support transmissible tel qu'un signal électrique ou optique, un tel signal pouvant être acheminé via un câble électrique ou optique, par radio classique ou hertzienne ou par faisceau laser autodirigé ou par d'autres moyens. Le programme d’ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme d’ordinateur est incorporé, le circuit intégré étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. L’objet de la présente invention concerne selon un quatrième aspect un système informatique de surveillance d’un patient susceptible d’être atteint d’une pathologie déterminée.

Avantageusement, le système selon la présente invention comprend : - un premier terminal de communication, appartenant au patient, configuré pour collecter au moins une donnée clinique contenant une information physiologique relative au patient, - un processeur informatique configuré pour : a) comparer au moins une donnée clinique collectée à un instant déterminé avec au moins une autre donnée clinique précédemment collectées, b) mettre en œuvre une loi de détection, associée à la pathologie, pour évaluer un degré de risque que le patient soit atteint de la pathologie en fonction de la comparaison entre les données cliniques collectées, et c) générer un signal d’avertissement lorsque le degré de risque est supérieur à un seuil prédéterminé.

Avantageusement, le système selon la présente invention comporte des moyens informatiques qui sont configurés pour la mise en œuvre des différentes étapes du procédé tel que décrit ci-dessus.

Ainsi, l’objet de la présente invention, par ses différents aspects fonctionnels et structurels décrits ci-dessus, permet l’auto-surveillance des paramètres cliniques et physiologiques d’un patient pour une prise en charge rapide et efficace du praticien, par exemple lorsqu’un risque de rechute a été identifié.

Brève description des figures annexées D’autres caractéristiques et avantages de la présente invention ressortiront de la description ci-dessous, en référence aux figures 1 à 3 annexées qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif et sur lesquelles : la figure 1 représente de façon schématique un système informatique d’assistance pour la prise d’un rendez-vous conforme à un exemple de réalisation de la présente invention ; la figure 2 représente un organigramme illustrant le procédé de l’invention conforme à un exemple de réalisation de la présente invention ; la figure 3 représente un tableau de synthèse qui récapitule les différentes données collectées sur un patient pendant une période de plusieurs mois.

Description détaillée de différents exemples de réalisation avantageux

Un procédé d’assistance pour la prise d’un rendez-vous ainsi que le système informatique 100 qui lui est associé vont maintenant être décrits dans ce qui suit en faisant référence conjointement aux figures 1 à 3. L’exemple décrit ici se focalise sur la détection précoce d’une rechute d’un cancer bronchique.

Les études scientifiques et cliniques menées par l’inventeur ont abouti à l’élaboration d’un score correspondant à un degré de risque d’une rechute du cancer bronchique.

Ce score ou degré de risque sera noté ici sous la référence SC.

Le calcul de ce score SC est basé sur la dynamique et l’association de signes cliniques permettant d’alerter d’une possible rechute d’un cancer bronchique.

Dans l’exemple du cancer bronchique, les variables cliniques qui ont été déterminées comme pertinentes sont les suivantes : la variation de poids, l’appétit, l’essoufflement (ou la dyspnée), l’asthénie, la toux, les douleurs, l’existence ou non de fièvre, l’existence ou non de crachats hémoptoïques, l’existence ou non de nodules sous-cutanés, l’existence ou non d’une dysphonie, et l’existence ou non d’un syndrome cave supérieur.

On parlera dans le cadre de la présente invention de données cliniques DC1 ou DC2.

Dans l’exemple décrit ici, on parle de premières données cliniques DC1 lorsqu’il s’agit de données dites subjectives correspondant par exemple à un état physiologique perçu ou observé par le patient P : par exemple la douleur ou l’appétit ; et on parle de deuxièmes données cliniques DC2 lorsqu’il s’agit de données objectives et/ou mesurables comme par exemple le poids ou la température corporelle.

Dans le cadre de la présente invention, ces données cliniques DC1 et DC2 sont donc collectées par le terminal de communication 10 du patient P.

Dans cet exemple, on prévoit une collecte SI des premières données DC1 par une autoévaluation sur une échelle de 0 à 3 des différents paramètres physiologiques ci-dessus (voir notamment en figure 3).

Suite à cette autoévaluation, le patient renseigne par des moyens dédiés ces données DC1 dans le terminal 10.

On peut aussi prévoir que la patient P coche simplement la case « oui » ou « non » pour indiquer la présence de sang dans les crachats (hémoptysie) ou pour indiquer la présence de nodules sous-cutanés.

On prévoit de la même façon une collecte SI’ des deuxièmes données DC2 par le patient P.

Cette collecte SI’ peut se faire automatiquement, par exemple avec une montre connectée 40 comprenant une pluralité de capteurs 41, 42, 43, 44 et 45 configurés pour mesurer un paramètre physiologique déterminé du patient P, par exemple sa température corporelle ou encore sa tension.

Un thermomètre à infrarouge 47 peut également être utilisé.

On peut également prévoir une balance connectée 46 qui fournit le poids du patient P au terminal de communication 10.

On peut prévoir que ces étapes de collectes SI et SI’ sont réalisées à intervalle régulier, par exemple chaque semaine.

Le terminal de communication 10 collecte dont l’ensemble des données cliniques DC1 et DC2.

La figure 3 récapitule dans un tableau synthétique les différentes données collectées sur plusieurs mois.

Dans l’exemple décrit ici, le terminal 10 sert uniquement d’interface utilisateur.

Les données collectées DC1 et DC2 ne sont pas nécessairement stockées sur le terminal 10 ; elles peuvent être envoyées directement vers un serveur central 20.

Les canaux de transmission sur lesquels sont transférées ces données DC1 et DC2 sont de préférence sécurisés.

Dans cet exemple, le serveur 20 comprend un processeur informatique 21 qui est configuré pour traiter les données collectées DC1 et DC2.

Ainsi, dans cet exemple, le processeur informatique 21, sur réception des données, compare lors d’une étape S2 chacune des données cliniques DC1 et DC2 collectée à l’instant t avec l’historique de l’ensemble des données DC1 et DC2 précédemment collectées.

On comprend donc ici que le serveur 20 comprend des moyens de stockage 22 configurés pour enregistrer et stocker ces données DC1 et DC2.

On peut prévoir une synchronisation temporelle de ces données DC1 et DC2 pour en améliorer le traitement.

Suite à cette comparaison S2, le processeur 21 met en œuvre une loi de détection associée à la pathologie pour évaluer en fonction de la comparaison un degré de risque SC que le patient P soit atteint par cette pathologie.

Ce degré de risque SC peut se présenter par exemple sous la forme d’un pourcentage. Il peut également se présenter sous la forme d’un score suggérant ou non un niveau d’alerte ou de complication. L’implémentation de cette loi de détection pour le calcul de ce degré de risque SC ou score est caractéristique de la présente invention.

Cette loi de détection est le fruit d’années d’études et d’observations cliniques qui ont permis à l’inventeur d’établir des associations dynamiques entre différents paramètres physiologiques susceptibles de suggérer un risque de rechute.

Par exemple, on observe ici qu’une perte de poids de 3 kg ou plus à une semaine d’intervalle conjuguée à la présence de dyspnée et de douleur peut suggérer un risque potentiel de rechute.

Cette loi de détection comprend bien évidemment d’autres règles non explicitées ici et qui ne font pas partie de l’invention en tant que telle. L’homme du métier comprendra néanmoins que cette loi de détection est particulièrement complexe dans son implémentation ; de très nombreux paramètres sont à prendre en considération.

On notera en outre que cette loi de détection prend en compte dans son évaluation d’autres paramètres propres au patient ; par exemple, cette loi prendra en considération le fait que le patient suit un régime ou que le patient est dépressif.

Ces autres paramètres vont donc pondérer à chaque fois l’évaluation du score SC. L’étude prospective de cette loi de détection, avec onze paramètres étudiés, a montré des résultats très prometteurs avec : une sensibilité de 100 %, une spécificité de 89 %, une VPP (Valeur Prédictive Positive — probabilité d’avoir une alerte quand la pathologie recherchée existe) de 81 %, et une VPN (Valeur Prédictive Négative — probabilité de ne pas avoir d’alerte quand la pathologie recherchée n’existe pas) de 100 %.

Dans l’étude initiale visant à établir un algorithme de détection à partir de seulement six symptômes, une VPN de 93% était déjà notée.

Par ailleurs, les rechutes étaient détectées en moyenne 5 semaines avant la date prévues du bilan de suivi (imageries tous les 3 mois).

Une analyse en survie globale (monocentrique et non-randomisée) suggère par ailleurs un gain en survie de près de 24 % à 1 an, ce qui est très encourageant. L’inventeur soumet ici qu’une étude clinique randomisée multicentrique de grande ampleur est en cours pour valider ce bénéfice observé.

Dans le suivi clinique des patients, il est apparu que l’algorithme était plus sensible si le patient était peu symptomatique à l’inclusion et avait un score initial inférieur à 7 (en ajoutant les scores de 0 à 3 pour les symptômes concernant la toux, la dyspnée, les douleurs, l’anorexie et asthénie : pas de problème = 0, problème léger = 1, problème moyen = 2, problème important = 3 points).

Le paramétrage de cette loi mise en œuvre par le processeur 21 est donc important pour une bonne détection.

On peut prévoir une alternative dans laquelle c’est le terminal 10 du patient qui comprend le processeur. Dans ce cas, le processeur est référencé avec la référence 11. L’intégration du processeur 21 dans le serveur central 20 permet d’administrer et de mettre à jour facilement la loi de détection si nécessaire. Cette variante assure donc toute la sécurité sanitaire nécessaire à la mise en place d’un tel système de prise en charge médicale (on parle aussi de matériovigilance). Dans ce cas et sous certaines autres conditions non discutées ici, l’application logicielle installée pourra être considérée comme un dispositif médical logicielle.

Lorsque le degré de risque SC est supérieur à un seuil prédéterminé, noté TH, le processeur 21 génère un signal d’avertissement AV. A titre d’exemple, si le patient indique « oui » dans la case « présence de sang dans les crachats » (hémoptysie), le fait de renseigner cette information génère immédiatement un avertissement car ce paramètre est considéré selon la loi de détection comme suffisant pour suggérer un risque de rechute potentielle.

Suite à une réception S5 de ce signal d’avertissement AV, le processeur 21 émet donc à destination d’un deuxième terminal de communication 30 appartenant au praticien M une requête RQ pour solliciter un rendez-vous.

Dans cet exemple, la requête RQ contient une information relative au degré de risque SC ainsi qu’un récapitulatif de l’ensemble des données cliniques collectées DC1 et DC2.

Un tel récapitulatif peut se présenter par exemple sous la forme du tableau de synthèse de la figure 3.

Le praticien M peut donc avoir un premier aperçu de la situation de son patient P.

Dans l’exemple décrit, il peut décider de déclencher un processus de prise de rendez- vous.

Il confirme alors la prise en charge du patient P et donne au serveur 20 l’accès à son agenda électronique AG.

Ceci est réalisé par exemple par la fourniture d’une clé d’authentification donnant accès à l’agenda AG.

Ensuite, en consultant cet agenda électronique AG, le serveur 20 peut déterminer lors d’une étape S7 une ou plusieurs dates de rendez-vous disponibles, notées ici dl, d2, et d3.

Dans un mode de réalisation, on peut également prévoir que la détermination de ces dates dl, d2, et d3 tiennent également compte des disponibilités du patient P, ceci implique que le patient P donne accès lui aussi à son agenda électronique.

Si le degré de risque SC est élevé et nécessite une prise en charge urgente, par exemple sous sept jours, et que les dates dl, d2 et d3 disponibles du médecin nécessitent une période d’attente PT trop longue, par exemple supérieur à sept jours, le processeur 21 comprend une intelligence embarquée lui permettant de sélectionner lors d’une étape S8 un autre praticien M’.

Dans cet exemple, cette sélection S8 d’un autre praticien M’ est réalisée en fonction notamment des agendas électroniques AG’ des autres praticiens M’, du degré de risque évalué SC et éventuellement d’une donnée de localisation associée au patient P et fournie par exemple par des moyens de géolocalisation (non représentés ici) intégrés dans le premier terminal de communication 10.

Cette intelligence embarquée permet d’assurer une prise en charge efficace du patient P en cas d’urgence.

Le système 100 selon la présente invention prévoit donc la mise en œuvre d’une loi permettant une détection précoce des risques liés à la sensibilité d’un patient à une pathologie.

Cette détection est basée sur l’analyse de la dynamique, c'est-à-dire l’évolution sur la durée, de certains nombres de paramètres physiologiques relatifs au patient.

Des observations peuvent être complétées par des mesures, réalisées à l’aide d’une balance, d’un autre appareil de mesure (par exemple : un thermomètre, un glucomètre, etc.) ou encore d’une montre intelligente (par exemple une montre connectée avec des capteurs adaptés).

Dans le cadre de la présente invention, c’est le patient qui, lui-même ou avec l’assistance d’un aidant, collecte et renseigne ses propres observations.

Ici, on peut comprendre qu’un aidant est une personne qui va réaliser les mêmes tâches en délégation du patient, qui, dans certaines pathologies ou en présence de certains handicaps, ne peut utiliser l’application lui-même.

Un aidant peut assister un ou plusieurs patients, par exemple dans une maison de retraite ou un établissement du type EPHAD.

Le système 100 proposé dans le cadre de la présente invention permet ainsi : une collecte, de manière régulière et systématique, d’un ensemble de données cliniques pertinentes déterminées par le médecin, l’analyse en temps réel de ces données, et la remontée d’une alerte vers le médecin pour organiser une prise en charge rapide et efficace lorsqu’une rechute d’une pathologie déjà soignée a été détectée ou qu’une potentielle nouvelle pathologie a été détectée.

Le système 100 permet ensuite de gérer cette prise en charge de façon intelligente en proposant le rendez-vous le plus pertinent par rapport à la situation du patient P (en fonction de la pathologie, du niveau de risque identifié et de l’emploi du temps du patient), et le cas échéant permet de trouver un autre médecin M’ en cas d’urgence si le médecin habituel du patient P n’est pas disponible dans la période suivant l’alerte, ou si le patient P est en vacances dans une zone trop éloignée du médecin M pour envisager un retour anticipé.

La solution proposée dans le cadre de la présente invention se présente donc comme une solution de télésurveillance automatisée assurant notamment une prise en charge rapide en cas de risque de rechute ou d’apparition de la pathologie.

Un exemple simple de mise en œuvre de l’invention peut être le suivant :

Un patient P est suivi par son médecin M pour un cancer bronchique par radiothérapie.

Le patient P entre chaque semaine via une application dédiée installée sur son téléphone portable 10 des informations contenant des données cliniques DC1 et DC2.

Des mesures complémentaires peuvent également être réalisées à l’aide d’objets connectés type montre connectée ou balance intelligente.

Comme précédemment, on peut imaginer un exemple dans lequel le patient indique un « oui » dans la case « présence de sang dans les crachats ».

Cette information est transmise puis traitée par le serveur 20 selon la loi de détection implémentée.

Dans ce cas et selon la loi de détection associée au suivi du cancer bronchique, le serveur central 20 transmet automatiquement au médecin M, par exemple par mail, un message d’alerte AV pour suggérer une prise en charge rapide.

Le médecin M peut alors appeler directement le patient P pour la prise de rendez- vous.

Il peut également valider la nécessité d’une prise de rendez-vous en confirmant l’alerte et en autorisant le serveur 20 d’avoir un accès à son agenda électronique AG (fourniture d’une clé d’authentification).

Le serveur 20 va alors se retourner directement vers le patient P en lui envoyant une convocation avec une ou plusieurs dates de rendez-vous disponibles, par exemple dans les sept jours.

Grâce à cette prise en charge précoce, le patient P a gardé un très bon état général : un traitement puissant et efficace peut alors être proposé. Sa survie en sera allongée.

La mise en œuvre de la loi de détection sur le serveur central 20 déporté est souhaitable, notamment dans une utilisation du logiciel comme un dispositif médical logiciel. Dans cette configuration, le terminal 10 se comporte comme un simple périphérique de collecte, qui transfert les informations collectées vers le serveur central 20 et qui récupère ensuite, en cas de rechute, une convocation par le médecin avec des dates de rendez-vous possibles. Dans ce cas, le serveur 20 comporte le processeur 21 mettant en œuvre notamment la loi de détection.

La présente invention peut également être utilisée comme un simple système d’accompagnement ne faisant pas office de dispositif médical, lorsque par exemple l’application est utilisée par un fumeur qui veut éviter une prise en charge tardive d’un cancer bronchique.

Pour cette application (moins sensible), l’algorithme, le stockage des données collectées DC1 et DC2, et le calcul des scores SC peuvent être entièrement réalisés sur le terminal de communication 10 du patient, au sein d’une même application logicielle. On pourra donc mettre en œuvre la loi de détection directement sur le terminal de communication 10 du patient P. Dans ce cas, le terminal 10 intègre un processeur 11 qui implémente un algorithme de traitement pour mettre en œuvre les différentes étapes du procédé dont notamment les étapes de comparaison S2, d’analyse S3, et de génération S4 du signal d’avertissement AV.

Dans une telle application, on peut prévoir qu’il y ait ou non l’émission d’une alerte vers le médecin. L’étape de détermination des rendez-vous S7 et le cas échéant l’étape de sélection S8 d’un autre praticien M’ en cas d’urgence sont purement optionnelles. Néanmoins, elles peuvent être réalisées par exemple pour prévenir le médecin traitant que le patient P présente potentiellement un risque de pathologie.

Dans un cas comme dans l’autre, l’application logicielle installée sur le terminal 10 du patient peut prendre la forme d’une application mobile native sous iOS® ou Android®, ou sur tout autre système d’exploitation mobile ou d’une application web, accessible par tout navigateur ou par tout autre procédé de communication client/serveur ou pair à pair. H devra être observé que cette description détaillée porte sur un exemple de réalisation particulier de la présente invention, mais qu’en aucun cas cette description ne revêt un quelconque caractère limitatif à l’objet de l’invention ; bien au contraire, elle a pour objectif d’ôter toute éventuelle imprécision ou toute mauvaise interprétation des revendications qui suivent.

Il devra également être observé que les signes de références mis entre parenthèses dans les revendications qui suivent ne présentent en aucun cas un caractère limitatif ; ces signes ont pour seul but d’améliorer l’intelligibilité et la compréhension des revendications qui suivent ainsi que la portée de la protection recherchée.

Claims (18)

1. REVENDICATIONS

   1. Procédé de surveillance d’un patient (P), susceptible d’être atteint d’une pathologie déterminée, dans lequel ledit patient (P) est muni d’un premier terminal de communication (10), ledit procédé, mis en œuvre par des moyens informatiques, comprenant les étapes suivantes : - une étape de collecte (SI, SI’) au cours de laquelle, à un instant déterminé, est collectée à l’aide dudit premier terminal de communication (10) au moins une donnée clinique (DC1, DC2) contenant une information physiologique relative audit patient (P), - une étape de comparaison (S2) au cours de laquelle un processeur informatique (11, 21) compare ladite au moins une donnée clinique (DC1, DC2) collectée à un instant déterminé avec au moins une autre donnée clinique (DC) précédemment collectées, - une étape d’analyse (S3) au cours de laquelle ledit processeur (11, 21) met en œuvre une loi de détection, associée à ladite pathologie, configurée pour évaluer en fonction de ladite comparaison un degré de risque (SC) que le patient (P) soit atteint de ladite pathologie, - une étape de génération (S4) au cours de laquelle un signal d’avertissement (AV) est généré lorsque ledit degré de risque (SC) est supérieur à un seuil prédéterminé (TH).
2. 2. Procédé selon la revendication 1, dans lequel l’étape de collecte (SI, SI’) comprend la collecte (SI) d’au moins une première donnée clinique (DC1) et/ou la collecte (SI’) d’au moins une deuxième donnée clinique (DC2).
3. 3. Procédé selon la revendication 2, dans lequel ladite première donnée clinique (DC1) est une valeur relative à un indice représentatif d’un état physiologique perçue par ledit patient (P), cette dite valeur étant comprise sur une échelle de valeurs déterminées.
4. 4. Procédé selon la revendication 2 ou 3, dans laquelle ladite première donnée clinique (DC1) est renseignée par ledit patient (P) par l’intermédiaire dudit premier terminal de communication (10).
5. 5. Procédé selon l’une quelconque des revendications 2 à 4, dans lequel ladite deuxième donnée clinique (DC2) est une valeur issue d’une mesure représentative d’un paramètre physiologique dudit patient (P).
6. 6. Procédé selon la revendication 5, dans lequel ladite deuxième donnée clinique (DC2) est collectée à l’aide d’un équipement de mesure (40) connecté audit premier terminal de communication (10).
7. 7. Procédé selon la revendication 6, dans lequel ledit équipement de mesure (40) est un objet connecté comprenant au moins un capteur (41, 42, 43, 44, 45) configuré pour mesurer : - une tension artérielle, et/ou - un taux glycémique, et/ou - une température corporelle, et/ou - un rythme cardiaque, et/ou - un rythme respiratoire dudit patient.
8. 8. Procédé selon la revendication 6 ou 7, dans lequel ledit équipement de mesure (40) est du type montre connectée.
9. 9. Procédé selon l’une quelconque des revendications 6 à 8, dans lequel ledit équipement de mesure (40) comprend une balance (46) apte à mesurer le poids dudit patient (P), et/ou un thermomètre à infrarouge (47).
10. 10. Procédé selon l’une quelconque des revendications 1 à 9, comprenant une étape de planification (S6, S7, S8) au cours de laquelle, sur réception (S5) dudit signal d’avertissement (AV), un serveur central (20) émet à destination d’un deuxième terminal de communication (30) appartenant à un praticien déterminé (M) une requête (RQ) pour solliciter un rendez-vous auprès dudit praticien (M), ladite requête (RQ) contenant au moins une information relative au degré de risque (SC).
11. 11. Procédé selon la revendication 10, dans lequel le deuxième terminal de communication (30) et/ou le serveur central (20) ont accès à un agenda électronique (AG) dudit praticien (M), et dans lequel l’étape de planification (S6, S7, S8) comprend une détermination (S7) par le deuxième terminal de communication (30) et/ou le serveur central (20) d’au moins une date de rendez-vous (dl, d2, d3) en consultant ledit agenda électronique (AG).
12. 12. Procédé selon l’une quelconque des revendications 10 ou 11, dans lequel l’étape de planification (S6, S7, S8) comprend une sélection (S8) par le serveur central (20) d’un autre praticien (M’) si ladite au moins une date de rendez-vous (dl, d2, d3) nécessite une attente supérieure à une période d’attente (PT) déterminée, ladite période d’attente (PT) étant fonction du degré de risque évalué (SC).
13. 13. Procédé selon la revendication 12, dans lequel la sélection (S8) d’un autre praticien (M’) est réalisée par le serveur central (20) en fonction des agendas électroniques (AG’) des autres praticiens (M’), du degré de risque évalué (SC) et éventuellement d’une donnée de localisation associée audit patient (P) tel que par exemple celle fournie par des moyens de géolocalisation intégrés dans le premier terminal de communication (10).
14. 14. Procédé selon Tune quelconque des revendications 1 à 13, dans lequel l’étape de collecte (SI, SI’) est réalisée à intervalle régulier, par exemple tous les jours ou toutes les semaines.
15. 15. Programme d’ordinateur comportant des instructions adaptées pour l’exécution des étapes du procédé selon Tune quelconque des revendications 1 à 14 lorsque ledit programme d’ordinateur est exécuté par au moins un processeur.
16. 16. Support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes du procédé selon Tune quelconque des revendications 1 à 14.
17. 17. Système informatique de surveillance (100) d’un patient (P) susceptible d’être atteint d’une pathologie déterminée, ledit système (100) comprenant : un premier terminal de communication (10), appartenant audit patient (P), configuré pour collecter au moins une donnée clinique (DC1, DC2) contenant une information physiologique relative audit patient (P), un processeur informatique (11,21) configuré pour : a) comparer au moins une donnée clinique (DC1, DC2) collectée à un instant déterminé avec au moins une autre donnée clinique (DC1, DC2) précédemment collectées, b) mettre en œuvre une loi de détection, associée à ladite pathologie, pour évaluer un degré de risque (SC) que le patient (P) soit atteint de ladite pathologie en fonction de ladite comparaison entre lesdites données cliniques collectées (DC1, DC2), et c) générer un signal d’avertissement (AV) lorsque le degré de risque (SC) est supérieur à un seuil prédéterminé (TH).
18. 18. Système (100) selon la revendication 17, comportant des moyens informatiques configurés pour la mise en œuvre des étapes du procédé selon Tune quelconque des revendications 2 à 14.