EP3612993A1 - Système intelligent et écoresponsable de transport sanitaire - Google Patents

Abstract

Le système de l'invention assure la régulation et la gestion de transports sanitaires de patients et comprend : des premiers terminaux (TMP, TFP) hébergeant des premières applications logicielles d'utilisateur (AP_PM, AP_PF) pour des prescripteurs, des deuxièmes terminaux (TMT, TFT, TMV) hébergeant des deuxièmes applications logicielles d'utilisateur (AP_TM, AP_TF, AP_VE) pour des transporteurs, un serveur informatique (SP, NS) hébergeant un module logiciel de régulation (REG) et un module logiciel de gestion (GES), et un réseau de communication de données (IT, RTM) autorisant des communications entre les premiers et deuxièmes terminaux et le serveur. Les premiers et deuxièmes terminaux comportent des terminaux mobiles (TMP, TMT, TMV) et les deuxièmes terminaux comprennent des terminaux embarqués (TMV) comportant des capteurs de géolocalisation (GL) et équipant des véhicules de transport, et le module de régulation inclut un moteur d'intelligence artificielle qui réalise la régulation en fonction de la géolocalisation des véhicules et d'un coût de transport estimé et/ou d'un bilan de pollution estimé.

Description

SYSTÈME INTELLIGENT ET ÉCORESPONSABLE

DE TRANSPORT SANITAIRE

L'invention concerne de manière générale le domaine du transport sanitaire. Plus particulièrement, l'invention concerne un système intelligent et écoresponsable de transport sanitaire de patients.

La maîtrise des dépenses liées au transport sanitaire est un sujet prioritaire pour les organismes d'assurance maladie dans les pays économiquement développés. En considérant, par exemple, le cas de la France, les dépenses liées au remboursement du transport sanitaire des patients ne cessent d'augmenter dans des proportions importantes depuis une dizaine d'années. Chaque année, plus de cinq millions de patients bénéficient d'une prise en charge pour se déplacer jusqu'à un lieu de soins, ce qui représente un budget considérable que les organismes d'assurance maladie se doivent de maîtriser.

Des facteurs objectifs peuvent expliquer en partie l'accroissement des dépenses de transport sanitaire. En effet, le vieillissement des populations dans les pays développés entraîne une augmentation des soins médicaux qui conduit irrémédiablement à un besoin accru de transport sanitaire. De plus, les personnes âgées sont davantage exposées à la perte d'autonomie et ont des difficultés à se déplacer par leurs propres moyens, ce qui induit un recours plus fréquent au transport sanitaire. L'augmentation du nombre des patients atteints de maladies chroniques et qui requièrent des transports en série est également un facteur influençant. De plus, la concentration de l'offre de soins dans des grandes unités hospitalières peut conduire, notamment dans les zones rurales, à un plus grand éloignement des patients et à davantage de transport.

Ces facteurs objectifs ne suffisent pas à eux seuls à expliquer l'inflation constatée des dépenses de transport sanitaire dans les pays développés. Une rationalisation de ce secteur est indispensable pour répondre aux inquiétudes légitimes des organismes d'assurance maladie.

Les acteurs du transport sanitaire comportent essentiellement des services ambulanciers intégrés aux centres de soins, des sociétés privées d'ambulances et des taxis conventionnés. Il est fait appel à différents types de véhicules qui sont les ambulances, les véhicules sanitaires légers (VSL) et les taxis conventionnés.

Les prestations de transport sanitaire sont effectuées sur prescription médicale. Il revient au médecin de juger si un patient a besoin ou pas d'un transport et du type de transport requis. Le type de transport dépendra de l'état de santé du patient. Si, par exemple, le patient a besoin d'aide pour marcher, le médecin prescrira un trajet en taxi conventionné ou en véhicule VSL qui dispose lui d'un équipement de secours. L'ambulance est réservée au patient qui doit être transporté allongé ou qui nécessite une surveillance médicale.

Le médecin prescripteur, qu'il exerce son activité à titre libéral ou au sein d'un centre de soins, est un acteur essentiel qui doit être parfaitement informé, responsabilisé et impliqué pour une collaboration active au bon fonctionnement du transport sanitaire. De nouveaux outils devraient être développés en ce sens, notamment pour assister le médecin libéral dans le choix du transport le mieux adapté à la situation, et lui offrir une visibilité accrue sur les transports effectivement réalisés par rapport à un budget alloué de transport sanitaire, sachant que les prescriptions, pour diverses raisons, ne sont pas toujours utilisées par les patients.

Dans les grands centres de soins tels que les hôpitaux, le transport sanitaire est habituellement régi par un service ou plateforme de régulation qui gère les transports effectués par une flotte interne d'ambulances et ceux effectués en ayant recours à des acteurs privés.

Un «tour de rôle » est souvent pratiqué pour l'attribution des missions de transport aux acteurs privés. Le tour de rôle, dans sa pratique actuelle, peut s'avérer être un sujet de controverse et un facteur d'accroissement des dépenses. Le recours aux taxis conventionnés s'est beaucoup développé ces dernières années au détriment des véhicules VSL, alors que les véhicules VSL offrent des prestations sanitaires non disponibles dans les taxis et ont un coût de transport est plus abordable.

Par ailleurs, la traçabilité de la prescription de transport demanderait à être consolidée. Il serait souhaitable que le prescripteur du transport soit dans tous les cas un médecin ayant une connaissance suffisante du dossier médical.

Dans un futur proche, les centres de soins auront à gérer, de même que les médecins libéraux, un budget de transport alloué par l'organisme d'assurance maladie. Les ressources disponibles devront donc être utilisables de manière optimale pour éviter des dépassements de budget et des dépenses restant à la charge des centres de soins.

Dans l'état de la technique, il est connu de l'entité inventive une plateforme, mise en œuvre par ordinateur, pour la régulation du transport sanitaire. Cette plateforme est destinée à être implantée dans un centre de soins et vise à optimiser l'utilisation des ressources de transport sanitaire. Cependant, dans cette plateforme, le niveau d'intégration des différents acteurs, et notamment les acteurs de transport privés et les médecins prescripteurs, reste insuffisant pour répondre de manière satisfaisante à la problématique exposée plus haut.

Par ailleurs, il serait souhaitable que le secteur du transport sanitaire progresse dans le domaine de l'écoresponsabilité vis-à-vis des émissions de CO2.

La réduction de l'empreinte CO2 passe par une minimisation du kilométrage parcouru et une bonne adéquation entre le moyen de transport utilisé, en termes de rejets de CO2, et le besoin de transport sanitaire prescrit par le médecin. Si la minimisation du kilométrage, par un choix optimum du trajet des véhicules, apparaît relativement aisée à mettre à place pour des flottes de transport sanitaire intégrées aux centres de soins, au moyen par exemple de la plateforme interne de régulation ou de dispositifs de navigation par GPS, il n'en est pas de même lorsque interviennent des acteurs privés, tels que les taxis conventionnés, dont la facturation est liée notamment au kilométrage parcouru.

Il existe donc un besoin pour un système intelligent et écoresponsable de transport sanitaire qui apporte une réponse satisfaisante aux besoins de rationalisation et de maîtrise des dépenses, en fournissant une régulation optimale et une gestion administrative complète des prestations de transport sanitaire, tout en apportant aux acteurs davantage de visibilité pour une utilisation compatible avec des budgets de transport alloués. Par ailleurs, un tel système doit être en mesure de traiter les données disponibles afin de produire des rapports d'activité, des analyses et prévisions, ainsi que des statistiques.

L'invention concerne donc un système intelligent et écoresponsable de transport sanitaire pour la régulation et la gestion d'une pluralité de transports sanitaires de patients, comprenant :

- une pluralité de premiers terminaux hébergeant des premières applications logicielles d'utilisateur pour une pluralité de prescripteurs de transports sanitaires,

- une pluralité de deuxièmes terminaux hébergeant des deuxièmes applications logicielles d'utilisateur pour une pluralité de transporteurs,

- au moins un serveur informatique hébergeant un module logiciel de régulation des transports sanitaires de patients et un module logiciel de gestion et édition de document, et

- un réseau de communication de données autorisant des communications de données entre les premiers terminaux et le au moins un serveur informatique et entre les deuxièmes terminaux et le au moins un serveur informatique, dans lequel les premiers et deuxièmes terminaux comportent des terminaux mobiles et les deuxièmes terminaux comprennent des terminaux embarqués comportant des capteurs de géolocalisation et équipant des véhicules de transport de patients, et

dans lequel le module logiciel de régulation inclut un moteur d'intelligence artificielle qui réalise la régulation des transports sanitaires en fonction de la géolocalisation des véhicules de transport et d'un coût de transport estimé et/ou d'un bilan de pollution estimé.

Selon une caractéristique particulière, le moteur d'intelligence artificielle réalise la régulation des transports sanitaires en fonction aussi d'un tour de rôle des transporteurs.

Selon une autre caractéristique particulière, le moteur d'intelligence artificielle réalise la régulation des transports sanitaires en fonction aussi d'adéquations horaires entre des heures de transport demandées et des heures d'arrivée estimées des véhicules de transport.

Selon encore une autre caractéristique particulière, le moteur d'intelligence artificielle réalise la régulation des transports sanitaires en fonction aussi d'un état sanitaire des véhicules de transport.

Selon encore une autre caractéristique particulière, le moteur d'intelligence artificielle réalise le régulation des transports sanitaires en fonction aussi d'un niveau d'occupation et du planning de transport des véhicules de transport.

Selon encore une autre caractéristique particulière, lors des saisies de prescriptions de transports sanitaires, les prescripteurs saisissent, sur les premiers terminaux, des informations comprenant une identification de prescripteur et/ou une identification de patient et/ou un mode de transport demandé et/ou des informations médicales et/ou des informations de point de départ/point d'arrivée et/ou des informations de transport immédiat ou à date ultérieure à préciser et/ou des informations de transport en série.

Selon encore une autre caractéristique particulière, les premiers terminaux comprennent des moyens de signature électronique pour recevoir des signatures de prescripteur.

Selon encore une autre caractéristique particulière, les deuxièmes terminaux comprennent des moyens de signature électronique pour recevoir des signatures de transporteur et/ou des signatures de patient.

Selon encore une autre caractéristique particulière, le au moins un serveur informatique réalise, au moyen du module logiciel de gestion et édition de document, des opérations de chiffrage et facturation des transports sanitaires de patients et des opérations d'émission de factures et/ou de documents.

Selon encore une autre caractéristique particulière, les opérations de chiffrage et facturation sont réalisées à partir d'un kilométrage de trajet optimal retenu qui a été déterminé par le moteur d'intelligence artificielle.

Selon encore une autre caractéristique particulière, le au moins un serveur informatique réalise une sauvegarde de données relatives aux transports sanitaires de patients réalisés et/ou en cours.

Selon encore une autre caractéristique particulière, le au moins un serveur informatique comprend des moyens d'édition de rapports d'activité, des moyens de calcul statistique et des moyens d'analyse et prévision, ces moyens exploitant les données sauvegardées et étant accessibles par les prescripteurs, les transporteurs et des centre de soins.

Selon encore une autre caractéristique particulière, les terminaux embarqués comprennent un module de navigation intégré qui est piloté par le système à partir de données de géolocalisation fournies par le capteur de géolocalisation.

Selon encore une autre caractéristique particulière, le module de navigation intégré est également piloté par le système à partir de données de trafic routier.

Selon encore une autre caractéristique particulière, les terminaux embarqués comprennent des téléphones intelligents dits « smartphones » et/ou des tablettes informatiques.

Selon encore une autre caractéristique particulière, les premiers terminaux comprennent des ordinateurs, des téléphones intelligents dits « smartphones » et/ou des tablettes informatiques.

Selon encore une autre caractéristique particulière, les deuxièmes terminaux comprennent des ordinateurs, des téléphones intelligents dits « smartphones » et/ou des tablettes informatiques.

Selon encore une autre caractéristique particulière, ledit réseau de communication de données comprend le réseau Internet. Selon encore une autre caractéristique particulière, le réseau de communication de données comprend un réseau cellulaire de téléphonie mobile.

Selon encore une autre caractéristique particulière, les communications de données sont établies à travers des liaisons de données hertziennes et/ou des liaisons de données filaires.

D'autres avantages et caractéristiques de la présente invention apparaîtront plus clairement à la lecture de la description ci-dessous de plusieurs formes de réalisation particulières en référence aux dessins annexés, dans lesquels :

- la Fig.1 montre les différents acteurs participant au système de transport sanitaire selon l'invention ;

- la Fig.2 est un bloc-diagramme montrant l'architecture générale du système de transport sanitaire selon l'invention ;

- la Fig.3 montre la configuration d'un fichier de transport utilisé par le traitement de données effectué par le système de transport sanitaire selon l'invention ;

- les Figs.4 et 5 sont des bloc-diagrammes montrant l'architecture et le fonctionnement d'un module logiciel de régulation inclus dans le système de transport sanitaire selon l'invention ; et

- la Fig.6 est bloc-diagramme montrant l'architecture et le fonctionnement d'un module logiciel de gestion inclus dans le système de transport sanitaire selon l'invention.

Comme montré à la Fig.1 , le système de transport sanitaire STS selon l'invention est déployé à travers un réseau de communication tel que le réseau Internet IT.

Le système STS est implanté dans un ou plusieurs serveurs connectés au réseau Internet IT Typiquement, un serveur principal SP est situé dans des locaux d'un centre d'exploitation du système STS et est relié à un nuage de serveurs NS (dit « cloud » en anglais) qui autorise un accès rapide au système STS par ses différents acteurs.

Comme cela apparaît à la Fig.1 , le système STS selon l'invention organise les échanges entre les différents acteurs de manière à permettre la bonne réalisation de transports sanitaires. Les différents acteurs, excepté le patient PAT bénéficiaire du transport, ont été enregistrés préalablement et sont donc connus du système STS. Le patient PAT est un assuré d'un organisme d'assurance maladie et est connu par un numéro d'assuré.

Les transports sanitaires sont prescrits typiquement par des médecins prescripteurs P qui sont, de manière générale, des médecins en pratique libérale ou des médecins exerçant dans des centres de soins. Les termes « centres de soins » sont à interpréter ici au sens le plus large et recouvrent non seulement des hôpitaux et cliniques HOSP et autres, mais aussi des centres d'imagerie IAM, d'analyses médicales, de dialyse et autres, ainsi que des maisons médicalisées de retraite EM, de convalescence, de rééducation et autres. Typiquement, les transports sont effectués, de manière non exclusive, entre le domicile DOM du patient PAT et un centre de soins ou de centre de soins à centre de soins. Selon l'état sanitaire du patient PAT, le prescripteur P préconise le mode de transport qui lui semble le plus adapté. Ainsi, le prescripteur P peut demander un transport par ambulance ou un transport en position assise qui pourra être assuré par un véhicule sanitaire léger ou un taxi conventionné. Le prescripteur P peut également autoriser un transport à plusieurs, dit par la suite « transport partagé ». Il peut également prescrire une série de transports, dit « transport en série », pour plusieurs soins réguliers comme par exemple des dialyses.

Les transports sanitaires sont réalisés par des transporteurs T qui sont typiquement des sociétés privées d'ambulances et des taxis conventionnés. Pour les transports sanitaires, il est fait appel à une flotte de véhicules V comprenant des ambulances AMB, des véhicules sanitaires légers VSL et des taxis TAX.

L'accès au système STS par les différents acteurs est réalisé à travers des terminaux fixes ou mobiles tels qu'un ordinateur ORD, un téléphone tel qu'un téléphone intelligent dit « smartphone » PH ou une tablette informatique TAB. Selon les acteurs, les terminaux ORD, PH, TAB, hébergent des applications logicielles d'utilisateur dédiées ou permettent un accès à travers une plateforme internet comportant des espaces privés.

L'architecture du système de transport sanitaire STS selon l'invention est représentée de manière générale à la Fig.2.

Comme montré à la Fig.2, le système STS comprend un ou plusieurs serveurs SP, NS, une pluralité de terminaux fixes et de terminaux mobiles ORD, PH, TAB, et des bases de données BR et BG.

Les serveurs SP, NS, comprennent un processeur μΡ, des mémoires RAM et ROM, une interface réseau 1RS et des modules logiciels de régulation REG et de gestion GES. Le processeur μΡ, typiquement un microprocesseur, et les mémoires RAM et ROM opèrent de manière connue, en exécutant des instructions de programme de modules logiciels réalisant différentes fonctions opérationnelles du système STS. Le fonctionnement des modules logiciels

REG et GES sera décrit plus bas en détail, en référence aux Figs.3 à 6.

Les terminaux fixes et mobiles se répartissent en différentes catégories.

Les terminaux TMP, TMT et TMV sont des terminaux mobiles ou embarqués prenant la forme de tablettes TAB ou smartphones PH hébergeant des applications logicielles d'utilisateur dédiées AP_PM, AP_TM et AP_VE, respectivement.

Les terminaux TFP et TFT sont des terminaux fixes prenant la forme d'ordinateur ORD hébergeant des applications logicielles d'utilisateur dédiées AP_PF et AP_TF, respectivement.

Les terminaux TP sont les ordinateurs ORD, téléphones PH et tablettes TAB utilisés par les patients PAT pour communiquer avec le système STS. L'accès au système STS se fait à travers le réseau internet IT, de manière connue, en utilisant un navigateur internet ou une application spécifique sur smartphone ou tablette. Les patients PAT ont la possibilité de créer des espaces privés sur une plateforme internet du système STS de manière à communiquer avec celui-ci. Les terminaux TMP et TFP sont les terminaux utilisés par les prescripteurs P. Les terminaux mobiles TMP utilisent le réseau internet IT pour se connecter aux serveurs SP, NS, du système STS à travers deux types de liaison de données de type hertzienne. Ils utilisent ainsi soit une liaison de données L_PH à travers un réseau cellulaire de téléphonie mobile RTM soit une liaison de données L_WF à travers une borne BWF d'un réseau WIFI local. Par exemple, la borne BWF est intégrée dans un boîtier de type ADSL qui est connecté à un terminal fixe TFP du prescripteur P. Les terminaux fixes TFP se connectent aux serveurs SP, NS, à travers le réseau internet IT, typiquement par liaison filaire, par exemple, à travers un boîtier de type ADSL.

Les applications logicielles AP_PM et AP_PF, hébergées respectivement dans les terminaux mobiles TMP et fixes TFP, sont conçues pour permettre aux prescripteurs P de saisir et de transmettre de manière cryptée les prescriptions vers les serveurs SP, NS. Ces applications logicielles AP_PM et AP_PF intègrent des fonctionnalités d'information et d'assistance pour guider les prescripteurs P lors de la saisie de leurs prescriptions de transport. Les applications logicielles AP_PM et AP_PF comportent aussi des fonctionnalités de consultation d'espaces privés dans lesquels les prescripteurs P peuvent accéder à leurs données DPR (base de données BG) . Dans leurs espaces privés, les prescripteurs P peuvent éditer des rapports d'activité RAC et optimiser leur utilisation d'un budget alloué de transport sanitaire au moyen d'outils de statistiques OST et d'analyse et prévision OAP On notera que les prescripteurs P pourront également consulter leurs espaces privés en utilisant un navigateur internet.

Trois types de terminaux TMT, TFT et TMV sont prévus pour les transporteurs T. Les terminaux TMV sont des terminaux mobiles ou embarqués qui sont dédiés aux équipages des véhicules. Les terminaux TMT et TFT permettent un accès complet aux comptes des transporteurs T et sont utilisés par des personnes habilitées.

Les terminaux mobiles TMT utilisent le réseau internet IT pour se connecter aux serveurs SP, NS, du système STS à travers deux types de liaison de données. Ils utilisent ainsi soit une liaison de données L_PH à travers un réseau cellulaire de téléphonie mobile RTM soit une liaison de données L_WF à travers une borne BWF d'un réseau WIFI local. Par exemple, la borne BWF est intégrée dans un boîtier de type ADSL qui est connecté à un terminal fixe TFT du transporteur T. Les terminaux fixes TFT se connectent aux serveurs SP, NS, à travers le réseau internet IT, typiquement par liaison filaire, par exemple, à travers un boîtier de type ADSL.

Les applications logicielles AP_TM et AP_TF, hébergées respectivement dans les terminaux mobiles TMT et fixes TFT, sont conçues pour permettre aux transporteurs T d'interagir avec le système STS de manière cryptée. Les applications AP_TM et AP_TF permettent ainsi aux transporteurs T de consulter, dans des espaces privés, des missions de transport qui sont proposées par le système STS après une sélection intelligente, d'accepter ou de refuser une mission, d'annuler à postériori une acceptation de mission et d'échanger des informations avec le système STS et les patients PAT afin de mener à bien les missions de transport. Ces applications logicielles AP_TM et AP_TF intègrent des fonctionnalités d'information et d'assistance pour guider les transporteurs T lors de leur utilisation du système STS. Les applications logicielles AP_TM et AP_TF comportent aussi des fonctionnalités de consultation d'espaces privés dans lesquels les transporteurs T peuvent accéder à leurs données DTR (base de données BG). Dans leurs espaces privés, les transporteurs T peuvent consulter la facturation FAD, éditer des rapports d'activité RAC, ainsi qu'utiliser des outils de statistiques OST et d'analyse et prévision OAP. On notera que les transporteurs T pourront également consulter leurs espaces privés en utilisant un navigateur internet.

Les terminaux mobiles ou embarqués TMV des équipages mobiles des véhicules V sont conçus pour interagir avec le système STS de manière cryptée. Les terminaux TMV utilisent le réseau internet IT pour se connecter aux serveurs SP, NS, du système STS par une liaison de données L_PH, à travers un réseau cellulaire de téléphonie mobile RTM. Dans le cas où le véhicule V possède sa propre connexion au réseau internet IT, une borne WIFI locale du véhicule V pourra être utilisée pour la liaison de données entre le terminal TMV et le serveur SP, NS.

L'application logicielle AP_VE, hébergée dans les terminaux AP_VE, est conçue pour permettre à l'équipage du véhicule V d'interagir avec le système STS et pour héberger un module de navigation intégré qui est piloté par le système STS à partir de données de géolocalisation GL fournies par un capteur (GPS) du terminal TMV. L'application AP_VE permet ainsi à l'équipage du véhicule V de consulter, dans leur espace privé, les missions de transport qui sont proposées au véhicule V par le système STS après une sélection intelligente, d'accepter ou de refuser une mission, d'annuler à postériori une acceptation de mission et d'échanger des informations avec le système STS et les patients PAT afin de mener à bien les missions de transport. L'application AP_VE comporte également une fonction de signature électronique pour recueillir la signature du patient PAT qui atteste de la réalisation de la mission de transport. Cette signature du patient pourra être recueillie sur un écran tactile équipant le terminal TMV.

Les bases de données de régulation BR et de gestion BG sont hébergées dans des unités de mémoire de masse (non représentées) des serveurs SP, NS.

La base de données BR et BG contiennent l'ensemble des données nécessaires au fonctionnement du système STS selon l'invention, et notamment au fonctionnement des modules logiciels REG et GES.

Les transporteurs T et les prescripteurs P référencés comme affiliés au système STS sont connus par des fichiers respectifs qui sont accessibles dans les bases BR et BG.

Le fichier T(V) d'un transporteur T comportent toutes les informations nécessaires à la gestion ainsi qu'un descriptif pour chacun des véhicules V de la flotte du transporteur. Le descriptif est actualisé de manière dynamique et indique la disponibilité ou pas du véhicule pour une mission de transport, le type de véhicule (ambulance, VLS, taxi), le nombre de places disponibles pour les patients, l'état sanitaire du véhicule (désinfecté ou pas), la géolocalisation GL du véhicule, les émissions de polluants du véhicule et autres.

Le fichier P(CdS) d'un prescripteur P comportent toutes les informations nécessaires à la gestion, et notamment son statut de praticien libéral ou de rattachement à un centre de soins CdS et, dans le second cas, les informations relatives au centre de soins CdS. Des fichiers M de transports en cours sont également accessibles dans les bases de données BR et BG. On notera que ces fichiers sont dynamiques et sont renseignés par le système STS au fur et à mesure du traitement des missions de transport. Dans la base de données de gestion BG sont aussi sauvegardés les fichiers M de transports effectués.

La base de données de régulation BR comprend également des fichiers de données de géolocalisation GL des véhicules qui sont rafraîchis en permanence avec les données GL transmises par le terminal mobile ou embarqué de véhicule TMV.

Une cartographie CART et des données de trafic routier TRAF sont également contenues dans la base de données BR. Typiquement, la cartographie CART et les données de trafic routier TRAF sont alimentées en données et actualisées par des services fournisseurs externes avec lesquels communique le système STS.

Comme indiqué plus haut, la base de données de gestion BG contient, de même que la base BR, l'ensemble des fichiers de prescripteur P(CdS) et de transporteurs T(V), et les fichiers M de transports en cours et effectués. Ces différents fichiers sont utilisés par le module de gestion pour l'édition de factures et de documents FAD qui sont destinés à l'organisme d'assurance maladie. Les fichiers FAD édités sont conservés dans la base de données BG.

Les données contenues dans les fichiers P(CdS), T(V), M et FAD sont sauvegardées sans la base de données BG et alimentent des outils d'édition de rapports d'activité RAC, de statistiques OST et d'analyse et prévision OAR

Un exemple d'un fichier de transport quelconque Mm, utilisé par le système STS, est représenté à la Fig.3.

Dans cet exemple, le fichier Mm comprend les informations suivantes :

IDM sont les informations d'identification du prescripteur P (et du centre de soins auquel il est rattaché, si applicable). Les informations IDM sont préremplies par le système STS lorsque le prescripteur ouvre un dossier de prescription de transport à travers un terminal TMP, TFP

IDP sont les informations d'identification du patient PAT et comporte notamment un numéro d'assuré. Ces informations sont renseignées par le prescripteur P.

- CDP sont les coordonnées du patient PAT utilisables pour joindre celui-ci. Elles peuvent comprendre une adresse de messagerie électronique, un numéro de téléphone, etc. Les coordonnées CDP sont destinées notamment à être remises au transporteur T qui prendra à charge la mission de transport. Ces informations sont renseignées par le prescripteur P.

- MTD est le mode de transport demandé par le prescripteur P. MTD indique le type de véhicule, à savoir, une ambulance, un VLS ou un taxi, et la possibilité d'un transport partagé ou pas. Ces informations sont renseignées par le prescripteur P. IM sont des informations d'ordre médical indiquées par le prescripteur P.

- D-A sont les informations de lieu de départ et d'arrivée renseignées par le prescripteur P. - UR/DIF sont les informations relatives au moment auquel doit être effectué la mission de transport. Le prescripteur P peut indiquer ici s'il s'agit d'un transport urgent/immédiat ou un transport différé dont la date et l'heure seront précisés ultérieurement par le patient PAT (par exemple, une fois que celui-ci a obtenu un rendez-vous).

- TS est une information qui indique si la prescription est relative à un transport en série.

- T est une information qui est renseignée par le système STS pendant la régulation et qui indique le transporteur retenu pour effectuer la mission de transport.

- CDT sont les coordonnées du transporteur retenu T qui sont renseignées par le système STS pendant la régulation et destinées notamment à être transmises au patient PAT, par exemple, pour informer le transporteur T d'une date/heure de transport après prise de rendez-vous.

- DA-DH sont des informations renseignées par le système STS pendant la régulation et précisant les points de départ et d'arrivée ainsi que la date et l'heure à laquelle le véhicule V récupère le patient PAT.

- Vt sont des informations renseignées par le système STS pendant la régulation et qui identifient le véhicule retenu, son type (ambulance, VSL, Taxi) et un mode de transport partagé ou pas.

- Trj sont des informations renseignées par le système STS pendant la régulation et qui indiquent le trajet optimal retenu et le kilométrage de ce trajet. Ces informations sont destinées au transporteur retenu. Une navigation cartographique correspondante au trajet retenu est assurée par le système STS à travers l'application AP_VE et un affichage sur l'écran du terminal TMV. En cas d'écart par rapport au trajet retenu, la navigation calcule en dynamique un nouveau trajet et fournit au système STS, en fin de mission de transport, le kilométrage parcouru de manière effective.

- CTE est un coût financier estimé pour la mission de transport. Le coût CTE est calculé par le système STS pour les besoins de la régulation. Le coût CTE est une estimation calculée pendant le processus de traitement de la régulation et pourra différer du montant réel facturé pour la mission de transport.

- BPE est un bilan de pollution estimé, ou empreinte CO2, calculé par le système STS pour les besoins de la régulation. BPE concerne la mission de transport considérée avec le trajet Trj et le mode de transport Vp retenus.

- COT sont des informations complémentaires fournies par le transporteur retenu à la fin de la mission de transport. Les informations COT comprendront notamment les noms des ambulanciers. Elles pourront aussi comprendre, par exemple, des informations pour expliquer un écart par rapport aux données initiales définissant la mission de transport, tel que par exemple un écart de trajet impactant le kilométrage ou une annulation d'un patient sur un transport partagé. Les informations COT sont utilisées par le module de gestion GES pour le contrôle et la consolidation de la facturation.

- CTC sont des informations de facturation comprenant un coût de transport consolidé qui est calculé par le module de gestion GES du système STS. Le calcul se fonde sur les informations Trj de trajet/kilométrage, consolidées après contrôle avec les informations complémentaires COT fournies par le transporteur, et d'éventuels temps d'attente (Taxi) déterminés à partir des données de géolocalisation GL.

- SMP, ST et SP sont des données de signature électronique des prescripteur P, transporteur T et patient PAT.

En référence aussi aux Figs.4 et 5, il est maintenant décrit l'architecture et le fonctionnement du module logiciel de régulation REG intégré dans le système intelligent et écoresponsable de transport sanitaire STS selon l'invention.

Il est montré à la Fig.4 le traitement effectué par le module REG pour une prescription de transport sanitaire à laquelle correspond un fichier de transport Mm.

Un ensemble de N prescripteurs et un ensemble de R transporteurs sont affiliés et référencés dans le système STS. Le module REG a accès à l'ensemble des fichiers de prescripteur P(CdS) et de transporteur T(V).

Le bloc R1 représente l'ensemble des fichiers de transport M qui sont en cours de traitement par le module REG et qui correspondent à des prescriptions par des prescripteurs, P1 à PN.

Le fichier de transport Mm est créé par le module REG à l'ouverture par le prescripteur Pn de la prescription correspondante, en utilisant son terminal TMP, TFP. Le fichier Mm est inclus dans un ensemble de fichiers M1 à MK correspondant à l'ensemble des prescriptions en cours de traitement pour le prescripteur Pn. L'ensemble de fichiers M1 à MK sont accessibles au prescripteur Pn à travers un espace privé de celui-ci.

Dans le bloc R1 , le prescripteur Pn renseigne le fichier Mm avec un groupe d'informations GP1 (Fig.3) regroupant les informations IDM à TS. Pendant la session de saisie du fichier Mm, le prescripteur Pn a la possibilité de revenir en arrière pour effectuer des corrections et il a également la possibilité d'annuler le fichier Mm en cours de saisie. Tant que le fichier Mm n'est pas signé par le prescripteur Pn, il reste à l'état de brouillon et peut être repris et modifié à volonté par le prescripteur Pn. Une fois le fichier Mm signé par le prescripteur Pn, celui-ci est transmis, T1 , avec la signature SMP du prescripteur, à un moteur logiciel d'intelligence artificielle NIA tel qu'un moteur d'inférences.

Le bloc R2 représente l'ensemble des fichiers de transporteur T(V)1 à T(V)R correspondant aux transporteurs T1 à TR. Il est représenté un fichier de transporteur T(V)t quelconque correspondant à un transporteur Tt ayant un nombre Z de véhicules qui sont identifiés Vt1 à VtZ. Pour les besoins du traitement de régulation, le fichier de transporteur T(V)t comprend, pour chacun des Z véhicules, un groupe d'informations GT1 , montré à la Fig.5, qui comporte l'identification du véhicule avec son type (Ambulance, VSL, Taxi), Vt1 à VtZ, des informations d'état associées au véhicule, E1 à EZ, et la géolocalisation associée au véhicule, GL1 à GLZ.

Comme montré à la Fig.5, les informations d'état E associées à un véhicule comprennent une information d'état sanitaire SAN (véhicule désinfecté ou pas), une information de niveau d'occupation NO (Nombre de places disponibles), des informations PLAN du planning des futurs transports affectés au véhicule, des informations de rejets polluants (CO2) du véhicule et une information VAP de version de l'application logicielle AP_VE pour le pilotage de navigation du véhicule.

L'ensemble des fichiers de transporteur T(V)1 à T(V)R est accessible, T2 (Fig.4), par le moteur d'intelligence artificielle NIA.

Le traitement effectué par le moteur NIA est détaillé à la Fig.5.

Comme montré à la Fig.5, le moteur NIA réalise une sélection S_Mm de véhicules représentant les meilleures coïncidences obtenues dans les fichiers de transporteur T(V) pour le fichier de transport Mm correspondant à la prescription.

Pour chacun des véhicules V géolocalisés, en utilisant les informations disponibles dans les groupes GP1 et GT1 du fichier de transport Mm et des fichiers de transporteur T(V)1 à T(V)R, la cartographie CART et les informations de trafic routier TRAF, le moteur NIA détermine un groupe de critères de sélection CS qui est utilisé pour la sélection.

Préalablement à la détermination des critères de sélection CS, le moteur NIA calcule un trajet optimal Trj pour un ensemble initial de véhicules présélectionnés sur une adéquation entre le type de véhicule Vt, sa disponibilité (SAN, NO, PLAN) et la prescription de transport. Le trajet optimal Trj est déterminé non seulement par la distance kilométrique découlant des points de départ et d'arrivée D-A et de la géolocalisation GL du véhicule, mais aussi en tenant compte d'un bilan de pollution estimé BPE pour chacun des trajets envisagés. Les informations de rejets polluants CPOL des véhicules seront utilisées pour le calcul du bilan de pollution estimé BPE. Le nombre de carrefours sur les trajets, les informations de trafic TRAF et d'autres informations, telles que des interdictions de roulage de véhicule dans des zones polluées, pourront être pris en compte par le moteur NIA pour déterminer le trajet optimal Trj.

Le groupe de critères de sélection CS comprend les critères suivant :

- CTE qui est le coût de transport estimé associé au véhicule. Ce coût dépendra bien entendu du type Vt du véhicule, du trajet Trj retenu, des conditions du transport (partagé ou pas), de temps d'attente estimés (Taxi), etc.

- BPE qui est le bilan de pollution estimé associé au véhicule pour le trajet Trj retenu.

- ADH qui représente un écart d'adéquation horaire entre l'heure de transport demandée pour récupérer le patient et l'heure d'arrivée estimée du véhicule V.

- TRT qui représente une priorité de tour de rôle associée au transporteur T. Des pondérations P1 à P4 sont associées respectivement aux critères CTE, BPE, ADH et TRT.

La sélection S_Mm est obtenue à partir des meilleures coïncidences sur la satisfaction des critères pondérés. On notera que les pondérations P1 à P4 sont déterminées de manière dynamique par le moteur d'intelligence artificielle NIA. L'apprentissage du moteur d'intelligence artificielle NIA intervient pendant une phase initiale d'expérimentation et de mise au point du système STS.

Dans cet exemple, pour le fichier de transport Mm, le moteur NIA fournit une sélection S_Mm composée de trois sélections de véhicule S1 , S2 et S3. Les sélections S1 , S2 et S3 concernent des véhicules Vtx, Vty et Vtz de transporteurs Tx, Ty et Ty pour des trajets Trjx, Trjy et Trjz, respectivement. Des indicateurs de niveau de coïncidence Cx, Cy et Cz sont également associés aux sélections S1 , S2 et S3, respectivement.

En référence de nouveau à la Fig.4, comme montré dans le bloc R3, les sélections S1 (Tx, Vtx), S2(Ty, Vty) et S3(Tz, Vtz) sont transmises, T3, par le moteur NIA vers les espaces privés des transporteurs concernées, Tx, Ty et Tz, et ceux-ci reçoivent à travers leurs terminaux TMT, TFT et TMV des informations pour signaler l'arrivée d'offres de mission de transport.

On notera que les indicateurs de niveau de coïncidence Cx, Cy et Cz, qui n'offrent pas d'intérêt pour les transporteurs, ne sont pas affichées dans les espaces privés. Par contre, l'ensemble des données relatives à la sélection S_Mm, comprenant notamment les indicateurs de niveau de coïncidence Cx, Cy et Cz, sont sauvegardées, T4, par le moteur RIA dans un autre bloc R4.

On notera aussi que seules les informations des fichiers Mm strictement nécessaires à l'exécution de la mission de transport sont affichées dans les espaces privés des transporteurs Tx, Ty et Tz. De manière générale, le moteur NIA gère les informations, et notamment les informations sensibles telles que les numéros d'assuré, les noms des médecins prescripteurs, etc., de manière à ce que les différents acteurs n'aient accès qu'aux informations qui leurs sont nécessaires et autorisées par la réglementation.

Dans le bloc R3, il est montré l'acceptation X de l'offre de mission de transport par les transporteurs Tx et Tz pour les sélections S1 (Tx, Vtx) et S3(Tz, Vtz), respectivement. Ces acceptations X sont indiquées, T5, au moteur NIA et correspondent à des signatures ST provisoires des transporteurs Tx et Tz.

Une fonction d'attribution de mission de transport AT du moteur NIA choisit alors la sélection, S1 ou S3, ayant niveau de coïncidence, Cx ou Cz, le plus élevé. Les niveaux de coïncidence Cx, Cz, sont fournis, T6, à la fonction d'attribution de mission de transport AT.

Dans le bloc R5, il est considéré que la sélection S1 (Tx, Vtx) a été choisie par le moteur

NIA pour le transport Mm. Une fois que le transporteur Tx a confirmé son acceptation X du transport Mm, ce qui correspond à une signature ST finale, les informations relatives au transport Mm lui sont transmises, T7, par la fonction d'attribution de mission de transport AT, dans son espace privé. Outre le véhicule retenu Vtx et le trajet retenu Trj, il est également transmis toutes les informations utiles à la réalisation du transport et notamment les informations DA-DH de points de départ et d'arrivée et de date/heure, ainsi que les coordonnées CDP du patient PAT. Les transporteurs Ty et Tz non retenus par le moteur NIA pour le transport Mm en sont informés par une transmission d'information, T1 , dans leurs espaces privés respectifs.

Le bloc R6 représente une communication au patient PAT qui est transmise, T8, par la fonction d'attribution de mission de transport AT vers les terminaux TP de celui-ci. Par exemple, par un message de type SMS vers son téléphone PH, un courriel vers sa boîte de messagerie et/ou une communication dans son espace privé s'il en a créé un. Le patient PAT reçoit toute l'information nécessaire qui identifie le transport Mm, le transporteur Tx avec ses coordonnées CDT, et la date/heure (DA-DH) du départ.

Dans le cas un transport en série, indiqué par l'information UR/DIF renseignée par le prescripteur Pn, le traitement effectué par le moteur NIA diffère de celui qui vient d'être décrit. En effet, la sélection effectuée par le moteur NIA est faite individuellement pour chacun des transports de la série. L'identification d'un transport en série par le moteur NIA fait suite à la transmission, T1 , du fichier de transport Mm au moteur NIA. Le moteur NIA transmet alors une information au patient PAT, bloc R7, lui demandant de communiquer l'information DA-DH pour chaque transport. Cette information est transmise au patient PAT, par exemple, par un message de type SMS vers son téléphone PH, un courriel vers sa boîte de messagerie et/ou une communication dans son espace privé si celui-ci a été créé à son initiative. Le retour du patient PAT, bloc R8, par exemple après une prise de rendez-vous médical, peut intervenir par la messagerie, l'espace privé ou par un appel à un numéro téléphonique qui aura été indiqué au patient PAT. Une fois l'information DA- DH connue par le moteur NIA, le fichier de transport Mm est renseigné et est ensuite traité par le moteur NIA pour sélectionner un transporteur T, de la manière décrite dans les paragraphes ci- dessus.

Dans une autre forme de réalisation, un même transporteur pourra être choisi par le moteur NIA pour effectuer la totalité d'un transport en série dans la mesure où l'intelligence artificielle estime que des conditions de proximité favorables sont respectées après avoir pris en compte des historiques de géolocalisation des véhicules des transporteurs.

De manière générale, on notera que le système STS est optimisé pour une sélection tardive du transporteur T, afin de bénéficier pleinement de la géolocalisation en temps réel des véhicules qui autorise des sélections plus performantes. Cependant, une sélection plus précoce du transporteur T est également possible et s'appuiera, dans ce cas-là, davantage sur le planning PLAN des transports des véhicules (Fig.5).

Les annulations/modifications de transports sont gérées par le moteur NIA de la manière décrite ci-après.

Lorsque l'annulation du transport Mm fait suite à un désistement du transporteur Tx sélectionné (bloc R5). Le transporteur Tx indique cette annulation dans son espace privé. Le moteur NIA est alors informé et le fichier de transport Mm est réintroduit en entrée, T1 , du processus de traitement pour faire aboutir une nouvelle sélection. Lorsqu'une nouvelle sélection est obtenue, le patient PAT est informé par le bloc R6 et reçoit des informations actualisées pour son transport.

L'annulation par le patient PAT du transport Mm programmé est effectuée par la voie du bloc R8 ou par la voie d'un bloc R9.

L'annulation par le bloc R8, comme pour un retour du patient PAT décrit plus haut, intervient par la messagerie, l'espace privé ou par un appel à un numéro téléphonique qui aura été indiqué au patient PAT. Le moteur NIA est informé de cette annulation par le patient PAT et en informe le transporteur Tx à travers l'espace privé (bloc R5) de celui-ci.

Le bloc R9 correspond à une annulation qui est requise directement auprès du transporteur Tx par le patient PAT. Le transporteur Tx, lorsqu'il est informé, bloc R9, indique, T9, l'annulation dans son espace privé (bloc R5). Une transmission, T10, est alors effectuée vers le moteur NIA pour informer celui-ci de l'annulation par le patient PAT.

Une demande de modification par le patient PAT, affectant l'information date/heure (DA- DH), est gérée comme une annulation requise par le patient et conduira à une nouvelle sélection en utilisant la nouvelle information date/heure (DA-DH) indiquée par le patient PAT.

L'annulation ou la modification par le prescripteur Pn d'une prescription avec un fichier Mm signé, et donc en cours de régulation, est effectuée à travers l'espace privé du prescripteur Pn. En accédant à son espace privé, le prescripteur Pn a accès à l'ensemble des fichiers M1 à MK, signés ou pas, de ses prescriptions et peut agir sur ceux-ci.

En cas d'annulation, le prescripteur Pn précise de préférence la raison de l'annulation du fichier Mm et valide l'annulation par une signature qui donne lieu à une transmission d'information, T1 , au moteur NIA. Le moteur NIA informe ensuite de l'annulation le transporteur Tx précédemment sélectionné, ou la sélection des transporteurs Tx, Ty et Tz si la sélection n'était pas finalisée. Le patient PAT est également informé à travers le bloc R6 de l'annulation par le prescripteur Pn et de la raison de celle-ci.

En cas de modification, le moteur NIA est également informé par une transmission d'information, T1 , et opère, dans un premier temps, de la même manière que dans le cas d'une annulation. Ensuite, le moteur NIA traite le fichier Mm modifié comme un fichier M nouvellement signé de manière à faire aboutir la sélection d'un transporteur Tx. Une fois la sélection finalisée, le patient PAT est informé à travers le bloc R6.

L'exécution du transport Mm est représentée par le bloc R10.

Lorsque le transport Mm est terminé, la signature SP du patient PAT est entrée, bloc R11 , sur le terminal de véhicule TMV. La signature SP du patient PAT valide la réalisation du transport Mm.

Le transporteur Tx a la possibilité de saisir, bloc R12, des compléments d'information

COT, par exemple, pour expliquer un écart par rapport aux données initiales définissant la mission de transport, tel que par exemple un écart de trajet impactant le kilométrage ou une annulation d'un patient sur un transport partagé. La signature SP et les informations COT sont renseignées dans le fichier de transport Mm pour être prises en compte par le traitement de gestion assuré par le module de gestion GES.

Le module logiciel de gestion GES est maintenant décrit en référence aussi à la Fig.6.

Les fichiers de transport M des transports effectués sont représentés dans le bloc G1 . Le fichier de transport Mm, comprenant l'ensemble des informations décrites plus haut en référence à la Fig.3, est transmis à une fonction de consolidation de chiffrage pour facturation CCF.

La fonction CCF effectue une consolidation du chiffrage en prenant en compte le trajet retenu Trj calculé par le moteur d'intelligence artificielle NIA, un kilométrage réel KM et un temps d'attente TA (Taxi), ainsi que les compléments d'information COT fournis par le transporteur Tx. Le kilométrage réel KM et le temps d'attente TA, bloc G2, sont calculés par la fonction CCF à partir de données de navigation qui ont été enregistrées par le module logiciel de régulation REG pendant le transport Mm.

En cas d'incohérence que la fonction CCF ne puisse résoudre avec les informations disponibles, une demande d'information D_INF est émise vers l'espace privé du transporteur Tx. Une décision définitive est prise sur le chiffrage du coût de transport consolidé CTC après la réception d'une réponse R_INF en provenance du transporteur Tx.

Dans une autre forme de réalisation, le coût de transport consolidé CTC sera uniquement calculé en fonction du trajet Trj le plus court déterminé par le moteur NIA lors du processus de régulation REG et d'un barème fixé par l'organisme d'assurance maladie.

Le coût de transport consolidé CTC et les informations pertinentes, bloc G3, extraites du fichier de transport Mm sont transmis à une fonction d'émission de facture et document EFD qui édite des fichiers FAD comprenant la facture et les documents requis pour le paiement au transporteur Tx. Ces fichiers FAD sont transmis au transporteur Tx sur son espace privé.

Comme montré également à la Fig.6, les données de fichiers de transport M et de coût de transport consolidé CTC sont sauvegardés dans la base de données de gestion BG. Ces données sont utilisées, bloc G4, par les outils d'édition de rapports d'activité RAC, de statistiques OST et d'analyses et prévisions OAR Les outils RAC, OST et OAP peuvent être utilisés, bloc G5, par les prescripteurs P, les centres de soins CdS et les transporteurs T à travers leurs espaces privés respectifs.

Bien entendu, l'invention ne se limite pas aux formes de réalisation qui ont été décrites plus particulièrement ici à titre d'exemple. L'homme du métier, selon les applications de l'invention, pourra apporter différentes modifications et variantes qui entrent dans la portée des revendications ci-annexées.

Claims

REVENDICATIONS

Système intelligent et écoresponsable de transport sanitaire pour la régulation et la gestion d'une pluralité de transports sanitaires de patients (M), comprenant :

- une pluralité de premiers terminaux (TMP, TFP) hébergeant des premières applications logicielles d'utilisateur (AP_PM, AP_PF) pour une pluralité de prescripteurs de transports sanitaires,

- une pluralité de deuxièmes terminaux (TMT, TFT, TMV) hébergeant des deuxièmes applications logicielles d'utilisateur (AP_TM, AP_TF, AP_VE) pour une pluralité de transporteurs,

- au moins un serveur informatique (SP, NS) hébergeant un module logiciel de régulation (REG) desdits transports sanitaires de patients (M) et un module logiciel de gestion et édition de document (GES), et

- un réseau de communication de données (IT, RTM) autorisant des communications de données entre lesdits premiers terminaux (TMP, TFP) et ledit au moins un serveur informatique (SP, NS) et entre lesdits deuxièmes terminaux (TMT, TFT, TMV) et ledit au moins un serveur informatique (SP, NS),

dans lequel lesdits premiers et deuxièmes terminaux (TMP, TFP ; TMT, TFT, TMV) comportent des terminaux mobiles (TMP, TMT, TMV) et lesdits deuxièmes terminaux (TMT, TFT, TMV) comprennent des terminaux embarqués (TMV) comportant des capteurs de géolocalisation (GL) et équipant des véhicules de transport de patients (V), et dans lequel ledit module logiciel de régulation (REG) inclut un moteur d'intelligence artificielle (NIA) qui réalise ladite régulation desdits transports sanitaires (M) en fonction de la géolocalisation (GL) desdits véhicules de transport (V) et d'un coût de transport estimé (CTE) et/ou d'un bilan de pollution estimé (BPE).

Système selon la revendication 1 , caractérisé en ce que ledit moteur d'intelligence artificielle (NIA) réalise ladite régulation desdits transports sanitaires (M) en fonction aussi d'un tour de rôle (TRT) desdits transporteurs (T).

Système selon la revendication 1 ou 2, caractérisé en ce que ledit moteur d'intelligence artificielle (NIA) réalise ladite régulation desdits transports sanitaires (M) en fonction aussi d'adéquations horaires (ADH) entre des heures de transport demandées et des heures d'arrivée estimées desdits véhicules de transport (V).

Système selon la revendication 3, caractérisé en ce que ledit moteur d'intelligence artificielle (NIA) réalise ladite régulation desdits transports sanitaires (M) en fonction aussi d'un état sanitaire (SAN) desdits véhicules de transport (V). Système selon la revendication 3 ou 4, caractérisé en ce que ledit moteur d'intelligence artificielle (NIA) réalise ladite régulation desdits transports sanitaires (M) en fonction aussi d'un niveau d'occupation (NO) et du planning de transport (PLAN) desdits véhicules de transport (V).

Système selon l'une quelconque des revendications 1 à 5, caractérisé en ce que, lors des saisies de prescriptions de transports sanitaires, lesdits prescripteurs (P) saisissent, sur lesdits premiers terminaux (TMP, TFP), des informations comprenant une identification de prescripteur (IDM) et/ou une identification de patient (CDP) et/ou un mode de transport demandé (MTD) et/ou des informations médicales (IM) et/ou des informations de point de départ/point d'arrivée (D-A) et/ou des informations de transport immédiat ou à date ultérieure à préciser (UR/DIF) et/ou des informations de transport en série (TS) .

Système selon l'une quelconque des revendications 1 à 6, caractérisé en ce que lesdits premiers terminaux (TMP, TFP) comprennent des moyens de signature électronique pour recevoir des signatures de prescripteur (SMP).

Système selon l'une quelconque des revendications 1 à 7, caractérisé en ce que lesdits deuxièmes terminaux (TMT, TFT, TMV) comprennent des moyens de signature électronique pour recevoir des signatures de transporteur (ST) et/ou des signatures de patient (SP).

Système selon l'une quelconque des revendications 1 à 8, caractérisé en ce que ledit au moins un serveur informatique (SP, NS) réalise, au moyen dudit module logiciel de gestion et édition de document (GES), des opérations de chiffrage et facturation (CCF) desdits transports sanitaires de patients (M) et des opérations d'émission de factures et/ou de documents (EFD).

10. Système selon la revendication 9, caractérisé en ce que lesdites opérations de chiffrage et facturation (CCF) sont réalisées à partir d'un kilométrage de trajet optimal retenu (Trj) qui a été déterminé par ledit moteur d'intelligence artificielle (NIA).

Système selon l'une quelconque des revendications 1 à 10, caractérisé en ce que ledit au moins un serveur informatique (SP, NS) réalise une sauvegarde (BG) de données relatives auxdits transports sanitaires de patients (M) réalisés et/ou en cours.

12. Système selon la revendication 11 , caractérisé en ce que ledit au moins un serveur informatique (SP, NS) comprend des moyens d'édition de rapports d'activité (RAC), des moyens de calcul statistique (OST) et des moyens d'analyse et prévision (OAP), lesdits moyens exploitant lesdites données sauvegardées et étant accessibles par lesdits prescripteurs (P), lesdits transporteurs (T) et des centre de soins (CdS). 13. Système selon l'une quelconque des revendications 1 à 12, caractérisé en ce que lesdits terminaux embarqués (TMV) comprennent un module de navigation intégré (VAP) qui est piloté par le système (STS) à partir de données de géolocalisation (GL) fournies par ledit capteur de géolocalisation.

14. Système selon la revendication 13, caractérisé en ce que ledit module de navigation intégré (VAP) est également piloté par le système (STS) à partir de données de trafic routier (T RAF).

15. Système selon l'une quelconque des revendications 1 à 14,, caractérisé en ce que lesdits terminaux embarqués (TMV) comprennent des téléphones intelligents (PH) dits « smartphones » et/ou des tablettes informatiques (TAB).

16. Système selon l'une quelconque des revendications 1 à 15, caractérisé en ce que lesdits premiers terminaux (TMP, TFP) comprennent des ordinateurs (ORD), des téléphones intelligents (PH) dits « smartphones » et/ou des tablettes informatiques (TAB).

17. Système selon l'une quelconque des revendications 1 à 16, caractérisé en ce que lesdits deuxièmes terminaux (TMT, TFT, TMV) comprennent des ordinateurs (ORD), des téléphones intelligents (PH) dits « smartphones » et/ou des tablettes informatiques (TAB).

18. Système selon l'une quelconque des revendications 1 à 17, caractérisé en ce que ledit réseau de communication de données comprend le réseau Internet (IT).

19. Système selon l'une quelconque des revendications 1 à 18, caractérisé en ce que ledit réseau de communication de données comprend un réseau cellulaire de téléphonie mobile (RTM).

20. Système selon l'une quelconque des revendications 1 à 19, caractérisé en ce que lesdites communications de données sont établies à travers des liaisons de données hertziennes (L_PH, L_WF) et/ou des liaisons de données filaires (IT).