FR 3145434 A1 20240802 FR 2300879 A 20230131 La présente invention propose un système et un procédé de gestion de prise en charge de patients par un réseau de praticiens multidisciplinaires, dans un contexte où un premier praticien demandeur, a besoin de faire prendre en charge un patient dans un court délai, par un autre praticien effecteur. Le système comprend différents modules clients fonctionnels opérant sur un dispositif informatique de chaque professionnel de santé lui permettant de gérer des prises en charge de patients, en tant que demandeur ou effecteur. Le système comprend un module serveur qui a des moyens configurés pour gérer des accès de professionnels de santé au réseau médical et pour gérer des configurations de mise en œuvre des modes opérationnels des modules clients entre professionnels de santé demandeurs et effecteurs. Figure pour l’abrégé : Fig.1 Dispositif et procédé de gestion centralisée de demandes de prise en charge de patients La présente invention concerne le domaine de l’informatique médicale, et concerne plus spécifiquement un système et un procédé mis en œuvre dans un réseau informatique partagé entre professionnels de santé, pour la prise en charge de patients. Etat de la technique Le secteur de la santé se sert de plus en plus de l'informatique, et de diverses technologies de l’information, que ce soit pour traiter des données, établir des diagnostics, gérer des dossiers patients informatisés, simplifier des processus, les rendre plus flexibles, … L'informatique médicale est ainsi devenue incontournable dans des parcours de soins, quelle que soit la ou les pathologies de patients à appréhender par les professionnels de santé. Elle permet une communication rapide entre intervenants. Il existe alors une réelle collaboration entre informatique et soins, un patient et son praticien utilisant de plus en plus d’applications mobiles. Cependant, il est remonté par les professionnels de santé, que l’adressage de patients vers des confrères spécialisés, souvent devant être organisé pendant le temps d’une consultation, reste une opération fastidieuse et pour laquelle l’informatique médicale n’a pas encore proposé de solution. Ainsi, il existe un besoin de mettre à disposition des praticiens un outil spécifique pour l’adressage et la prise en charge de patients, dans un délai court. Une telle solution doit offrir une interface d’utilisation simplifiée pour le praticien quelle que soit sa spécialisation. La présente invention répond à ce besoin. Un but de l’invention est de modéliser et numériser les réseaux informels fonctionnels médicaux déjà existants. Un autre but de l’invention est de rendre les connexions au réseau, plus faciles et plus qualitatives, sans détruire des fonctionnements vertueux déjà existants, et sans déshumaniser les interactions entre soignants et patients. Une implémentation préférentielle de la présente invention est réalisée sous la forme d’un logiciel opérant en tant que service ou « Software as a Service » (SaaS) selon l’anglicisme consacré, où les logiciels opérés sont installés sur des serveurs distants, plutôt que sur une machine de l'utilisateur. Dans une variante d’implémentation, l’invention est proposée comme une application mobile comprenant des modules clients installés sur un dispositif informatique de chaque praticien, et un module serveur installé sur un serveur distant ou sur un dispositif informatique d’un superviseur. Pour obtenir les résultats recherchés, il est proposé un système de gestion de prise en charge d’un patient par un réseau médical, le réseau médical comprenant une pluralité de professionnels de santé multidisciplinaires, les professionnels étant équipés de moyens de communication configurés pour communiquer via un réseau de communication. Le système comprend un module fonctionnel client opérant sur un dispositif informatique de chaque professionnel de santé, permettant de gérer des prises en charge de patients, ledit module client ayant un premier mode opérationnel activable en tant que professionnel de santé demandeur et un deuxième mode opérationnel activable en tant que professionnel de santé effecteur. Le module client est configuré dans le premier mode opérationnel, pour communiquer des requêtes individualisées entre un demandeur et un effecteur sélectionné par le demandeur parmi la pluralité de professionnels de santé du réseau médical, et pour communiquer en tant que demandeur des requêtes généralisées vers un ensemble d’effecteurs. Le module client est configuré dans le deuxième mode opérationnel, pour recevoir et traiter des requêtes individualisées ou généralisées. Le système comprend aussi un module fonctionnel serveur comprenant des moyens configurés pour gérer des accès de professionnels de santé au réseau médical et pour gérer des configurations de mise en œuvre des modes opérationnels des modules fonctionnels clients et entre professionnels de santé demandeurs et effecteurs. L’invention propose plusieurs modes de réalisation alternbatifs ou combinés. Selon un aspect particulier de l’invention, le module fonctionnel client comprend : - des moyens fonctionnels dits de premier niveau configurés pour gérer une demande de prise en charge d’un patient, dite « demande de première intention », entre un demandeur et un professionnel de santé sélectionné par le demandeur parmi une liste de professionnels de santé effecteurs de première intention définie pour ladite prise en charge du patient; - des moyens fonctionnels dits de second niveau configurés pour gérer une demande de prise en charge d’un patient, dite « demande généralisée », entre un demandeur et tout ou partie des professionnels de santé du réseau médical, les moyens de second niveau étant activés si une prise en charge de première intention est refusée ou échue; - des moyens fonctionnels configurés pour communiquer à un patient une proposition de prise en charge de première intention ou généralisée, et pour traiter une réponse reçue d’un patient ; et - des moyens fonctionnels de suivi configurés pour afficher sur le dispositif informatique de chaque professionnel de santé, un suivi quantitatif et temporel des prises en charge de demandes de première intention et de demandes généralisées. Dans un mode de réalisation de l’invention, les moyens de premier niveau sont configurés pour : - créer une requête individualisée de prise en charge d’un patient pour une pathologie donnée, la requête comprenant au moins le nom du professionnel de santé demandeur, une fiche patient contenant des informations administratives et cliniques quant au patient, et des critères quant à la prise en charge du patient ; - sélectionner un professionnel de santé effecteur de première intention, parmi ladite liste de professionnels de santé effecteurs de première intention définie ; et - transmettre une requête individualisée de prise en charge du patient vers le module client de l’effecteur de première intention ; et les moyens de second niveau sont configurés pour générer une liste généralisée de professionnels de santé effecteurs pouvant traiter une requête individualisée refusée par un effecteur de première intention, et pour adresser ladite requête en tant que requête généralisée aux professionnels de santé effecteurs de ladite liste généralisée. Les moyens de premier niveau sont de plus configurés pour recevoir une requête individualisée de prise en charge d’un patient, et traiter ladite requête individualisée pour accepter ou refuser la prise en charge. Le module fonctionnel client opérant dans le deuxième mode, est de plus configuré pour recevoir une requête généralisée de prise en charge d’un patient, et traiter ladite requête généralisée pour accepter ou refuser la prise en charge. Dans un mode de réalisation, les moyens fonctionnels du module serveur comprennent un module fonctionnel pour gérer des profils de professionnels de santé selon leur spécialité, un module fonctionnel pour gérer des configurations de mise en œuvre des modes opérationnels des modules clients entre professionnels de santé demandeurs et effecteurs, un module de suivi configuré pour gérer un suivi quantitatif et temporel des prises en charge de demandes de première intention et de demandes généralisées pour l’ensemble des professionnels de santé du réseau médical. Avantageusement, le dispositif informatique de chaque professionnel de santé comprend une interface homme-machine configurée pour afficher un suivi dynamique des demandes individualisées et généralisées. Dans un mode de réalisation, l’interface homme-machine comprend un premier onglet pour afficher l’état des envois de requêtes individualisées et généralisées, et un deuxième onglet pour afficher l’état des réceptions de requêtes individualisées et généralisées. Dans une implémentation, les modules fonctionnels clients sont installés sur un module serveur, ledit module serveur opérant les fonctionnalités des modules clients comme un logiciel en tant que service via le réseau de communication L’invention a aussi pour objet un procédé pour gérer une prise en charge d’un patient par un réseau médical, le réseau médical comprenant une pluralité de professionnels de santé multidisciplinaires, les professionnels étant équipés de moyens de communication configurés pour communiquer via un réseau de communication, le procédé étant mis en œuvre par les moyens du système de l’invention. L’invention adresse aussi un programme d'ordinateur comprenant des instructions de code qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre le procédé de l’invention. D’autres caractéristiques et avantages de la présente invention apparaîtront mieux à la lecture de la description qui suit en relation aux dessins suivants : La illustre un environnement informatique fonctionnel permettant de mettre en œuvre le procédé de l’invention ; La est un schéma fonctionnel d’un dispositif informatique implémentant un composant applicatif client selon un mode de réalisation ; La est un schéma fonctionnel d’un dispositif informatique implémentant un composant applicatif serveur selon un mode de réalisation ; La illustre des étapes du procédé d’émission d’une requête individualisée de prise en charge d’un patient selon un mode de réalisation ; La illustre des étapes du procédé de traitement d’une réponse à une requête de prise en charge d’un patient, individualisée ou généralisée, selon un mode de réalisation ; La illustre des étapes du procédé de traitement d’une requête individualisée de prise en charge d’un patient, selon un mode de réalisation du procédé de l’invention ; La illustre des étapes du procédé de traitement d’une requête généralisée de prise en charge d’un patient, selon un mode de réalisation du procédé de l’invention ; Les figures 6a à 6c montrent différents exemples non exhaustifs de configurations d’interface hommes-machines selon différents états du traitement d’une demande ; Les figures 7a à 7h montrent différents exemples non exhaustifs de statuts de suivi de demandes individualisées sur une interface praticien selon l’invention. Description détaillée de l’invention La illustre un environnement de mise en œuvre du système de l’invention, pour une réalisation de type implémentation sur machine de l’utilisateur. L’homme du métier pourra appliquer les principes décrits à une implémentation de type SaaS (non illustrée). D'une manière générale, une application SaaS est une application qui s'exécute sur un dispositif informatique client et communique directement avec un hôte cible (par exemple, un serveur SaaS) via le réseau Internet. Selon l’exemple illustré, le système (100) de l’invention opère en tant que système de gestion de prise en charge de patients (10) (un seul patient étant illustré par simplification) au sein d’un réseau médical (102). Un patient (10) au sens du contexte de l’invention, est un utilisateur disposant d’au moins un moyen de communication avec un professionnel de santé initial, lui permettant de recevoir des messages et d’en envoyer soit sous la forme d’un SMS, soit par messagerie électronique. Le réseau médical (102) désigné aussi comme réseau « medamed » ou encore « med@med » est constitué d’une pluralité de professionnels de santé participants multidisciplinaires. Un professionnel de santé peut entrer dans le réseau par demande de sa part ou sur sollicitation d’un confrère, qui peut lancer une invitation à rejoindre le réseau medamed, par mail, par sms ou par la plateforme. Une fois invité, et que l’invitation est acceptée, le professionnel de santé devient participant en tant qu’effecteur pour tous les demandeurs déjà participants, et il devient lui-même demandeur. Bien que la description soit faite pour une application à des professionnels de santé exerçant comme médecins généralistes et spécialistes, les principes décrits pourraient être généralisés à d’autres professions de santé et hors santé, opérant selon un schéma impliquant une triade « un professionnel initial / un patient / un réseau de professionnels spécialistes ». Les professionnels sont équipés de moyens de communication configurés pour communiquer via un réseau de communication (106). Les moyens de communication de chaque professionnel de santé peuvent être identiques ou différents mais adaptés pour communiquer vers d’autres professionnels de santé du réseau médical, et vers des patients, notamment via le réseau Internet (106). Ces moyens peuvent être des terminaux mobiles, des téléphones cellulaires pouvant communiquer par l'intermédiaire d’un réseau de communication mobile par exemple afin d’envoyer et recevoir des messages SMS (« Short Message Service » selon l’anglicisme consacré) selon des normes de réseau de téléphonie mobile adaptées. Ces moyens de communication peuvent aussi permettre d’envoyer des messages via des messageries électroniques. Les professionnels de santé disposent par ailleurs de moyens de connexion individuels leur permettant de s’authentifier en tant que professionnel (par exemple vérifier qu’un médecin est bien inscrit au Conseil de l’Ordre et du Ministère de la Santé, ou authentifier l’identité d’un infirmier ou d’une infirmière, d’un ou une psychologue). L’authentification peut être faite via une carte de professionnel de santé (carte CPS) équipée d’une puce. Le système de l’invention comprend un module fonctionnel client (108) opérant (en mode SaaS ou installé en local) sur un dispositif informatique (104) de chaque professionnel de santé, et qui est configuré pour gérer des prises en charge de patients. L’exemple de la est simplifié pour permettre une bonne compréhension des principes de l’invention, mais n’est en rien limitatif quant au nombre de dispositifs informatiques, et donc de professionnels de santé, et quant aux variantes de réalisation basées sur de tels dispositifs aux fonctionnalités équivalentes. Dans un mode de réalisation, le dispositif informatique (104) permettant de mettre en œuvre le module applicatif client de l’invention, est couplé aux moyens de communication du professionnel de santé, i.e. le module client (108) opère par exemple sur le téléphone portable ou sur une tablette du professionnel de santé ou une connexion de type USB par exemple permet de les coupler. Avantageusement, le module client (108) opère selon deux modes fonctionnels. Un premier mode fonctionnel/opérationnel permet à un professionnel de santé d’être demandeur, i.e. solliciteur pour une prise en charge d’un patient. Un deuxième mode fonctionnel/opérationnel permet à un professionnel de santé d’être récepteur d’une demande de prise en charge d’un patient, et éventuellement réalisateur d’une prise en charge d’un patient, et l’on parle alors d’effecteur. Plus spécifiquement, le module client (108) est configuré selon le premier mode opérationnel, pour communiquer des requêtes dites individualisées de prise en charge, entre un demandeur et un professionnel de santé qui est sélectionné par le demandeur parmi la pluralité de professionnels de santé du réseau médical. Le premier mode opérationnel permet aussi, en tant que demandeur, de communiquer des requêtes dites généralisées vers un ensemble de professionnels de santé. Selon le deuxième mode opérationnel, le module client (108) permet de recevoir et traiter des requêtes de prise en charge individualisées ou généralisées. Le système de l’invention (100) comprend de plus un module serveur (110) qui comprend des moyens configurés pour administrer et superviser l’ensemble des opérations. Dans une implémentation, le serveur est un dispositif de type (HDS) désignant un « Hébergeur de Données de Santé », qui permet par une certification HDS (alignée sur la norme internationale ISO 27001), que toutes les données qui circulent sur le réseau commun aux professionnels de santé soient échangées de manière sécurisée. Une certification HDS permet à un hébergeur de garantir une qualité de service (stockage, traitements, …) autant au niveau de la sécurité que de la maîtrise des incidents, en ce qui concerne les données de santé, qui sont inscrites dans la catégorie des données sensibles. Le module serveur est configuré pour gérer des accès de professionnels de santé au réseau médical et pour gérer des configurations de mise en œuvre des différents modes opérationnels des modules clients entre professionnels de santé demandeurs et effecteurs. Selon des modes de réalisation, le module applicatif serveur (110) selon l’invention, peut être installé sur un dispositif informatique distant (112) dit superviseur, qui peut comprendre des interfaces homme-machine appropriées pour effectuer les opérations d’administration et de supervision du réseau médical (gestion d’accès ; de profils utilisateurs, de configurations de modules clients, gestion des demandes de soins, gestion des rendez-vous, …), pour un professionnel de santé ou plusieurs regroupés au sein d’un groupement. Dans une implémentation SaaS, les modules fonctionnels clients sont installés sur le module serveur qui opère les fonctionnalités des modules clients via le réseau de communication (106). Passant à la , chaque dispositif informatique (104) est équipé au moins d’un processeur couplé à une mémoire (210) qui stocke des instructions de code non transitoires qui, lorsqu'elles sont exécutées, amènent le processeur à effectuer (localement ou en tant que service SaaS) les fonctions applicatives du module client (108). Le dispositif informatique (104) offre aussi une interface utilisateur E/S (Entrées/Sorties) (212) spécifique à l’application de gestion de prise en charge de patient selon l’invention, et dont des exemples, non exhaustifs, de configurations sont montrés sur les figures 6a à 6c pour différents états du traitement d’une demande de prise en charge de patient. Dans un mode de réalisation, l’interface homme-machine (212) est configurée pour afficher sous un premier onglet l’état des envois de requêtes individualisées et généralisées, et pour afficher sous un deuxième onglet l’état des réceptions de requêtes individualisées et généralisées. Dans le détail, le module client (108) comprend plusieurs modules fonctionnels. Un module fonctionnel (202) de gestion de première intention (ou moyens de premier niveau), permet de gérer une demande individualisée de prise en charge d’un patient, dite « demande de première intention ». La demande de première intention va être créée par un professionnel de santé, demandeur initial souhaitant adresser un patient à un confrère spécialiste sélectionné parmi une liste de professionnels de santé de première intention qui sont définis pour cette prise en charge. La illustre une interface homme-machine permettant à professionnel de santé de faire un choix de confrère effecteur de première intention. Un module fonctionnel (204) de gestion de seconde intention (ou moyens de second niveau), permet de gérer une demande généralisée de prise en charge d’un patient, dite « demande en seconde intention », entre un demandeur et tout ou partie des professionnels de santé du réseau médical. Les moyens de second niveau sont configurés pour être activés quand une prise en charge de première intention est refusée ou échue au terme d’un temps prédéfini (et paramétrable), par le professionnel de santé qui a été sélectionné en première intention par le demandeur initial. Un module fonctionnel (206) pour communiquer à un patient une proposition de prise en charge de première intention ou de seconde intention, et pour traiter une réponse reçue d’un patient. Un module fonctionnel (208) de suivi pour gérer et afficher sur l’interface du dispositif informatique de chaque professionnel de santé, un suivi quantitatif et temporel des demandes de première intention et de seconde intention. Passant à la , il est décrit un schéma fonctionnel d’un dispositif informatique (112) implémentant un composant applicatif serveur (110) selon un mode de réalisation. Le dispositif informatique (112) est équipé au moins d’un processeur couplé à une mémoire (308) qui stocke des instructions de code non transitoires qui, lorsqu'elles sont exécutées, amènent le processeur à effectuer les fonctions applicatives du module serveur (110). Le dispositif informatique superviseur (112), offre une interface utilisateur E/S (310) qui permet à un superviseur d’effectuer diverses opérations de supervision du réseau médical. Le superviseur peut être un administrateur qui gère, via une interface appropriée, les profils utilisateurs, les créations et annulations de participants, ou encore tout problème relatif au profil et aux accès des professionnels de santé. Dans le détail, le module serveur (110) comprend plusieurs modules fonctionnels, dont un module (302) de gestion des accès au réseau médical, un module (304) pour gérer les configurations et mises en œuvre des différents modes opérationnels des participants au réseau médical, un module (306) de suivi de l’ensemble des demandes et réponses de prise en charge. Le module (302) de gestion des accès au réseau médical permet de gérer les autorisations de rejoindre le réseau médical (sur demande spontanée ou sur invitation), de gérer des profils de professionnels de santé, des listes de professionnels selon des regroupements par spécialisation ou selon d’autres critères. Le module (304) de gestion des configurations et des mises en œuvre des différents modes opérationnels des participants au réseau médical, permet de faire les mises à jour nécessaires quand des informations sont remontées par des professionnels de santé, par exemple sur les différentes listes de professionnels d’un même groupe. Le module (306) de suivi de l’ensemble des demandes et réponses de prise en charge permet une supervision de l’état des prises en charge selon des critères choisis, par exemple par spécialisation, ou selon un critère de temps. Passant à la , il est décrit des étapes d’un procédé d’émission d’une requête individualisée de prise en charge d’un patient selon un mode de réalisation. Dans une phase préliminaire non illustrée, chaque professionnel de santé pour devenir membre du réseau médical, crée via le module client, un compte utilisateur avec un profil praticien, l’identifiant comme professionnel de santé. Des informations d’identification peuvent être indiquées par le praticien (mot de passe ; téléphone ; email ; site web ; …) et d’autres informations d’identification peuvent être récupérées directement via une carte de professionnel de santé CPS, comme par exemple le numéro d’identification professionnel RPPS ou ADELI. Dans un mode de réalisation, l’application permet de créer un profil fédérateur « Bedmanager » qui regroupe plusieurs profils de professionnels de santé sous sa responsabilité. Ce profil permet de rattacher plusieurs praticiens travaillant dans une même structure (par exemple une clinique ou un centre de santé, …), pour gérer des demandes de services (par exemple des consultations, des hospitalisations de jour, à domicile, …). Le médecin fédérateur peut ensuite suivre via l’interface, l’ensemble de toutes les demandes de prise en charge arrivant pour cette même structure. Dans un mode de réalisation, l’application permet sur le dispositif informatique hébergeant le module serveur, de créer un profil Superviseur regroupant des informations essentiellement administrateur réseau. Les informations du profil utilisateur fournies lors de la création d’un compte restent stockées en mémoire locale sur le dispositif informatique du praticien pour les prochains accès. Dans la variante de réalisation en version SaaS, ces informations restent hébergées dans le « Cloud ». Les informations des profils utilisateur sont de plus stockées dans la base de données (102) de praticiens participant au réseau médical. De manière standard, un utilisateur peut éditer et modifier ses propres informations, qui seront aussi mises à jour dans la base de données. Revenant à la , une fois connecté à l’application de gestion de prise en charge de patient, un praticien demandeur qui souhaite établir une demande de prise en charge, initie un processus (400) de création de requête individualisée de prise en charge d’un patient pour une pathologie donnée. L’interface utilisateur permet dans un premier temps de renseigner manuellement et automatiquement (par exemple en récupérant des données patient via sa carte vitale) une fiche patient contenant des informations administratives quant au patient, et des contraintes quant à la prise en charge du patient (par exemple, la spécialité requise pour la prise en charge, son degré de mobilité). La montre un exemple d’une fiche patient. Après avoir renseigné et enregistré la fiche patient (la pathologie, les symptômes, les échelles de pathologie si besoin, la qualification de la demande selon une logique médicale, avec l’aide d’un système d’aide à la décision médicale SADM), le praticien demandeur obtient une liste de professionnels de santé susceptibles de pouvoir prendre en charge le patient, dits professionnels de santé effecteur de première intention. Cette liste comprend des professionnels de santé appartenant au réseau médical, et répondant aux critères déclarés par le praticien initial. Dans un mode de réalisation, l’interface utilisateur permet que les praticiens non disponibles (non connectés à l’application au moment de la création de la requête) ou ne répondant pas à tous les critères (par exemple pas d’accueil brancard), ne soient pas sélectionnables par le praticien demandeur. La montre un exemple de fiche patient avec une liste de médecins de première intention. Le praticien demandeur peut ainsi sélectionner (404) un professionnel de santé effecteur de première intention, parmi la liste des professionnels de santé effecteurs de première intention disponibles. Une fois un praticien effecteur de première intention sélectionné, le processus permet de mettre à jour la liste initiale et conserver une liste de professionnels de santé susceptibles de pouvoir prendre en charge le patient, en seconde intention. Dans un mode de réalisation, une fiche patient comprend au moins des informations relatives à : l’identité du patient ; les contraintes de la prise en charge ; la création de la demande en renseignant les symptômes de la maladie ou le diagnostic de la maladie ; le contexte de survenue du problème de santé. Dans un mode de réalisation, le système peut « brider » certaines demandes, pour ne pas permettre de faire des demandes pour des motifs trop graves qui doivent être prise en charge par d’autres professionnels, en général en urgence à l’hôpital. Le contenu d’une telle fiche est vu comme un système d’aide à la décision médicale ou (SADM) qui est un guide et une aide pour un médecin demandeur pour formaliser sa demande de soins selon des critères de bonnes pratiques cliniques médicales. Le processus permet ensuite au praticien de compléter la fiche patient par des informations plus spécifiques quant à des risques sur le patient (par exemple il peut indiquer une suspicion de thrombose veineuse) et des informations cliniques (par exemple, insuffisance rénale, contre-indication hémorragique, …). Une fois la fiche client complétée, le demandeur peut envoyer sa demande. Le processus permet de transmettre (406) une requête individualisée de prise en charge du patient vers le module client de l’effecteur de première intention qu’il a sélectionné. La illustre des étapes du procédé de traitement d’une requête individualisée de prise en charge d’un patient, selon un mode de réalisation du procédé de l’invention. A réception (502) d’une demande individualisée de prise en charge, le processus permet au praticien effecteur de première intention de traiter (504) la demande, soit en la refusant (ko), soit en l’acceptant (ok). La demande peut aussi être refusée au bout d’un temps échu, par exemple après 2h d’attente sans réponse. Dans un mode de réalisation, le processus permet de tenir compte d’un historique de réponses des praticiens effecteurs, pour affiner la liste des praticiens de première intention. Ainsi, si un effecteur en première intention qui vise à être sélectionné par un demandeur, n’accepte jamais les demandes ou si ses créneaux habituels de rendez-vous sont déjà passés dans la semaine, ou il n’accepte jamais tel motif ou telle pathologie, le système permet d’en informer le demandeur. Dans un mode de réalisation, un sms peut être envoyé simultanément au praticien sélectionné pour l’informer de l’arrivée d’une demande de prise en charge dans l’application de gestion, les informations de contact étant automatiquement récupérées de la fiche profil du praticien sélectionné. Si le praticien effecteur de première intention refuse la demande, le procédé permet d’en informer le praticien demandeur (ko vers 408). Si le praticien effecteur de première intention accepte la demande, le procédé permet d’en informer le praticien demandeur (ok vers 408), de faire (506) une proposition de rendez-vous au patient, et mettre à jour (508) le suivi de ses demandes, en particulier sous l’onglet des demandes individuelles reçues. La illustre une interface d’un praticien effecteur de première intention où l’onglet des demandes individualisées reçues est actualisé à l’arrivée d’une demande, avec la fiche informative sur le patient, le médecin adressant, le type de demande, les renseignements cliniques. Dans un mode de réalisation, le patient reçoit un sms sur son téléphone cellulaire récapitulant la proposition de rendez-vous, et lui donnant un temps limité pour confirmer. S’il confirme le rendez-vous, le patient est redirigé vers un lien pour accepter les conditions générales de la prise en charge. De plus, le praticien effecteur de première intention est informé de la confirmation, et l’onglet de suivi des demandes individualisées est mis à jour (508). Les figures 7e et 7g illustrent des exemples d’interface homme-machine montrant une demande acceptée par un effecteur et acceptée par un patient, une demande arrivée, une demande refusée et une demande généralisée. Si le patient ne répond pas dans le temps limite ou refuse la proposition, le processus permet que le praticien effecteur de première intention soit informé du refus (le praticien effecteur reçoit un sms l’en informant) et l’onglet de suivi des demandes est mis à jour (508). De plus, un sms est renvoyé au patient pour l’informer de dispositions possibles pour lui (par exemple, se rendre aux urgences compte-tenu de sa pathologie). La illustre un exemple de mise à jour des barres de suivi, côté demandeur. La illustre des étapes du procédé de traitement d’une réponse à une requête de prise en charge d’un patient, individualisée ou généralisée, selon un mode de réalisation. Le procédé permet à réception (408) d’une réponse d’un effecteur, déterminer si la réponse est pour une demande individualisée ou généralisée. Si la réponse reçue provient d’un effecteur de première intention (410), et si la réponse est un refus de prise en charge, le procédé permet d’activer le réseau de praticiens de deuxième intention, et transmettre (412) la demande en tant que requête généralisée aux professionnels de santé effecteurs présents sur la liste généralisée. L’interface de suivi des demandes de prise en charge est mise à jour (412). Si la réponse reçue provient d’un effecteur de deuxième intention (416), et si la réponse est un refus de prise en charge, le procédé permet d’informer (420) le patient qu’une prise en charge n’est actuellement pas possible. De plus, si tous les effecteurs de deuxième intention refusent ou ne répondent pas au terme d’un temps défini (par exemple 4h), le système informe le patient de se rendre aux urgences ou de recontacter son médecin traitant et le demandeur. L’interface de suivi des demandes généralisées de prise en charge est mise à jour (418). La illustre des étapes du procédé de traitement d’une requête généralisée de prise en charge d’un patient, selon un mode de réalisation du procédé de l’invention. A réception (510) d’une requête généralisée, le procédé permet au praticien concerné de traiter (512) la demande soit en la refusant (ko), soit en l’acceptant (ok). Dans un mode de réalisation, chaque praticien de la liste généralisée reçoit un sms sur son téléphone cellulaire pour l’informer de la mise à disposition dans son espace praticien, d’une demande qui a été rendue généralisée. Si le praticien effecteur de deuxième intention refuse la demande, le procédé permet d’en informer le praticien demandeur (ko vers 408). Si le praticien effecteur de deuxième intention accepte la demande, le procédé permet d’en informer le praticien demandeur (ok vers 408), de faire (514) une proposition de rendez-vous au patient, et mettre à jour (516) le suivi de ses demandes, en particulier sous l’onglet des demandes généralisées reçues. Avantageusement, une fois la prise en charge validée par un praticien de deuxième intention, la fiche patient n’est alors consultable que par le praticien ayant validé. Dans un mode de réalisation, le patient reçoit un sms sur son téléphone cellulaire récapitulant la proposition de rendez-vous, et lui donnant un temps limité pour confirmer. S’il confirme le rendez-vous, le patient est redirigé vers un lien pour accepter les conditions générales de la prise en charge. De plus, le praticien effecteur de première intention est informé de la confirmation (vers 408), et l’onglet de suivi de ses demandes généralisées est mis à jour (418) sur son espace. Si le patient ne répond pas dans le temps limite ou refuse la proposition, le processus permet que le praticien effecteur de deuxième intention soit informé du refus (le praticien effecteur reçoit un sms l’en informant) et l’onglet de suivi des demandes généralisées est mis à jour (508). De plus, un sms est renvoyé au patient pour l’informer de dispositions possibles pour lui (par exemple, se rendre aux urgences compte-tenu de sa pathologie). Les figures 7a à 7h montrent différents exemples non exhaustifs de statuts de suivi de demandes individualisées sur une interface praticien selon l’invention. Le suivi des demandes se fait pour des demandes envoyées et pour des demandes reçues. De plus, le suivi des demandes envoyées ou reçues se fait pour des demandes individualisées et pour des demandes généralisées. Dans un mode de réalisation de l’interface praticien, le suivi des demandes s’affiche comme des barres d'outil informatique visuelles, fonctionnelles et dynamiques. Leur présentation permet une gestion simple et un traitement facilité des demandes de prise en charge de patients. Avantageusement, une telle présentation contribue à la motivation et l'engagement des praticiens au traitement des demandes de soins. Comme illustré sur les exemples des figures 7a à 7h, deux barres d'outils visuelles sont incluses dans deux onglets, l’un pour les demandes envoyées, l’autre pour les demandes reçues. Sur chaque onglet, il est disposé une première barre d'outils qui concerne les demandes reçues individuellement. En dessous il est disposé une deuxième barre d'outils qui concerne les demandes généralisées. Ces deux barres d'outils peuvent se segmenter en fonction du nombre de demandes et d'actions faites ou à faire. La segmentation combine le nombre de demandes, qui est indiqué par un chiffre dans la barre d'outils, et un code couleur qui varie en fonction des actions à faire. Dans une implémentation, la segmentation par couleur combine trois codes couleurs différents vert, orange et rouge. Le code couleur vert signifie que la demande a été traitée et acceptée par le professionnel de santé effecteur, mais pas forcément acceptée par le patient. Le code couleur rouge signifie que la demande a été traitée et refusée ou qu’elle n'a pas été traitée car échue au terme d'un temps défini (par exemple 1 heure pour les demandes individuelles, et 4 heures pour les demandes généralisées), ou qu’il y a une impossibilité d'être traitée par le praticien. Le code couleur orange signifie qu'une ou plusieurs demandes attendent d'être traitées. Comme visible sur les figures 7a à 7h, une pastille contenant un chiffre indique le nombre de demandes pour lesquelles une action est nécessaire. Dans un mode de réalisation, lorsque le praticien passe la souris une barre d'outil ( ), une petite fenêtre s'ouvre en dessous et précise la ou les demandes : l’identité du demandeur et l’heure respective de chaque demande ( ). Il peut aussi être précisé la nature de la réponse du patient à un rendez-vous proposé, i.e. une croix rouge pour un refus, un symbole V vert pour un accord, tout en rappelant la date et l’heure du rendez-vous. L’interface praticien permet aussi, qu’en cliquant sur une demande spécifique, il s’ouvre une fenêtre sur l’écran, qui détaille la demande (par exemple à droite sur la ). La illustre une mise à jour du tableau de bord lorsqu’une demande a été acceptée. La pastille ne décompte plus que 4 actions à effectuer au lieu de 5, et les détails montrent la suppression de la demande du Dr AAAAA de 9h00 initialement listée sur la . Une option avantageuse de l’interface praticien de l’invention est la gestion automatique du tableau de bord des demandes. En particulier, une demande peut passer de la barre d’outils individuelle à la barre d’outils généralisée. Un changement de statut peut intervenir automatiquement au bout d'un certain temps (par exemple 1h) si aucun retour, aucune action n’a été entreprise sur une demande individuelle, et la demande passe alors dans la barre d'outils des demandes généralisées. Un changement de statut intervient aussi, comme décrit précédemment, si un praticien effecteur de première intention ne peut répondre à la demande. La demande passe alors en code rouge en individuel et au code orange en généralisée jusqu'à un temps échu (4h par exemple mais variable selon la demande), au terme de ce temps elle passe au rouge. Elle reste consultable comme expliqué précédemment en cliquant sur la barre. Les demandes sont donc consultables en passant la souris sur les codes couleurs, et accessibles à une intervention pour proposer un rendez-vous seulement sur un code couleur orange. Dans une variante de réalisation, une jauge dynamique peut apparaitre en-dessous de la barre d'outils des demandes généralisées, sous la forme d’une petite barre d'outils dans laquelle apparaît le nom du demandeur avec un code couleur orange (signifiant qu’une action est requise). Cette mini barre est dynamique et indique le temps restant avant la fin d’un traitement possible, grâce à une progression de la couleur dans la barre (progression par exemple de gauche à droite). En cas de multiples demandes, par exemple sur la , les barres d'outils se divisent en un nombre de parties égales au nombre de demandes. Elles se segmentent en nombres de demandes et couleurs. Les figures 7 à 7h illustrent différents états de l’interface homme-machine représentant les traitements de demandes à différents avancements du traitement. Sans entrer dans les détails, les figures 7 montrent : : des barres outils de suivi qui combinent le statut des demandes reçues : 5 demandes individuelles reçues, 0 généralisée. : ouverture des détails des 5 demandes reçues : nom demandeur et heure de la demande. : une demande acceptée, 4 demandes à traiter. : 3 demandes acceptées, une refusée, une nouvelle demande arrivée en attente de traitement et une demande généralisée. : une demande acceptée par un effecteur et acceptée par un patient, une demande arrivée, une demande refusée et une demande généralisée. : affichage du statut de demandes envoyées par un demandeur qui sont en attente de traitement et d’acceptation par un patient. : affichage du statut de demandes après qu’un rdv a été proposé au patient ; trois icônes selon trois possibilités, i.e. refusée par le patient, en attente de réponse du patient, acceptée par le patient. : affichage de barres outils qui combinent le statut de demandes individuelles et généralisées reçues coté effecteur. Il a ainsi été décrit un système et un procédé de gestion de prise en charge de patients par un réseau de praticiens, dans un contexte où un premier praticien, un demandeur, a besoin de faire prendre en charge un patient dans un court délai, par un autre praticien, un effecteur. L’homme du métier pourra apporter des variantes de réalisation autour des principes décrits. Système (100) de gestion de prise en charge d’un patient (10) par un réseau médical, le réseau médical (102) comprenant une pluralité de professionnels de santé multidisciplinaires, les professionnels étant équipés de moyens de communication (104) configurés pour communiquer via un réseau de communication (106), le système comprenant : - un module fonctionnel client (108) opérant sur un dispositif informatique (104) de chaque professionnel de santé, permettant de gérer des prises en charge de patients, ledit module client ayant un premier mode opérationnel activable en tant que professionnel de santé demandeur et un deuxième mode opérationnel activable en tant que professionnel de santé effecteur, le module client étant configuré : - dans le premier mode opérationnel, pour communiquer des requêtes individualisées entre un demandeur et un effecteur sélectionné par le demandeur parmi la pluralité de professionnels de santé du réseau médical, et pour communiquer en tant que demandeur des requêtes généralisées vers un ensemble d’effecteurs ; et - dans le deuxième mode opérationnel, pour recevoir et traiter des requêtes individualisées ou généralisées ; - un module fonctionnel serveur (110) comprenant des moyens configurés pour gérer des accès de professionnels de santé au réseau médical et pour gérer des configurations de mise en œuvre des modes opérationnels des modules fonctionnels clients et entre professionnels de santé demandeurs et effecteurs. Système selon la revendication 1 dans lequel le module fonctionnel client (108) comprend : - des moyens fonctionnels (202) dits de premier niveau configurés pour gérer une demande de prise en charge d’un patient, dite « demande de première intention », entre un demandeur et un professionnel de santé sélectionné par le demandeur parmi une liste de professionnels de santé effecteurs de première intention définie pour ladite prise en charge du patient; - des moyens fonctionnels (204) dits de second niveau configurés pour gérer une demande de prise en charge d’un patient, dite « demande généralisée », entre un demandeur et tout ou partie des professionnels de santé du réseau médical, les moyens de second niveau étant activés si une prise en charge de première intention est refusée ou échue; - des moyens fonctionnels (206) configurés pour communiquer à un patient une proposition de prise en charge de première intention ou généralisée, et pour traiter une réponse reçue d’un patient ; et - des moyens fonctionnels (208) de suivi configurés pour afficher sur le dispositif informatique de chaque professionnel de santé, un suivi quantitatif et temporel des prises en charge de demandes de première intention et de demandes généralisées. Système selon la revendication 2 dans lequel : - les moyens (202) de premier niveau sont configurés pour : - créer (402) une requête individualisée de prise en charge d’un patient pour une pathologie donnée, la requête comprenant au moins le nom du professionnel de santé demandeur, une fiche patient contenant des informations administratives et cliniques quant au patient, et des critères quant à la prise en charge du patient ; - sélectionner (404) un professionnel de santé effecteur de première intention, parmi ladite liste de professionnels de santé effecteurs de première intention définie ; et - transmettre (406) une requête individualisée de prise en charge du patient vers le module client de l’effecteur de première intention ; - les moyens (204) de second niveau sont configurés pour générer une liste généralisée de professionnels de santé effecteurs pouvant traiter une requête individualisée refusée (408) par un effecteur de première intention, et pour adresser (412) ladite requête en tant que requête généralisée aux professionnels de santé effecteurs de ladite liste généralisée. Système selon la revendication 2 ou 3 dans lequel les moyens (202) de premier niveau sont de plus configurés pour recevoir (502) une requête individualisée de prise en charge d’un patient, et traiter (504, 506, 508) ladite requête individualisée pour accepter ou refuser la prise en charge. Système selon l’une quelconque des revendications précédentes dans lequel le module fonctionnel client opérant dans le deuxième mode, est configuré pour recevoir (510) une requête généralisée de prise en charge d’un patient, et traiter (512, 514, 516) ladite requête généralisée pour accepter ou refuser la prise en charge. Système selon l’une quelconque des revendications précédentes dans lequel les moyens fonctionnels du module serveur (110) comprennent un module fonctionnel (302) pour gérer des profils de professionnels de santé selon leur spécialité, un module fonctionnel (304) pour gérer des configurations de mise en œuvre des modes opérationnels des modules clients entre professionnels de santé demandeurs et effecteurs, un module (306) de suivi configuré pour gérer un suivi quantitatif et temporel des prises en charge de demandes de première intention et de demandes généralisées pour l’ensemble des professionnels de santé du réseau médical. Système selon l’une quelconque des revendications précédentes dans lequel le dispositif informatique de chaque professionnel de santé comprend une interface homme-machine (212) configurée pour afficher un suivi dynamique des demandes individualisées et généralisées. Système selon la revendication 7 dans lequel l’interface homme-machine comprend un premier onglet pour afficher l’état des envois de requêtes individualisées et généralisées, et un deuxième onglet pour afficher l’état des réceptions de requêtes individualisées et généralisées. Système selon la revendication 7 ou 8 dans lequel l’interface homme-machine est configuré pour afficher un suivi des demandes individualisées et généralisées quantitatif et temporel. Système selon l’une quelconque des revendications précédentes dans lequel les modules fonctionnels clients sont installés sur le module serveur, ledit module serveur opérant les fonctionnalités des modules clients comme un logiciel en tant que service via le réseau de communication (106). Procédé pour gérer une prise en charge d’un patient par un réseau médical, le réseau médical comprenant une pluralité de professionnels de santé multidisciplinaires, les professionnels étant équipés de moyens de communication configurés pour communiquer via un réseau de communication, le procédé étant mis en œuvre par les moyens de l’une quelconque des revendications 1 à 10. Programme d'ordinateur comprenant des instructions de code permettant d’effectuer les étapes du procédé selon la revendication 11, lorsque ledit programme est exécuté sur un ordinateur.