[go: up one dir, main page]

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

Système intelligent et écoresponsable de transport sanitaire Download PDF

Info

Publication number
WO2017179033A1
WO2017179033A1 PCT/IB2017/054306 IB2017054306W WO2017179033A1 WO 2017179033 A1 WO2017179033 A1 WO 2017179033A1 IB 2017054306 W IB2017054306 W IB 2017054306W WO 2017179033 A1 WO2017179033 A1 WO 2017179033A1
Authority
WO
WIPO (PCT)
Prior art keywords
transport
terminals
tmv
information
regulation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/IB2017/054306
Other languages
English (en)
Inventor
Fadi KOUBA
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to EP17743401.6A priority Critical patent/EP3612993A1/fr
Publication of WO2017179033A1 publication Critical patent/WO2017179033A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"
    • G06Q10/047—Optimisation of routes or paths, e.g. travelling salesman problem
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/101—Collaborative creation, e.g. joint development of products or services

Definitions

  • the invention relates generally to the field of sanitary transport. More particularly, the invention relates to an intelligent and environmentally responsible health transport system of patients.
  • Objective factors may partly explain the increase in health transport expenditures.
  • the aging of populations in developed countries is leading to an increase in medical care that inevitably leads to an increased need for medical transport.
  • older people are more vulnerable to loss of autonomy and have difficulty moving on their own, which leads to more frequent use of medical transport.
  • the increase in the number of patients with chronic diseases who require mass transport is also an influencing factor.
  • the concentration of healthcare provision in large hospital units can lead, especially in rural areas, to greater distance from patients and more transport.
  • the actors of the sanitary transport essentially comprise ambulance services integrated to the centers of care, private companies of ambulances and agreed taxis. Different types of vehicles are used, including ambulances, light commercial vehicles (VSLs) and convention taxis.
  • VSLs light commercial vehicles
  • Health transport services are performed on medical prescription. It is up to the doctor to judge whether or not a patient needs transportation and the type of transportation required. The type of transport will depend on the patient's state of health. If, for example, the patient needs help walking, the doctor will prescribe a conventional taxi or VSL vehicle that has emergency equipment. The ambulance is reserved for the patient who needs to be transported lying down or who needs medical supervision.
  • the prescribing physician whether he or she is working as a freelancer or in a health center, is a key player who needs to be fully informed, empowered and involved for an active collaboration in the good functioning of the sanitary transport.
  • New tools should be developed to this end, in particular to assist the liberal doctor in choosing the most appropriate transport for the situation, and to give him greater visibility on the actual transport carried out compared to an allocated health transport budget, knowing that prescriptions, for various reasons, are not always used by patients.
  • health transport In large health care centers such as hospitals, health transport is usually governed by a service or regulatory platform that manages transport carried out by an internal fleet of ambulances and those carried out using private actors.
  • the traceability of the transport prescription would need to be consolidated. It would be desirable for the transport prescriber to be in all cases a doctor with sufficient knowledge of the medical file.
  • the health centers will have to manage, as well as the liberal doctors, a transport budget allocated by the health insurance organization.
  • the resources available must therefore be optimally usable to avoid budget overruns and expenses that remain the responsibility of the health centers.
  • Reducing the CO2 footprint involves minimizing the mileage traveled and a good match between the means of transport used, in terms of CO2 emissions, and the need for medical transport prescribed by the doctor. If the minimization of the mileage, by an optimum choice of the path of the vehicles, appears relatively easy to set up for transport fleets integrated to the centers of care, by means for example of the internal platform of regulation or devices of navigation by GPS, it is not the same when intervene private actors, such as conventioned taxis, whose billing is related in particular to the mileage traveled.
  • the invention thus relates to an intelligent and eco-responsible health transport system for the regulation and management of a plurality of medical transports of patients, comprising:
  • At least one computer server hosting a software module for regulating the medical transports of patients and a software module for managing and editing documents
  • a data communication network allowing data communications between the first terminals and the at least one computer server and between the second terminals and the at least one computer server, in which the first and second terminals comprise mobile terminals and the second terminals; terminals comprise on-board terminals comprising geolocation sensors and equipping vehicles for transporting patients, and
  • the regulatory software module includes an artificial intelligence engine that regulates the medical transports based on the geolocation of the transport vehicles and an estimated transport cost and / or an estimated pollution budget.
  • the engine of artificial intelligence realizes the regulation of the transports transports also according to a rotation of the carriers.
  • the artificial intelligence engine realizes the regulation of the medical transports also according to hourly adaptations between requested transport times and estimated arrival times of the transport vehicles.
  • the engine of artificial intelligence realizes the regulation of the sanitary transports also according to a state of health of the transport vehicles.
  • the engine of artificial intelligence realizes the regulation of sanitary transports also according to a level of occupation and the transport schedule of the transport vehicles.
  • the prescribers when entering prescriptions for medical transports, enter, on the first terminals, information including a prescriber identification and / or a patient identification and / or a mode of transport requested and / or medical information and / or information point of departure / arrival point and / or immediate or subsequent transport information to be specified and / or serial transport information.
  • the first terminals comprise electronic signature means for receiving prescriber signatures.
  • the second terminals comprise electronic signature means for receiving carrier signatures and / or patient signatures.
  • the at least one computer server carries out, by means of the document management and editing software module, operations for the encryption and billing of the medical transports of patients and the operations of issuing bills and / or documents.
  • the encryption and billing operations are carried out starting from an optimum chosen mileage of journey that has been determined by the engine of artificial intelligence.
  • the at least one computer server performs a backup of data relating to medical transports of patients made and / or in progress.
  • the on-board terminals comprise an integrated navigation module which is controlled by the system from geolocation data provided by the geolocation sensor.
  • the integrated navigation module is also controlled by the system from road traffic data.
  • the on-board terminals include so-called “smartphones” smart phones and / or computer tablets.
  • the first terminals include computers, smart phones known as “smartphones” and / or computer tablets.
  • the second terminals include computers, smart phones known as “smartphones” and / or computer tablets.
  • said data communication network comprises the Internet network.
  • the data communication network comprises a mobile cellular network.
  • the data communications are established through wireless data links and / or wired data links.
  • FIG. 1 shows the various actors participating in the sanitary transport system according to the invention
  • FIG. 2 is a block diagram showing the general architecture of the sanitary transport system according to the invention.
  • FIG. 3 shows the configuration of a transport file used by the data processing performed by the sanitary transport system according to the invention
  • FIGS. 4 and 5 are block diagrams showing the architecture and operation of a control software module included in the sanitary transport system according to the invention.
  • FIG. 6 is a block diagram showing the architecture and the operation of a management software module included in the sanitary transport system according to the invention.
  • the STS sanitary transport system according to the invention is deployed through a communication network such as the IT Internet network.
  • the STS system is located in one or more servers connected to the Internet IT network
  • a main server SP is located in the premises of an operating center of the STS system and is connected to a cloud of servers NS (called “cloud” in English) which allows quick access to the STS system by its different actors.
  • the STS system organizes the exchanges between the various actors so as to allow the good realization of medical transports.
  • the different actors except the patient PAT beneficiary of the transport, were registered beforehand and are therefore known to the STS system.
  • the PAT patient is an insured person from a health insurance organization and is known by an insured number.
  • Medical transports are typically prescribed by prescribing physicians P who are, in general, doctors in liberal practice or doctors practicing in health centers.
  • the terms "health centers” are to be interpreted here in the broadest sense and cover not only HOSP and other hospitals and clinics, but also IAM imaging, medical analysis, dialysis and other centers, as well as medical nursing homes EM, convalescence, rehabilitation and others.
  • transportation is carried out, non-exclusively, between the DOM home of the PAT patient and a care center or care center at a health center. According to the sanitary state of the PAT patient, the prescriber P recommends the mode of transport which seems to him the most adapted.
  • the prescriber P can request ambulance transportation or transport in a seated position that can be provided by a light sanitary vehicle or a taxi agreement.
  • the prescriber P can also authorize a transport with several, said later "shared transport”. It can also prescribe a series of transports, called “mass transport", for several regular care such as dialysis.
  • Transport transports are carried out by T carriers which are typically private companies of ambulances and taxis conventioned.
  • T carriers typically private companies of ambulances and taxis conventioned.
  • V vehicles For medical transport, a fleet of V vehicles is used, including AMB ambulances, VSL light commercial vehicles and TAX taxis.
  • Access to the STS system by the various actors is achieved through fixed or mobile terminals such as an ORD computer, a telephone such as a smartphone smartphone called PH or a tablet computer TAB.
  • the ORD, PH, TAB terminals host dedicated user software applications or allow access through an internet platform with private spaces.
  • FIG. 1 The architecture of the sanitary transport system STS according to the invention is represented generally in FIG.
  • the system STS comprises one or more servers SP, NS, a plurality of fixed terminals and mobile terminals ORD, PH, TAB, and databases BR and BG.
  • the SP, NS servers include a ⁇ processor, RAM and ROM memory, a 1RS network interface and REG regulation and GES management software modules.
  • the processor ⁇ typically a microprocessor, and the RAMs and ROMs operate in a known manner, executing program instructions of software modules performing various operational functions of the STS system. The operation of the software modules
  • the TMP, TMT and TMV terminals are mobile or embedded terminals in the form of TAB tablets or PH smartphones hosting dedicated user software applications AP_PM, AP_TM and AP_VE, respectively.
  • the TFP and TFT terminals are fixed terminals in the form of an ORD computer hosting dedicated user software applications AP_PF and AP_TF, respectively.
  • TP terminals are the ORD computers, PH phones, and TAB tablets used by PAT patients to communicate with the STS system. Access to the STS system is done through the IT Internet network, in a known manner, using a web browser or a specific application on a smartphone or tablet. PAT patients have the option to create private spaces on an STS internet platform in order to communicate with it.
  • the terminals TMP and TFP are the terminals used by the prescribers P.
  • the mobile terminals TMP use the Internet IT network to connect to the servers SP, NS, of the STS system through two types of data link type radio. They thus use either an L_PH data link through an RTM mobile cellular network or an L_WF data link through a BWF terminal of a local WIFI network.
  • the BWF terminal is integrated in an ADSL-type box which is connected to a fixed terminal TFP of the prescriber P.
  • the fixed terminals TFP connect to the servers SP, NS, through the Internet IT network, typically by wire connection, for example, through an ADSL type box.
  • the software applications AP_PM and AP_PF hosted respectively in the mobile terminals TMP and fixed TFP, are designed to allow prescribers P to enter and transmit encrypted prescriptions to the servers SP, NS.
  • These AP_PM and AP_PF software applications incorporate information and support functionalities to guide P prescribers when entering their transport requirements.
  • the AP_PM and AP_PF software applications also include private space look-up functions in which the prescribers P can access their data DPR (database BG). In their private spaces, P prescribers can publish RAC activity reports and optimize their use of an allocated health transport budget using OST statistics and OAP analysis and forecasting tools. Note that P prescribers will be able to also consult their private spaces using an internet browser.
  • TMV terminals are mobile or on-board terminals that are dedicated to vehicle crews.
  • the TMT and TFT terminals allow full access to T carrier accounts and are used by authorized individuals.
  • TMT mobile devices use the IT Internet to connect to SP, NS, STS servers through two types of data links. They thus use either an L_PH data link through an RTM mobile cellular network or an L_WF data link through a BWF terminal of a local WIFI network.
  • the BWF terminal is integrated in an ADSL type box which is connected to a fixed terminal TFT of the carrier T.
  • the fixed terminals TFT connect to the servers SP, NS, through the Internet IT network, typically by wire connection, for example, through an ADSL type box.
  • the AP_TM and AP_TF software applications hosted respectively in the TMT mobile and fixed TFT terminals, are designed to allow the transporters T to interact with the STS system in an encrypted manner.
  • the applications AP_TM and AP_TF thus allow the carriers T to consult, in private spaces, transport missions which are proposed by the STS system after an intelligent selection, to accept or refuse a mission, to cancel a posteriori acceptance mission and exchange information with the STS system and PAT patients to carry out the transport missions.
  • These AP_TM and AP_TF software applications incorporate information and support features to guide T carriers when using the STS system.
  • AP_TM software applications and AP_TF also includes private space lookup features in which the T-carriers can access their DTR data (BG database). In their private spaces, T carriers can view ADF billing, edit RAC activity reports, as well as use OST statistics tools and OAP analysis and forecasting. It will be noted that the carriers T will also be able to consult their private spaces using an internet browser.
  • TMV terminals use the IT internet network to connect to STS servers SP, NS, via an L_PH data link, over a cellular RTM mobile network.
  • STS servers SP, NS via an L_PH data link, over a cellular RTM mobile network.
  • a local WIFI terminal of the vehicle V may be used for the data link between the TMV terminal and the server SP, NS.
  • the AP_VE software application hosted in the AP_VE terminals, is designed to allow the crew of the vehicle V to interact with the STS system and to host an integrated navigation module which is driven by the STS system from data of the vehicle.
  • GL geolocation provided by a TMV terminal (GPS) sensor.
  • the application AP_VE thus allows the vehicle crew V to consult, in their private space, the transport missions that are offered to the vehicle V by the STS system after an intelligent selection, to accept or refuse a mission, to postpone a mission acceptance and exchange information with the STS system and PAT patients to carry out the transport missions.
  • the AP_VE application also includes an electronic signature function to collect the signature of the patient PAT which certifies the carrying out of the transport mission. This signature of the patient can be collected on a touch screen fitted to the TMV terminal.
  • the BR and BG management databases are housed in mass storage units (not shown) of the SP, NS servers.
  • the database BR and BG contain all the data necessary for the operation of the STS system according to the invention, and in particular the operation of the REG and GES software modules.
  • the transporters T and the prescribers P referenced as affiliated with the STS system are known by respective files which are accessible in the databases BR and BG.
  • the file T (V) of a transporter T includes all the information necessary for management and a description for each vehicle V of the carrier's fleet.
  • the description is dynamically updated and indicates the availability or not of the vehicle for a transport mission, the type of vehicle (ambulance, VLS, taxi), the number of places available for patients, the sanitary condition of the vehicle (disinfected or not), GL geolocation of the vehicle, pollutant emissions from the vehicle and others.
  • the file P (CdS) of a prescriber P includes all the information necessary for the management, and in particular his status of liberal practitioner or attachment to a CdS care center and, in the second case, the information relating to the health center CdS.
  • Current transport M files are also available in the BR and BG databases. It should be noted that these files are dynamic and are filled by the STS system as and when the transport missions are processed. In the management database BG are also saved the transport files M carried out.
  • the control database BR also includes GPS geolocation data files that are continuously refreshed with the GL data transmitted by the TMV mobile or onboard vehicle terminal.
  • CART mapping and TRAF road traffic data are also contained in the BR database.
  • CART mapping and TRAF road traffic data are fed into data and updated by external provider services with which the STS system communicates.
  • the management database BG contains, as well as the database BR, the set of prescribing files P (CdS) and transporters T (V), and the transport files M in progress and carried out . These different files are used by the management module for editing invoices and FAD documents that are intended for the health insurance organization.
  • the edited FAD files are kept in the BG database.
  • FIG. 1 An example of an arbitrary transport file Mm used by the STS system is shown in FIG. 1
  • the Mm file includes the following information:
  • IDM is the identifying information of the prescriber P (and the health center to which he is attached, if applicable).
  • the IDM information is pre-filled by the STS system when the prescriber opens a transport prescription file through a TMP terminal, TFP
  • IDP is the identification information of the PAT patient and includes an insured number. This information is provided by the prescriber P.
  • CDP are the patient's PAT coordinates that can be used to join this one. They may include an email address, a phone number, and so on.
  • the CDP coordinates are intended in particular to be given to the carrier T who will take charge of the transport mission. This information is provided by the prescriber P.
  • MTD is the mode of transport requested by the prescriber P.
  • MTD indicates the type of vehicle, namely, an ambulance, a VLS or a taxi, and the possibility of shared transport or not. This information is provided by the prescriber P.
  • IM are medical information indicated by the prescriber P.
  • - DA are the departure and arrival point information provided by the prescriber P.
  • - UR / DIF are the information on when the transport mission is to be carried out.
  • the prescriber P can indicate here whether it is an urgent / immediate transport or a deferred transport whose date and time will be specified later by the patient PAT (for example, once he has obtained a Appointment).
  • - TS is information that indicates whether the requirement relates to mass transport.
  • - T is information that is entered by the STS during the regulation and indicates the carrier selected to perform the transport mission.
  • CDT are the coordinates of the selected carrier T which are filled by the STS system during the regulation and intended in particular to be transmitted to the PAT patient, for example, to inform the carrier T a date / time of transport after making appointments you.
  • - DA-DH are information provided by the STS system during the regulation and specifying the points of departure and arrival and the date and time when the vehicle V recovers the PAT patient.
  • Vt are information provided by the STS system during the regulation and which identify the vehicle selected, its type (ambulance, VSL, Taxi) and a shared mode of transport or not.
  • Map navigation corresponding to the selected route is provided by the STS system through the AP_VE application and a display on the TMV terminal screen. In the event of deviation from the chosen route, the navigation dynamically calculates a new path and provides the STS system, at the end of the transport mission, the mileage traveled effectively.
  • CTE is an estimated financial cost for the transport mission.
  • the cost CTE is calculated by the STS system for the purposes of regulation.
  • the CTE cost is an estimate calculated during the regulation process and may differ from the actual amount invoiced for the transportation mission.
  • BPE is an estimated pollution report, or CO2 footprint, calculated by the STS system for the purpose of regulation.
  • BPE concerns the transport mission considered with the Trj path and the transport mode Vp selected.
  • TOC are additional information provided by the carrier selected at the end of the transport mission.
  • the TOC information will include the names of the paramedics. They may also include, for example, information to explain a deviation from the initial data defining the transport mission, such as for example a path deviation impacting mileage or a cancellation of a patient on a shared transport.
  • TOC information is used by the GES management module for controlling and consolidating billing.
  • CTCs are billing information that includes a consolidated transport cost that is calculated by the STS GES management module. The calculation is based on the trip / mileage information Trj, consolidated after checking with the additional information TOC provided by the carrier, and possible waiting times (Taxi) determined from the geolocation data GL.
  • SMP, ST and SP are electronic signature data of the prescriber P, transporter T and patient PAT.
  • a set of N specifiers and a set of R carriers are affiliated and referenced in the STS system.
  • the REG module has access to all the prescriber files P (CdS) and transporter T (V).
  • the block R1 represents the set of transport files M which are being processed by the REG module and which correspond to prescriptions by prescribers, P1 to PN.
  • the transport file Mm is created by the module REG at the opening by the prescriber Pn of the corresponding prescription, using its terminal TMP, TFP.
  • the file Mm is included in a set of files M1 to MK corresponding to all the prescriptions currently being processed for the prescriber Pn.
  • the set of files M1 to MK are accessible to the prescriber Pn through a private area thereof.
  • the prescriber Pn informs the file Mm with a group of information GP1 (Fig.3) grouping the information IDM TS.
  • the prescriber Pn has the possibility to go back to make corrections and it also has the possibility to cancel the file Mm during data entry.
  • the file Mm is not signed by the prescriber Pn, it remains in the draft state and can be resumed and modified at will by the prescriber Pn.
  • the file Mm signed by the prescriber Pn it is transmitted, T1, with the SMP signature of the prescriber, to an artificial intelligence software engine NIA such as an inference engine.
  • Block R2 represents the set of carrier files T (V) 1 to T (V) R corresponding to carriers T1 to TR.
  • a carrier file T (V) t any corresponding to a carrier Tt having a number Z of vehicles which are identified Vt1 to VtZ.
  • the carrier file T (V) t comprises, for each of the Z vehicles, an information group GT1, shown in FIG. 5, which comprises the identification of the vehicle with its type ( Ambulance, VSL, Taxi), Vt1 to VtZ, status information associated with the vehicle, E1 to EZ, and vehicle-related geolocation, GL1 to GLZ.
  • the state information E associated with a vehicle includes sanitary status information SAN (vehicle disinfected or not), occupancy level information NO (number of places available), information PLAN of the planning of the future transports assigned to the vehicle, information of polluting discharges (CO2) of the vehicle and information VAP of version of the software application AP_VE for piloting navigation of the vehicle.
  • sanitary status information SAN vehicle disinfected or not
  • occupancy level information NO number of places available
  • CO2 polluting discharges
  • VAP version of the software application AP_VE for piloting navigation of the vehicle.
  • the set of carrier files T (V) 1 to T (V) R is accessible, T2 (Fig.4), by the artificial intelligence engine NIA.
  • the NIA engine makes a selection S_Mm of vehicles representing the best coincidences obtained in the transporter files T (V) for the transport file Mm corresponding to the prescription.
  • the NIA engine determines a CS selection criteria group that is used for selection.
  • the engine NIA calculates an optimal path Trj for an initial set of pre-selected vehicles on a match between the vehicle type Vt, its availability (SAN, NO, PLAN) and the transport prescription.
  • the optimal route Trj is determined not only by the distance kilometer from the departure and arrival points D-A and the geolocation GL of the vehicle, but also by taking into account an estimated BPE pollution budget for each of the routes envisaged.
  • the pollutant release information CPOL of the vehicles will be used for the calculation of the estimated pollution balance BPE.
  • the number of road junctions, TRAF traffic information and other information, such as vehicle taxi bans in polluted areas, may be taken into account by the NIA engine to determine the optimal path Trj.
  • the CS selection criteria group includes the following criteria:
  • TRT which represents a turnaround priority associated with the transporter T.
  • Weightings P1 to P4 are respectively associated with the criteria CTE, BPE, ADH and TRT.
  • the selection S_Mm is obtained from the best coincidences on the satisfaction of the weighted criteria. It should be noted that the weights P1 to P4 are determined dynamically by the artificial intelligence engine NIA. The learning of the NIA artificial intelligence engine comes during an initial phase of experimentation and development of the STS system.
  • the engine NIA provides a selection S_Mm composed of three vehicle selections S1, S2 and S3.
  • the selections S1, S2 and S3 relate to vehicles Vtx, Vty and Vtz of transporters Tx, Ty and Ty for Trjx, Trjy and Trjz paths, respectively.
  • Coincidence level indicators Cx, Cy and Cz are also associated with the selections S1, S2 and S3, respectively.
  • the selections S1 (Tx, Vtx), S2 (Ty, Vty) and S3 (Tz, Vtz) are transmitted, T3, by the NIA engine to the private areas of the carriers concerned, Tx, Ty and Tz, and these receive through their terminals TMT, TFT and TMV information to signal the arrival of transport mission offers.
  • coincidence level indicators Cx, Cy and Cz which are not of interest to carriers, are not displayed in private spaces.
  • the NIA engine manages information, including sensitive information such as insured numbers, names of prescribing doctors, etc., so that the different actors have access only to information that their are necessary and authorized by the regulations.
  • An AT mission assignment function of the NIA motor then selects the selection, S1 or S3, having the highest coincidence level, Cx or Cz.
  • the coincidence levels Cx, Cz, are provided, T6, to the AT mission assignment function.
  • the carrier Tx has confirmed its acceptance X of the transport Mm, which corresponds to a final signature ST, the information relating to the transport Mm is transmitted to it, T7, by the function of assignment of mission AT transport, in its private area.
  • the vehicle selected Vtx and the selected route Trj it is also transmitted all the information useful for carrying out the transport and in particular the DA-DH information of departure and arrival points and date / time, as well as the CDP coordinates of the PAT patient.
  • the carriers Ty and Tz not retained by the NIA engine for the transport Mm are informed by a transmission of information, T1, in their respective private spaces.
  • the block R6 represents a communication to the patient PAT which is transmitted, T8, by the AT mission assignment function to the terminals TP thereof. For example, by an SMS message to his PH phone, an email to his mailbox and / or a communication in his private area if he has created one.
  • the patient PAT receives all the necessary information which identifies the transport Mm, the transporter Tx with its coordinates CDT, and the date / time (DA-DH) of the departure.
  • the processing performed by the NIA engine differs from that just described. Indeed, the selection made by the NIA engine is made individually for each of the transports of the series.
  • the identification of a serial transport by the NIA engine follows the transmission, T1, of the transport file Mm NIA engine.
  • the NIA engine then transmits information to the patient PAT block R7, asking him to communicate the DA-DH information for each transport. This information is transmitted to the patient PAT, for example, by an SMS message to his PH phone, an email to his mailbox and / or a communication in his private area if it was created at his initiative.
  • the return of the patient PAT block R8, for example after a medical appointment, can intervene by messaging, private space or by a call to a telephone number which has been indicated to the PAT patient.
  • the transport file Mm is filled in and is then processed by the engine NIA to select a transporter T, as described in the paragraphs above.
  • the same carrier may be selected by the NIA engine to perform all of the serial transport since the artificial intelligence believes that favorable proximity conditions are met after taking into account historical geolocation of carriers' vehicles.
  • the STS system is optimized for a late selection of the transporter T, in order to benefit fully from the real-time geolocation of the vehicles which allows more efficient selections.
  • an earlier selection of the T-carrier is also possible and will in this case be based more on the vehicle transport planning PLAN (Fig.5).
  • Cancellations / changes to transports are handled by the NIA engine as described below.
  • the cancellation by the patient PAT of the programmed transport Mm is carried out by way of the block R8 or by way of a block R9.
  • the NIA engine is informed of this cancellation by the patient PAT and informs the carrier Tx through the private area (block R5) thereof.
  • Block R9 corresponds to a cancellation that is required directly from the Tx carrier by the patient PAT.
  • the Tx carrier when informed, block R9, indicates, T9, the cancellation in its private space (block R5).
  • a transmission, T10, is then made to the NIA engine to inform it of the cancellation by the PAT patient.
  • a change request by the PAT patient, affecting the date / time information (DA-DH), is handled as a cancellation required by the patient and will lead to a new selection using the new date / time information (DA-DH) indicated by the PAT patient.
  • the cancellation or modification by the Pn prescriber of a prescription with a signed Mm file, and therefore being regulated, is carried out through the private area of the Pn prescriber.
  • the Pn prescriber By accessing its private area, the Pn prescriber has access to all the files M1 to MK, signed or not, its prescriptions and can act on them.
  • the prescriber Pn preferably specifies the reason for the cancellation of the file Mm and validates the cancellation by a signature which gives rise to an information transmission, T1, to the engine NIA.
  • the NIA engine then informs the cancellation of the previously selected Tx carrier, or the selection of the Tx, Ty and Tz carriers if the selection was not finalized.
  • the patient PAT is also informed through block R6 of the cancellation by the prescriber Pn and the reason for it.
  • the NIA engine is also informed by an information transmission, T1, and operates, initially, in the same way as in the case of a cancellation. Then, the NIA engine treats the modified Mm file as a newly signed M file in order to complete the selection of a Tx carrier. Once the selection is finalized, the PAT patient is informed through block R6.
  • the execution of the transport Mm is represented by the block R10.
  • the signature SP of the patient PAT is entered, block R11, on the vehicle terminal TMV.
  • the signature SP of the patient PAT validates the realization of the transport Mm.
  • the Tx carrier has the possibility to enter, block R12, additional information
  • TOC for example, to explain a deviation from the initial data defining the transport mission, such as, for example, a trip deviation impacting the mileage or a cancellation of a patient on a shared transport.
  • the signature SP and the TOC information are entered in the transport file Mm to be taken into account by the management process provided by the management module GES.
  • the GES management software module is now described with reference also to FIG.
  • Transport files transport M performed are represented in block G1.
  • the transport file Mm comprising all the information described above with reference to FIG. 3, is transmitted to an encryption consolidation function for CCF billing.
  • the CCF performs a consolidation of the encryption taking into account the chosen path Trj calculated by the artificial intelligence engine NIA, a mileage KM and a waiting time TA (Taxi), as well as the supplementary information TOC provided by the Tx carrier.
  • the actual mileage KM and the waiting time TA, block G2 are calculated by the function CCF from navigation data that were recorded by the regulation software module REG during the transport Mm.
  • a D_INF information request is sent to the private space of the Tx carrier.
  • a final decision is made on the costing of the CTC consolidated transport cost after receipt of a R_INF response from the Tx carrier.
  • the consolidated transport cost CTC will only be calculated based on the shortest path Trj determined by the engine NIA during the regulation process REG and a scale set by the health insurance body.
  • the consolidated transport cost CTC and the relevant information, block G3, extracted from the transport file Mm are transmitted to an invoice issuing function and EFD document which edits FAD files including the invoice and the documents required for payment to the carrier. Tx. These FAD files are transmitted to the Tx carrier on its private area.
  • transport file data M and consolidated transport cost CTC are saved in the management database BG.
  • These data are used, block G4, by the tools of publication of reports of activity RAC, OST statistics and analyzes and forecasts OAR
  • the tools RAC, OST and OAP can be used, block G5, by the prescribers P, CdS care centers and T carriers through their respective private spaces.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Health & Medical Sciences (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Biomedical Technology (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Primary Health Care (AREA)
  • Tourism & Hospitality (AREA)
  • Marketing (AREA)
  • General Health & Medical Sciences (AREA)
  • General Physics & Mathematics (AREA)
  • Operations Research (AREA)
  • Game Theory and Decision Science (AREA)
  • Development Economics (AREA)
  • Epidemiology (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Medical Informatics (AREA)
  • Quality & Reliability (AREA)
  • Public Health (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

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).
PCT/IB2017/054306 2017-04-20 2017-07-17 Système intelligent et écoresponsable de transport sanitaire Ceased WO2017179033A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP17743401.6A EP3612993A1 (fr) 2017-04-20 2017-07-17 Système intelligent et écoresponsable de transport sanitaire

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR17/70402 2017-04-20
FR1770402 2017-04-20

Publications (1)

Publication Number Publication Date
WO2017179033A1 true WO2017179033A1 (fr) 2017-10-19

Family

ID=59153202

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2017/054306 Ceased WO2017179033A1 (fr) 2017-04-20 2017-07-17 Système intelligent et écoresponsable de transport sanitaire

Country Status (2)

Country Link
EP (1) EP3612993A1 (fr)
WO (1) WO2017179033A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130185221A1 (en) * 2012-01-13 2013-07-18 Steve Adams Compliance System for Reducing Fraud in the Provision of Non-emergency Medical Transportation Services
US20130204633A1 (en) * 2012-01-17 2013-08-08 Steve Jourdan System and methods for providing transportation services in health care facilities
US20140301537A1 (en) * 2001-08-02 2014-10-09 American Medical Response System and method for managing requests for medical transportation
US20150046187A1 (en) * 2013-08-08 2015-02-12 Tcn Technologies, Llc Clinical trial participant transportation system
US20160019473A1 (en) * 2014-07-18 2016-01-21 Otitopic Inc. Arranging transport amongst parties through use of mobile devices

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140301537A1 (en) * 2001-08-02 2014-10-09 American Medical Response System and method for managing requests for medical transportation
US20130185221A1 (en) * 2012-01-13 2013-07-18 Steve Adams Compliance System for Reducing Fraud in the Provision of Non-emergency Medical Transportation Services
US20130204633A1 (en) * 2012-01-17 2013-08-08 Steve Jourdan System and methods for providing transportation services in health care facilities
US20150046187A1 (en) * 2013-08-08 2015-02-12 Tcn Technologies, Llc Clinical trial participant transportation system
US20160019473A1 (en) * 2014-07-18 2016-01-21 Otitopic Inc. Arranging transport amongst parties through use of mobile devices

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Taille et type d'écran PLUS INTELLIGENT ET PLUS RAPIDE QUE JAMAIS", 30 September 2016 (2016-09-30), pages 1 - 2, XP055398365, Retrieved from the Internet <URL:http://medias1-6.ubaldi.com/auto-moto-gps/gps-navigation/gps/tomtom/gps-auto-tomtom--go-6200--620286.pdf> [retrieved on 20170811] *

Also Published As

Publication number Publication date
EP3612993A1 (fr) 2020-02-26

Similar Documents

Publication Publication Date Title
US10616362B2 (en) System and method for a convertible user application
US20230230121A1 (en) Data processing system with machine learning engine to provide output generation functions
US10497015B2 (en) Method and system for avoidance of parking violations
US9997071B2 (en) Method and system for avoidance of parking violations
US10671961B2 (en) Systems and methods for transportation
US20190392509A1 (en) Device and method for implementing a vehicle sharing reward program
US20160364823A1 (en) Systems and methods for on-demand transportation
US20160364679A1 (en) Systems and methods for on-demand transportation
US20160364812A1 (en) Systems and methods for on-demand transportation
US20170169366A1 (en) Systems and Methods for Adjusting Ride-Sharing Schedules and Routes
US20120131170A1 (en) System and method for fulfilling requests using a mobile device
EP3411836A1 (fr) Procédé et système de services personnalisés à la demande
WO2017028821A1 (fr) Procédé et système permettant de prédire des informations de commande actuelle sur la base d&#39;une commande historique
US11836748B2 (en) System and methods for predicting rental vehicle use preferences
EP1519288A1 (fr) Systeme et procede de covoiturage et dispositif de communication pour la mise en oeuvre du procede
FR2924509A1 (fr) &#34;procede et systeme permettant de mettre un vehicule public individuel a la disposition d&#39;un utilisateur&#34;
JP2014190952A (ja) ナビゲーションシステム、ナビゲーション方法、及びナビゲーションプログラム
FR3047102A1 (fr) Procede de detection de passagers, de gestion et d&#39;optimisation de leurs transports partages
FR3104296A1 (fr) Système de determination de produit optimisé
US20240265467A1 (en) SYSTEMS AND METHODS for GENERATING SUBSCRIPTION-BASED INSURANCE POLICIES WITH PREDESIGNATED COVERAGE AMOUNTS
KR102036902B1 (ko) 사용자 맞춤형 건강검진 서비스 제공 시스템 및 그 제어 방법
WO2018057817A1 (fr) Plateforme de réservation sociale pour système de location de véhicule sans retour
WO2017179033A1 (fr) Système intelligent et écoresponsable de transport sanitaire
Li et al. MaaS system development and APPs
JP2009104365A (ja) センシングデータの配信方法、センサネットシステム及び広告配信装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17743401

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017743401

Country of ref document: EP

Effective date: 20191120