WO2020011244A1 - 一种急危重症施救的医疗资源优化匹配方法和系统 - Google Patents

一种急危重症施救的医疗资源优化匹配方法和系统 Download PDF

Info

Publication number
WO2020011244A1
WO2020011244A1 PCT/CN2019/095722 CN2019095722W WO2020011244A1 WO 2020011244 A1 WO2020011244 A1 WO 2020011244A1 CN 2019095722 W CN2019095722 W CN 2019095722W WO 2020011244 A1 WO2020011244 A1 WO 2020011244A1
Authority
WO
WIPO (PCT)
Prior art keywords
critically ill
emergency
condition
information
patient
Prior art date
Application number
PCT/CN2019/095722
Other languages
English (en)
French (fr)
Inventor
高强
Original Assignee
飞救医疗科技（北京）有限公司
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 飞救医疗科技（北京）有限公司 filed Critical 飞救医疗科技（北京）有限公司
Publication of WO2020011244A1 publication Critical patent/WO2020011244A1/zh

Links

Images

Classifications

    • 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/20—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 management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
    • 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
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/20—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for computer-aided diagnosis, e.g. based on medical expert systems

Definitions

  • the present application relates to the field of medical intelligence technology, and in particular, to a method and system for optimizing and matching medical resources for emergency and critical care.
  • the application provides a method and system for optimizing and matching medical resources for emergency and critical care, which solves the problems of multiple disciplines, long processes, and low efficiency of the existing emergency medical system, and can provide medical resources that are reasonably adapted to the symptoms and realize The optimal dispatch of emergency resources, the optimal matching of medical resources, and the timeliness, fairness, and rationality of emergency medical services.
  • a first aspect of the present application provides a method for optimizing and matching medical resources for emergency and critical care.
  • the method for optimizing and matching medical resources for critically ill patients is implemented on a machine including at least one processor and at least one storage device, including: receiving a call for help for a critically ill patient; and collecting Related information; preliminary judgment of the condition of the critically ill patient according to the relevant information of the critically ill patient; matching the best emergency medical resources according to the preliminary judgment of the condition of the critically ill patient; Jia emergency medical resources arrived at the first scene where the critically ill patient was located.
  • the method for optimizing and matching medical resources for emergency and critical care further comprises: establishing a communication group of the best emergency medical resources.
  • the method for optimizing and matching medical resources for critically ill patients further includes: on-site inspection of the best emergency medical resources or / and rescue of the critically ill patients, and obtaining first aid information; and The first aid information updates a preliminary judgment result of the critically ill patient.
  • the method for optimizing and matching medical resources for critically ill patients further comprises: updating the matching emergency medical resources according to the updated medical condition results of the critically ill patients. Hospital resources.
  • the method for optimizing and matching medical resources for critically ill patients further includes: monitoring the condition of the critically ill patients in real time on the way to the matching hospital resources, and continuously updating the emergency information; and Based on the first aid information, an abnormal situation is warned.
  • the method for optimizing and matching medical resources for emergency treatment of the critically ill patients further includes: planning an optimal path for travelling by the best emergency medical resources according to road-related information data.
  • the best path includes the best path for the best first aid resource to reach the first site where the critically ill patient is located, and the best path for the best first aid medical resource to reach the hospital resource.
  • planning the best route for the best first aid medical resource according to road-related information data includes: planning the best first aid medical resource based on the estimated travel time of the road section of the first aid medical resource. The best path to drive.
  • the preliminary judgment of the condition of the critically ill patient according to the related information includes: extracting a keyword of related information of the critically ill patient; matching at least one of the keywords according to the keyword A disease; matching at least one disease according to the keyword; and initially determining a suspected disease of the critically ill patient based on the at least one disease or / and the at least one disease.
  • the preliminary judgment of the medical condition of the critically ill patient according to the related information includes: finding medical records, signs and / or symptoms of the critically ill patient; and according to the medical record , Symptom and / or condition information, to initially determine the suspected condition of the critically ill patient.
  • the preliminary judgment of the condition of the critically ill patient according to the relevant information includes: obtaining relevant information of the critically ill patient; and determining the based on a trained preliminary judgment model of the condition Results of preliminary judgment of critically ill patients.
  • the method for optimizing and matching medical resources for emergency and critical care further includes: determining whether the result of the preliminary judgment of the condition or the updated medical condition of the critically ill patient is standardized with the rescue procedure. Comply with real-time alarms to achieve quality control.
  • the second aspect of the present application provides a system for optimizing and matching medical resources for emergency treatment.
  • the system for optimizing and matching medical resources for critically ill patients includes: a request receiving module for receiving a call for help for a critically ill patient; an information acquisition module for collecting relevant information of the critically ill patient; condition A determination module for initial judgment of the condition of the critically ill patient according to the relevant information of the critically ill patient; a resource matching module for matching the best first aid according to the result of the primary judgment of the critically ill patient Medical resources; and a resource scheduling module, used to designate the best emergency medical resources to reach the first site where the critically ill patient is located.
  • the information collection module is further configured to: obtain on-site inspection or / and rescue the critically ill patient based on the best emergency medical resources to obtain emergency information.
  • the disease determination module is further configured to: update the preliminary judgment result of the critically ill patient according to the first aid information.
  • the resource matching module is further configured to update a hospital resource in the matched best emergency medical resources according to the updated condition result of the critically ill patient.
  • the system for optimizing and matching medical resources for critically ill patients further includes: a real-time monitoring and early warning module for real-time monitoring of the condition of the critically ill patients on the way to the matching hospital resources, And continuously update the first aid information; and based on the first aid information, early warning of abnormal conditions.
  • the resource scheduling module is further configured to: according to road-related information data, plan an optimal path for travel of the best emergency medical resource; the optimal path includes the optimal emergency resource reaching the The best path for the first scene where the critically ill patient is located, and the best path for the best emergency medical resource to reach the hospital resource.
  • the resource scheduling module is further configured to: based on the estimated travel time of the emergency medical resources, plan the best path for travel of the best emergency medical resources.
  • the disease determination module is further configured to: extract a keyword related to the critically ill patient; match at least one symptom according to the keyword; match at least one symptom according to the keyword And based on the at least one condition, making a preliminary determination of the suspected condition of the critically ill patient.
  • the disease determination module is further configured to: find medical records, symptoms, and / or illness information of the critically ill patient; and make a preliminary determination of the emergency according to the medical records, symptoms, and / or illness information Suspected condition in critically ill patients.
  • condition determination module is further configured to: obtain relevant information of the critically ill patient; and determine a preliminary condition of the critically ill patient based on a trained initial condition judgment model.
  • the system for optimizing and matching medical resources for emergency treatment of critically ill patients further includes: a quality control module for judging the result of the preliminary judgment of the condition or the updated condition of the critically ill patient If the result is consistent with the rescue process specification, a real-time alarm is performed to achieve quality control.
  • a third aspect of the present application provides a device for optimally matching medical resources for emergency treatment.
  • the device for optimally matching medical resources for critically ill patients includes at least one storage medium and at least one processor, characterized in that the at least one storage medium is used to store computer instructions; the at least one processor is used to execute all The method of computer instructions to realize the optimal matching of medical resources for emergency treatment is described.
  • a fourth aspect of the present application provides a computer-readable storage medium.
  • the storage medium stores computer instructions, and when the computer instructions are executed by a computer, a method for optimizing and matching medical resources for emergency and critical care is realized.
  • FIG. 1 is an application scenario diagram of a medical resource optimization and matching system for emergency and critical care according to some embodiments of the present application;
  • FIG. 2 is a structural diagram of a medical resource optimization and matching system for emergency and critical care according to some embodiments of the present application
  • FIG. 3 is a schematic diagram of a medical resource optimization and matching system for emergency treatment according to some embodiments of the present application.
  • FIG. 4 is a schematic diagram of an exemplary computing device according to some embodiments of the present application.
  • FIG. 5 is a block diagram of a medical resource optimization and matching system for emergency treatment in accordance with some embodiments of the present application.
  • FIG. 6 is an exemplary flowchart of a method for optimizing and matching medical resources for emergency treatment in accordance with some embodiments of the present application.
  • FIG. 7 is an exemplary flowchart of a method for preliminary diagnosis of a critically ill patient according to some embodiments of the present application.
  • FIG. 8 is an exemplary flowchart of another method for optimizing and matching medical resources for rescue of critically ill patients according to some embodiments of the present application.
  • system means for distinguishing different components, elements, parts, parts or assemblies at different levels.
  • apparatus means for distinguishing different components, elements, parts, parts or assemblies at different levels.
  • the words may be replaced by other expressions.
  • a flowchart is used in the present application to explain the operations performed by the system according to the embodiment of the present application. It should be understood that the preceding or following operations are not necessarily performed precisely in sequence. Instead, the steps can be processed in reverse order or simultaneously. At the same time, other operations can be added to or removed from these processes.
  • FIG. 1 is a diagram illustrating an application scenario of a medical resource optimization and matching system for emergency treatment of critically ill patients according to some embodiments of the present application.
  • the medical resource optimization and matching system 100 for emergency and critical care can be provided in various emergency centers to provide medical resources that are reasonably adapted to symptoms for callers.
  • the system may include an emergency medical resource terminal 110, a network 120, a call for help information terminal 130, a server 140, a storage device 150, and a hospital resource terminal 160.
  • the server 140 and the storage device 150 may be combined and referred to as a rescue cloud platform.
  • the urgent resource terminal 110 may be used to provide emergency medical resources.
  • Emergency medical resources include, but are not limited to, special emergency medical equipment (including nuclear magnetic resonance, CT (Computed Tomography, electronic computed tomography), B-mode ambulances or helicopters, etc.), conventional emergency medical equipment or systems, medicines, medical personnel, hospital resources Wait.
  • hospital resources can refer to hospitals with the ability to receive emergency patients, such as emergency hospitals and general hospitals. For more details about emergency medical resources, please refer to FIG. 6 and related descriptions, which will not be repeated here.
  • the network 120 connects various components of the system so that the components can communicate with each other.
  • the network between the parts in the system can be any one or more of a wired network or a wireless network.
  • the network 120 may include a cable network, a wired network, a fiber optic network, a telecommunications network, an internal network, the Internet, a local area network (LAN), a wide area network (WAN), a wireless local area network (WLAN), a metropolitan area network (MAN), public Switched telephone network (PSTN), Bluetooth network, ZigBee network, near field communication (NFC), in-device bus, in-device line, cable connection, etc. or any combination thereof.
  • the network connection between each two parts can be in one of the above ways, or in multiple ways.
  • the call information terminal 130, the emergency medical resource terminal 110, and the hospital resource terminal 160 may communicate with the emergency cloud platform 210 (including the server 140 and the storage device 150) through the network 120 (such as a wireless network).
  • the network 120 such as a wireless network.
  • the traffic data platform is only used as a data source to provide real-time road conditions, not as a part of the system.
  • the emergency medical route is continuously optimized to ensure the efficiency of medical resources matching and scheduling and medical service efficiency.
  • the call-for-help information terminal 130 may be related information for receiving a critically ill patient who has a call for help, such as a telephone station, a computer, a smart phone, a vehicle-mounted terminal device, etc. of a call center.
  • a call for help may come from one or more callers for help.
  • the call for help can be the critically ill patients who directly use the service, or it can be other people who assist the critically ill patients to call for help, such as family members, passers-by, etc. of the critically ill patients.
  • the call for help information terminal 130 may be various types of devices with communication functions, and the communication functions include, but are not limited to, making a call, receiving and / or sending information, and the like.
  • the call for help terminal 130 may be a device with a positioning function.
  • Specific positioning function technology can be based on Global Positioning System (GPS), Global Navigation Satellite System (GLONASS), Beidou Satellite Navigation System (COMPASS), Galileo Satellite Positioning System, Quasi-Zenith Satellite System (QZSS), Wireless Fidelity (WiFi) Positioning technology, etc., or any combination thereof.
  • GPS Global Positioning System
  • GLONASS Global Navigation Satellite System
  • COMPASS Beidou Satellite Navigation System
  • Galileo Satellite Positioning System Galileo Satellite Positioning System
  • Quasi-Zenith Satellite System QZSS
  • WiFi Wireless Fidelity
  • Positioning can provide location-related information.
  • the position-related information may include the position, height, speed or acceleration of the object, the current time, and the like.
  • the system 100 may also include other devices having a positioning function, and such devices may communicate with other devices to determine other device locations.
  • the server 140 may process data and / or information from at least one component of the system or an external data source (eg, a cloud data center).
  • the server 110 may be a single server or a computing platform composed of multiple servers.
  • the multiple servers may be centralized or distributed, may be dedicated, or may be provided by other devices or systems. Services are also provided.
  • the server may be implemented on a cloud platform.
  • the cloud platform may include a private cloud, a public cloud, a hybrid cloud, a community cloud, a distribution cloud, an internal cloud, a multi-layer cloud, or the like, or any combination thereof.
  • the server 140 may include an intelligent engine and emergency dispatch functions.
  • intelligent engine and emergency rescue scheduling please refer to FIG. 5 and related descriptions, which will not be repeated here.
  • the storage device 150 may store data and / or instructions.
  • the storage device 150 may include one or more storage components, and each storage component may be an independent device or a part of other devices.
  • the storage device may include mass storage, removable storage, volatile read-write memory, read-only memory (ROM), etc., or any combination thereof.
  • the storage device 150 may be implemented on a cloud platform.
  • the storage device 150 may store various information libraries.
  • the information database includes, but is not limited to, a disease database for storing a variety of symptoms, a medical record database for storing electronic medical records of historical conditions, and a knowledge database for storing various types of knowledge required for the first aid process.
  • various types of knowledge include, but are not limited to, rules for matching medical resources, norms for rescue procedures and abnormal monitoring criteria, rules for rescue procedures, and rules for system management operations.
  • the information base further includes a medical resource base for storing information on dispatchable emergency medical resources and hospital resources.
  • the medical resource library stores information of medical resources that can be scheduled, for example, information about doctors with emergency medical skills, information about ambulances, information about helicopters, and so on.
  • the storage device 150 may store patient information data, first aid data, best first aid matching resource data, dispatch data and group information data, and continuously updated data of the several types of data.
  • the storage methods of the several types of data may be in the form of a data table or other forms, which are not limited in this application.
  • the hospital resource terminal 160 may provide hospital resources based on the condition of the critically ill patient.
  • Hospital resources can include emergency hospitals or public hospitals, such as hospitals, county hospitals, municipal hospitals, and provincial hospitals. They can also include doctor information, equipment information, and location information for each hospital. For example, when the initial diagnosis of a critically ill patient is heart disease, information on a list of hospitals capable of treating heart disease, doctor information, and equipment information is provided.
  • the hospital resource terminal 160 may receive data transmitted by the emergency cloud platform, for example, patient information data, first aid data, etc.
  • the emergency doctor at the hospital resource terminal 160 may prepare for first aid according to the data, or provide on-site rescue measures Suggest.
  • the server 140 may process the data and / or information obtained from the emergency medical resource terminal 110, the call for help information terminal 302, the server 140, the storage device 150, and the hospital resource terminal 160, and analyze the data and / or information. Perform processing or control other equipment in the system based on these data, information and / or processing results.
  • the intelligent engine first according to the illness database, medical record database of the storage device 150 of the emergency cloud platform and The call-for-help interactive information is calculated and matched to output the intelligent match result and suggestion of the illness.
  • the emergency cloud platform 210 outputs the smart match result and suggestion of the illness to the call-for-help information terminal 130 for providing to the patient.
  • the emergency dispatch of the emergency cloud platform 210 matches the best medical resources from the medical resource database according to the matching rules preset in the knowledge base of the storage device 150, and calculates the best traffic from the real-time road conditions obtained by the traffic data platform. Route, perform dispatch, and send scheduling information and intelligent suggestions to the emergency medical resource terminal 110.
  • the device status and patient data are returned to the emergency cloud platform 210.
  • the emergency resource terminal 110 here includes an online collaborative treatment group established through a network.
  • the examination data of the patient's condition at the first site and the diagnostic information of the collaborative working group on the condition are uploaded to the emergency cloud platform 210 through the group information table, the disease information data table and the emergency data table are updated, and the reasoning of the condition based on the intelligent engine is inferred The second judgment rematched the treatment hospital.
  • the first aid resource terminal 110 sends the first aid data to the skill-matched doctors in the treatment hospital terminal 160 through the online collaborative treatment work group, thereby obtaining treatment recommendations, and achieving remote consultation at the first site and obtaining the hospital The beneficial effects of treatment recommendations.
  • the emergency cloud platform 210 While the patient is being transferred to the treatment hospital for rescue, the emergency cloud platform 210 also sends emergency data to the treatment hospital resource terminal 160, and the treatment hospital terminal 160 returns to the resource state. For example, special emergency equipment has reached the resource status information of the treatment hospital, which facilitates the emergency cloud platform 210 to monitor the status and quality control of the emergency medical resources, thereby improving the quality controllability of the rescue process and preventing the emergence of abnormal conditions.
  • FIG. 4 is a schematic diagram of an exemplary computing device according to some embodiments of the present application.
  • the computing device 400 may include a processor 420, a read-only memory 430, a random access memory 440, a communication port 450, an input / output interface 460, and a hard disk 470.
  • the processor 420 may execute calculation instructions (program code) and perform the functions of determining the recommended pick-up point system 100 described in this application.
  • the calculation instructions may include programs, objects, components, data structures, procedures, modules, and functions (the functions refer to specific functions described in this application).
  • the processor 420 may process image or text data obtained from any other component of the recommended pick-up point system 100.
  • the processor 420 may include a microcontroller, a microprocessor, a reduced instruction set computer (RISC), an application specific integrated circuit (ASIC), an application specific instruction set processor (ASIP), a central processing unit (CPU) , Graphics processing unit (GPU), physical processing unit (PPU), microcontroller unit, digital signal processor (DSP), field programmable gate array (FPGA), advanced RISC machine (ARM), programmable logic device, and capable of Any circuit, processor, etc., or any combination thereof that performs one or more functions.
  • RISC reduced instruction set computer
  • ASIC application specific integrated circuit
  • ASIP application specific instruction set processor
  • CPU central processing unit
  • GPU Graphics processing unit
  • PPU physical processing unit
  • DSP digital signal processor
  • FPGA field programmable gate array
  • ARM advanced RISC machine
  • the memory (e.g., read only memory (ROM) 430, random access memory (RAM) 440, hard disk 470, etc.) of the computing device 400 may store data and / or information obtained from any other component that determines the recommended pick-up point system 100.
  • exemplary ROMs may include mask ROM (MROM), programmable ROM (PROM), erasable programmable ROM (PEROM), electrically erasable programmable ROM (EEPROM), compact disc ROM (CD-ROM), and digital Universal disk ROM and so on.
  • Exemplary RAMs may include dynamic RAM (DRAM), double-rate synchronous dynamic RAM (DDR SDRAM), static RAM (SRAM), thyristor RAM (T-RAM), zero capacitance (Z-RAM), and the like.
  • the input / output interface 460 may be used to input or output signals, data, or information. In some embodiments, the input / output interface 460 may enable a user to contact the system 100 for determining a recommended pick-up point. In some embodiments, the input / output interface 460 may include an input device and an output device. Exemplary input devices may include a keyboard, a mouse, a touch screen, a microphone, and the like, or any combination thereof. Exemplary output devices may include display devices, speakers, printers, projectors, etc., or any combination thereof.
  • Exemplary display devices may include a liquid crystal display (LCD), a light emitting diode (LED) -based display, a flat panel display, a curved display, a television device, a cathode ray tube (CRT), or the like, or any combination thereof.
  • the communication port 450 may be connected to a network for data communication.
  • the connection may be a wired connection, a wireless connection, or a combination of both.
  • the wired connection may include a cable, a fiber optic cable, a telephone line, or the like, or any combination thereof.
  • the wireless connection may include Bluetooth, Wi-Fi, WiMax, WLAN, ZigBee, a mobile network (for example, 3G, 4G, or 5G, etc.), etc., or any combination thereof.
  • the communication port 450 may be a standardized port, such as RS232, RS485, and the like.
  • the communication port 450 may be a specially designed port.
  • FIG. 5 is a block diagram of a medical resource optimization and matching system for emergency and critical care according to some embodiments of the present application.
  • the system may include a request receiving module 510, an information acquisition module 520, a condition determination module 530, a resource matching module 540, a resource scheduling module 550, a real-time monitoring and early warning module 560, and a quality control module 570.
  • the system may further include a data pre-processing module 580.
  • the disease determination module 530, the resource matching module 540, and the resource scheduling module 550 may be combined into an intelligent engine, which may be used for intelligent reasoning including, but not limited to, search, calculation, and judgment. Specifically, it can be used to match the condition based on the input data and output recommendations based on artificial intelligence technology.
  • the request receiving module 510 may be configured to receive a call for help for a critically ill patient.
  • the information collection module 520 may be used to collect relevant information of a critically ill patient. In some embodiments, the information collection module 520 may obtain first aid information based on the best emergency medical resources for on-site inspection or rescue of the critically ill patients.
  • the illness determination module 530 may be used to make a preliminary judgment on the illness of the critically ill patient according to the relevant information of the critically ill patient.
  • the medical condition determining module 530 is configured to update the preliminary medical condition of the critically ill patient according to the first aid information.
  • the condition determination module 530 may be used to extract keywords related to the critically ill patient to determine the suspected condition of the critically ill patient.
  • the illness determination module 530 may be used to initially determine a suspected illness of a critically ill patient based on medical records, symptoms, and / or illness information.
  • the illness determination module 530 may be used to determine the results of the preliminary diagnosis of the critically ill patient based on the preliminary diagnosis model.
  • the resource matching module 540 may be used to match the best emergency medical resources according to the preliminary judgment results of the critically ill patients. In some embodiments, the resource matching module 540 may further update the hospital resources in the matched best emergency medical resources according to the updated condition results of the critically ill patients.
  • the resource scheduling module 550 may be used to designate the best emergency medical resources to reach the first scene where the critically ill patient is located.
  • the resource scheduling module 550 is also referred to as emergency response scheduling, and is used to instruct matching medical resource scheduling.
  • the resource scheduling module 550 is used for real-time scheduling based on the dynamic calculation of the intelligent engine to match the best medical resource.
  • the resource scheduling module 550 may be configured to plan an optimal route for travelling by the best emergency medical resources according to road-related information data.
  • the resource scheduling module 550 can plan the best route for the best emergency medical resources to travel based on the estimated travel time of the emergency medical resources.
  • the real-time monitoring and early warning module 560 can be used to monitor the condition of critically ill patients in real time while being delivered to the matching hospital resources, and to continuously update the emergency information. This module can be used to alert abnormal situations based on first aid information.
  • the quality control module 570 may be used to perform real-time alarming by judging whether the initial condition of the condition or the updated condition of the critically ill patient is consistent with the specification of the rescue process, so as to achieve quality control.
  • the data pre-processing module 580 may be used to pre-process the collected data.
  • system and its modules shown in FIGS. 1-5 may be implemented in various ways.
  • the system and its modules may be implemented by hardware, software, or a combination of software and hardware.
  • the hardware part can be implemented with dedicated logic; the software part can be stored in the memory and executed by a suitable instruction execution system, such as a microprocessor or dedicated design hardware.
  • a suitable instruction execution system such as a microprocessor or dedicated design hardware.
  • processor control code such as in a carrier medium such as a magnetic disk, CD or DVD-ROM, such as a read-only memory (firmware Such code is provided on a programmable memory or a data carrier such as an optical or electronic signal carrier.
  • the system and its modules of the present application can be implemented not only by hardware circuits such as VLSI or gate arrays, semiconductors such as logic chips, transistors, or programmable hardware devices such as field programmable gate arrays, programmable logic devices, and the like. It can also be implemented by software executed by various types of processors, for example, or by a combination of the above-mentioned hardware circuit and software (for example, firmware).
  • the request receiving module 510, the information acquisition module 520, the condition determination module 530, the resource matching module 540, the resource scheduling module 550, the real-time monitoring and early warning module 560, and the quality control module 570 may be a system
  • the different modules in the module may also be a module that implements the functions of the two or more modules described above.
  • the resource matching module 540 and the resource scheduling module 550 may be two modules, or one module may have functions of matching resources and scheduling at the same time.
  • the resource matching module 540 may also have the function of establishing an online collaborative rescue work group.
  • each module can share a storage module, and each module can also have its own storage module. Such deformations are all within the protection scope of this application.
  • FIG. 6 is an exemplary flowchart of a method for optimizing and matching medical resources for emergency treatment in accordance with some embodiments of the present application. As shown in FIG. 6, the method for optimizing and matching medical resources for emergency treatment may include:
  • Step 610 Receive a call for help for a critically ill patient. Specifically, this step may be performed by the request receiving module 510.
  • critically ill patients may include patients whose disease is some kind of emergency, endangered condition.
  • the patient's condition should be medically treated as early as possible, otherwise serious injury to the patient's body or death may result.
  • the call for help may be a request for help from a critically ill patient, or a request from a non-patient himself, for example, a family member of the patient.
  • the call for help may be sent through a mobile phone, a computer, a handheld terminal, a vehicle terminal device, or the like.
  • the call for help may be automatically issued by a device with a monitoring function.
  • Step 620 Collect relevant information of the critically ill patient. Specifically, this step may be performed by the information collection module 520.
  • the call-for-help information terminal may collect related information of the patient while receiving a call for help for critically ill patients.
  • Collection methods may include, but are not limited to, collection based on patient dictation, applications, wearable devices, health detection devices, home monitoring equipment, home robots, and other smart terminals.
  • the application may include a smart application with tracking the health status of the user, for example, Pacifica Tm .
  • the wearable device may include a smart bracelet, a smart watch (for example, Apple watch Tm ), and other devices.
  • the health detection device may include a device such as a sphygmomanometer, a thermometer, etc., which can obtain health condition information. Based on the above acquisition methods, vital sign data such as ECG data, heart rate data, blood pressure, pulse, blood oxygen, and temperature can be collected.
  • the method of collecting may also include a method of acquiring data.
  • the data may include medical record data of the patient, and the medical record data may be historical medical condition or condition information.
  • the patient's historical condition or condition information can be collected based on the patient's medical history (a database that records electronic medical records).
  • the medical record data may be read from the storage device 150.
  • the storage device 150 may be a storage device provided by the medical resource optimization and matching system 100 for emergency and critical care, or an external storage device that does not belong to the system 100, such as a hard disk, an optical disk, or the like.
  • the medical record data can be read through an interface, which includes but is not limited to a program interface, a data interface, a transmission interface, and the like.
  • the medical record data when the system 100 is working, can be automatically extracted from the interface.
  • the medical resource optimization matching system 100 for emergency treatment of critically ill patients may be called by other external devices or systems, and the medical record data is transferred to the system 100 when called.
  • the medical record data can also be obtained in any manner known to those skilled in the art, which is not limited in this application.
  • the related information of the critically ill patient may include, but is not limited to, patient information, time information, location information, and condition description.
  • patient information includes, but is not limited to, name, insurance ID, age, etc .
  • time information may include, but is not limited to, time of onset or call for help
  • location information may indicate the current geographic location of the patient
  • condition description may be structured data or unstructured Data, and descriptive information such as medical or family history.
  • the related information category of the critically ill patient may include text information, voice information, picture information, video information, and the like.
  • the system can read the relevant information through one or more conversion methods and output it in the form of text.
  • One or more methods may include artificial rules and machine learning models.
  • the machine learning model may be based on an acoustic model, such as a convolutional neural network and connectivity time series classification. In some embodiments, they can be combined with each other through artificial rules and through machine learning models. For example, you can perform manual rule-based conversion processing on the input related information before conversion, you can use a combination of multiple machine learning models, or you can include artificial rule-based conversion of the output of one or more machine learning models. deal with.
  • the information can be pre-processed. Specifically, it is sent to the data preprocessing module 580 on the emergency cloud platform for preprocessing.
  • the pre-processing process may include removing some noise data.
  • the noise data may include a part of data with low correlation with the information related to the condition. For example, when the user describes the condition, the content that is not related to the condition is mentioned.
  • the pre-processing method includes, but is not limited to, one or a combination of discrimination method, elimination method, average method, flattening method, proportional method, moving average method, exponential smoothing method, difference method, and the like.
  • a corresponding data structure may be established to store the information.
  • the cloud platform may establish a corresponding data structure for preservation after the related information is pre-processed.
  • the data structure may include, but is not limited to, an information data table, a data graph, a data heap, a data tree, and the like.
  • the data table may include, but is not limited to, a linear table, a linked list, and a hash table.
  • the data structure can also take other forms, and this application does not make any restrictions.
  • Step 630 Perform a preliminary judgment on the condition of the critically ill patient according to the relevant information of the critically ill patient. Specifically, this step may be performed by the condition judgment module 530.
  • the condition refers to the change of the disease, the cause of the disease, the clinical manifestations of the disease, and related conditions.
  • the change of the disease includes improvement, deterioration, and stability.
  • Symptoms are specific manifestations of the disease, such as high fever, shortness of breath, severe chest pain, vomiting, syncope, etc.
  • the symptoms may be professional medical descriptions based on the patient's description.
  • Sickness refers to the external manifestations of diseases, humans, animals, plants, microorganisms and other life forms. For example, acute myocardial infarction.
  • the condition can be inferred from the symptoms, for example, it is determined from the patient's description that the patient has symptoms of severe chest pain and syncope, and it can be further speculated that the patient may have the symptoms of acute myocardial infarction.
  • the condition may include at least one symptom or / and symptoms.
  • the condition obtained by a patient when calling for help belongs to the subjective description of the patient.
  • multiple symptoms included in the disease can be matched according to the information data table, and the disease is further matched from the disease database, so that the suspected disease is initially derived based on the information data table.
  • the method of preliminary judgment of the condition please refer to FIG. 7 and related descriptions.
  • Step 640 Match the best emergency medical resources according to the preliminary judgment result of the critically ill patient. Specifically, this step may be performed by the resource matching module 540.
  • Emergency medical resources refer to all kinds of human and material resources that can be used in first aid, and can include, but are not limited to, special emergency equipment, conventional emergency medical equipment or systems, medicines, medical personnel, hospital resources, and so on.
  • the special first-aid equipment may be an emergency vehicle or an emergency helicopter, which is determined according to the best first-aid medical resources adapted from the preliminary judgment of the condition.
  • the best emergency medical resources can indicate vehicles or helicopters carrying nuclear magnetic, CT ⁇ B, or other detection equipment as special emergency equipment.
  • Hospital resources can refer to hospitals with the ability to receive emergency patients.
  • the hospital can provide human and material resources such as personnel, equipment, places, and medicines for treatment, and these resources are available. Hospital resources may include, but are not limited to, emergency hospitals, general hospitals, and the like.
  • matching the best emergency medical resources according to the preliminary judgment results of the critically ill patients refers to the realization based on the matching rules.
  • the preset matching rule may include, but is not limited to, a nearest distance rule, an optimal experience and effect rule for treating the disease, or a rule with the lowest cost.
  • one rule or a combination of multiple rules can be selected according to different situations to match the best emergency medical resources.
  • the matched best emergency medical resources include at least one.
  • the best emergency medical resources can refer to medical resources that are adapted to the condition of critically ill patients and can meet the needs of treatment. Therefore, the matching best medical resources change at different stages of rescue.
  • the best emergency medical resource is the matching rule of possible preliminary judgment results of emergency and critical care patients preset with the cloud platform knowledge base to select the current critically ill patients. The best match of the results of the preliminary judgment of the condition.
  • Step 650 Specify the best emergency medical resources to reach the first scene where the critically ill patient is located. This step may be performed by the resource scheduling module 550.
  • the first aid cloud platform can designate the best first aid medical resources (for example, emergency vehicles in special first aid equipment, etc.) to reach the first scene where the critically ill patients are located.
  • the cloud platform dispatches the first-aid resources specified in the best matching resource data table, and the received first-aid resources go to the first scene of the patient.
  • the cloud platform may plan the best route for travel designated by the best emergency medical resources according to road-related information data.
  • Road-related information may include, but is not limited to, real-time road condition information, road speed limit information, road traffic signal information, road length information, road construction maintenance information, road slope, and other road attribute information.
  • the real-time road condition information includes road congestion information, Traffic accident information, etc.
  • Road-related information may also include emergency parking belt information, emergency parking belt occupancy information, reverse road condition information, road isolation facility information, and so on.
  • the cloud platform may select an appropriate road relationship to plan the best path according to the emergency situation of the critically ill patient. For example, for very urgent situations, if safety is ensured, non-objective factors caused by traffic rules such as real-time road condition information, road driving direction restriction information, road speed limit information, or road traffic signals may not be considered, and only road length information is considered. Or objective factors such as road construction and maintenance information to plan the best path.
  • traffic rules such as real-time road condition information, road driving direction restriction information, road speed limit information, or road traffic signals may not be considered, and only road length information is considered.
  • objective factors such as road construction and maintenance information to plan the best path.
  • the cloud platform may perform optimal route planning by estimating the transit time of the road section traveled by the best first aid resources.
  • an estimation method for a special vehicle for example, an ambulance
  • the route can take an emergency stop zone, run a red light, a reverse lane, and the like.
  • You can also flexibly plan your journey based on real-time road-related information and data.
  • time-related standards, service cost-related standards, and path-related standards for example, road types, road widths, traffic conditions, speed restrictions, curve radii, and number of intersections
  • the selection may be made from one or more paths.
  • the estimated travel time of a road section can be implemented by an ETA (Estimated Time of Arrival) model.
  • ETA models can include decision trees, association rules, artificial neural networks, deep learning, inductive logic programming, support vector machines, clustering, Bayesian networks, reinforcement learning, representation learning, similarity and metric learning, sparse dictionary learning, genetics Algorithms, rule-based machine learning, etc., or any combination thereof.
  • machine learning may determine an ETA that outputs the estimated road transit time based on a loss function (eg, average absolute percent error (MAPE) loss).
  • MME average absolute percent error
  • the cloud platform sends the planned optimal path to a device (e.g., special emergency equipment, vehicle equipment, etc.) of the best emergency medical resource that receives the order and displays it on the terminal interface, so that the best emergency The medical resources follow the best path to the first scene.
  • a device e.g., special emergency equipment, vehicle equipment, etc.
  • the cloud platform may store the dispatch information on the cloud platform based on the data structure, for example, create a dispatch data table and upload it to the cloud platform.
  • the dispatch information may include information on the best emergency medical resources for receiving orders, information on planned travel routes, and information on estimated travel times.
  • the first aid medical resource terminal can immediately establish a communication group including all members of the best first aid medical resource, and realize the online centering on the critically ill patients. Cooperate with the treatment team to facilitate real-time exchange of various medical information for remote consultation.
  • the emergency medical resource terminal includes an online collaborative treatment group established through the network. The examination data of the patient's condition at the first scene and the diagnostic information of the collaborative working group on the condition are uploaded to the emergency cloud platform through the group information table, and the disease information data table and the emergency data table are updated. The second judgment was rematched with the treating hospital.
  • the emergency medical resource terminal can immediately establish a communication group, including the list of members of the communication group, their responsibilities, and one or more contact methods.
  • the list of members of the communication group may include members in the best emergency medical resources, family members of patients, relatives, designated contacts of patients, or emergency contacts of historical records.
  • the members of the best emergency medical resources may include medical staff (for example, emergency doctors, etc.) visiting the scene and doctors (for example, on-duty doctors, chief doctors, etc.) of designated hospitals.
  • members of the communication group may form a communication group based on the communication device.
  • the communication device may include, but is not limited to, walkie-talkies, various handheld terminal communication devices (e.g., mobile phones, tablet computers, etc.), vehicle terminals, smart phones Robots, wearables, etc.
  • the communication group may be established based on a terminal on a communication device, may be established by a commonly used mobile application, for example, various social applications such as QQ, WeChat, or may be a specially established application.
  • members of the communication group may include doctors other than emergency medical resources, for example, specialist or / and specialist doctors corresponding to the patient's condition.
  • doctors other than emergency medical resources for example, specialist or / and specialist doctors corresponding to the patient's condition.
  • the corresponding expert doctor may be matched according to the preliminary judgment result, or the corresponding expert doctor may be matched according to the condition result updated after the on-site inspection.
  • the members of the communication group may be updated in real time based on the updated best emergency medical resources. For more details about updating the best emergency medical resources, see step 660, which will not be repeated here.
  • Step 660 Examine or rescue the critically ill patient at the best emergency medical resources site, obtain first aid information, and update the preliminary judgment result of the critically ill patient according to the first aid information. Specifically, this step is performed by the disease determination module 530.
  • the best emergency medical resources such as medical personnel, special emergency equipment, and conventional emergency medical equipment arrive at the first scene where the patient is located, and then return the equipment status and patient data to the emergency cloud platform.
  • the patient can be checked, and the result of the check is used as first aid information.
  • Examinations include but are not limited to: biochemical examination, vital sign examination, nuclear magnetic resonance, computed tomography (CT) or on-site image examination such as B-ultrasound.
  • CT computed tomography
  • the cloud platform may store first aid information through a data structure. For example, create a first aid data sheet and upload it to a cloud platform.
  • a medical diagnosis can be given based on the results of the site inspection and rescue measures can be taken for the patient.
  • medical diagnosis and rescue measures can be determined through online collaborative rescue treatment team communication.
  • condition or condition of the medical diagnosis given based on the results of the on-site examination may be inconsistent with the initial judgment result obtained based on the relevant information of the patient, and an updated critical situation may be obtained based on the on-site rescue and medical diagnosis. Results of preliminary judgment of critically ill patients.
  • the cloud platform can perform real-time updates on the stored related information of critically ill patients.
  • a second judgment is made on the condition to obtain a judgment result.
  • the results of the second judgment are relatively accurate, especially the first aid data table based on the examination of the patient at the first scene, the medical diagnosis of the patient's condition by the collaborative treatment team, and the patient information data table corresponding to the on-site rescue update , Combined with the results of artificial intelligence reasoning.
  • step 660 is only for example and illustration, and step 660 is not a required step in this application.
  • step 670 and the following steps can be directly performed based on step 650 under the guidance of the present application.
  • Step 670 Update hospital resources in the matched best emergency medical resources according to the updated medical condition results of the critically ill patients. Specifically, this step is performed by the resource matching module 540.
  • the hospital resources in the best emergency medical resources are updated according to the updated condition results of the critically ill patients.
  • the emergency hospital may change, or the emergency doctor of the emergency hospital may change.
  • the hospital resources can be rematched according to the situation of on-site inspection or rescue.
  • the matching rules can be adjusted to match hospital resources according to the emergency situation of the patient's illness, the seriousness of the illness, or the patient's hospital. For example, when the patient is about to stop breathing, he needs to be delivered to the fastest hospital, and when the patient has a fracture, he needs to be sent to an orthopedic hospital.
  • the best route for the best first aid resources to reach the emergency hospital can be planned according to the road-related information data, eliminating the possibility of delayed arrival to the target hospital due to long distances or traffic jams.
  • the best path planning see step 650 and related descriptions, which will not be repeated here.
  • Step 680 The condition of the critically ill patient is monitored in real time while being served to the matching hospital resources, and the emergency information is continuously updated, and an abnormal situation is warned based on the emergency information. This specific step may be performed by the real-time monitoring and early warning module 560.
  • the real-time monitoring may be the synchronous monitoring of the changing process of the condition of the critically ill patient by using various medical equipment or medical staff.
  • real-time monitoring may be based on monitoring by medical staff, monitoring based on patient data measured by an application, monitoring based on patient data measured by a wearable device, monitoring based on a connected vehicle control device, and the like.
  • the rescue data may be updated based on real-time monitoring. For example, if the patient's condition worsens or improves during transportation, the test results and diagnosis results may change accordingly, and the emergency data can be continuously updated.
  • the abnormal condition may refer to a sudden condition of the patient's condition, which may endanger the patient's illness, require urgent measures, or the condition may affect the hospital, doctor, or plan for treatment, and the like. For example, the patient's heartbeat suddenly stopped and blood pressure suddenly increased.
  • the early warning abnormality may be judged and issued an early warning according to the condition or threshold of the abnormal situation listed in the emergency rescue data and / or the emergency platform knowledge base.
  • an early warning can be triggered according to the patient's vital signs data value, for example, a certain data value is higher or lower than a normal value threshold; an early warning can be triggered according to the patient's feelings, for example, the patient's pain is already intolerable ; You can also trigger early warnings based on changes in patient needs, such as patients requesting replacement of matching hospital resources.
  • the conditions or thresholds for triggering the early warning may also be other conditions, which are not limited in this application.
  • the method of early warning abnormality may include, but is not limited to, sending early warning information or signals to a terminal of a communication group member, a hospital resource terminal, an emergency resource terminal, and the like.
  • the early warning information may be voice, video, text information, and so on.
  • the first-aid medical staff after receiving the warning, can take corresponding first-aid measures to the patient according to the abnormal situation of the early-warning, and the communication group can guide the medical staff to take the corresponding first-aid measures to the patient according to the abnormal situation of the early-warning.
  • the hospital resource terminal According to the abnormal situation of early warning, preparations for patient rescue can be done in advance.
  • it can communicate with the communication group in real time based on the continuously updated emergency data, take rescue measures to the patient in real time, and continuously update the patient's information data.
  • the hospital resources in the best medical resources can be rematched according to the continuously updated emergency data, and the dispatch data can be continuously updated.
  • real-time alarms are performed by judging whether the initial diagnosis result or the updated condition of the critically ill patient is consistent with the rescue procedure specification to implement quality control.
  • various types of conditions should adopt measures consistent with the rescue process specification.
  • the rescue procedure specification refers to the determination methods, steps, measures, etc. for the rescue of patients.
  • Real-time alarms can include voice reminders, text reminders, picture reminders, video reminders, and so on.
  • the real-time alarm may be, but is not limited to, an alert to a rescued medical staff, a communication group, an emergency medical resource terminal, an emergency cloud platform, and a hospital resource terminal. For example, when the medical staff's rescue procedure for patients does not meet the specifications, an alarm will be issued.
  • Quality control is to use the data collected during the entire first aid process for quality control, to monitor for any abnormalities that deviate from the requirements of the first aid guideline specifications in the knowledge base, and to alert if an abnormality occurs.
  • quality control By monitoring for abnormal conditions, performing quality control and providing intelligent-based alarms, it can improve the quality of medical services, reduce or avoid medical accidents, and improve the quality and effectiveness of services.
  • external communications may be added throughout the rescue of critically ill patients, and the diagnosis results, the results of changes in hospital scheduling on the way, etc. may be sent to the family members of the patients.
  • FIG. 7 is an exemplary flowchart of preliminary judgment of the condition of a critically ill patient according to some embodiments of the present application.
  • the method for optimizing and matching medical resources for emergency treatment may include:
  • Step 710 Acquire relevant information of the critically ill patient. Specifically, this step is executed by the disease determination module 530.
  • the relevant information of the critically ill patient can be obtained by calling for help from the requester.
  • the call for help may be uploaded from the call for help terminal.
  • this information can be read from a storage device.
  • the information may also be read through an interface, which includes but is not limited to a program interface, a data interface, a transmission interface, and the like.
  • the relevant information of the critically ill patient is stored in the storage device in the form of an information data table.
  • the relevant information of critically ill patients please refer to FIG. 6 and related descriptions, which will not be repeated here.
  • Step 720 Extract keywords related to the critically ill patient. Specifically, this step is executed by the disease determination module 530.
  • the keywords of the extracted related information may be keywords reflecting the symptom information, and may be keywords reflecting the condition of the critically ill patient.
  • the manner of extracting keywords related to critically ill patients may include keyword algorithm extraction, artificial rule extraction, and the like.
  • the keyword extraction algorithm may include a TF-IDF (term frequency-inverse document frequency) algorithm, a TextRank algorithm, and an LDA (Linear Discrimination Analysis) algorithm, or any combination thereof. Manual extraction can be used for some difficult to identify related information, such as special format files that have not been read.
  • rule-based calculation processing may be performed on input data before calculation, multiple machine learning models may be used in combination, or rule-based calculation processing may be performed on the results output by one or more machine learning models.
  • the keyword information may be input into a Chinese word segmentation tool for word segmentation, which is suitable for the system to output a pattern (such as a word vector) for matching, which is convenient for subsequent matching.
  • the Chinese word segmentation tools may include jieba, SnowNLP (Snow Natural Language Processing), THULAC (THU Lexical Analyzer for Chinese), NLPIR (Natural Language Processing and Information Retrieval).
  • Step 730 Match at least one disease sign according to the keyword. Specifically, this step is executed by the disease determination module 530.
  • At least one symptom can be identified based on the extracted keywords. For example, according to the keywords “very dizzy”, “infected with plague” and “hospital”, the symptoms “dizziness” can be identified. In some embodiments, it can be identified manually. In some embodiments, it may also be determined based on a model. For more details about matching according to the model, refer to step 730, which is not repeated here.
  • Step 740 Match at least one condition according to the keyword. Specifically, this step is executed by the disease determination module 530.
  • the condition may be matched from a disease database (ie, a database recording the condition) based on the extracted symptom keywords as a basis for preliminary judgment of a suspected condition.
  • At least one condition can be matched by the cloud platform's intelligent engine.
  • a suspected disease can be searched in the disease database based on the symptom keywords.
  • matching may also be implemented based on a deep learning model.
  • Deep learning models can be predictive models, including short text matching models ESIM (Enhanced LSTM for Natural Language Inference), and other models that can be implemented by keywords matching disease characteristics.
  • ESIM Enhanced LSTM for Natural Language Inference
  • the word vector data of the corresponding word segmentation such as the keywords "dizziness” and "weakness” are input into the trained prediction model for prediction, and the possible diseases and their probabilities are output, such as fever, cold, cervical degeneration, cerebral blood supply Deficiency, hypertension, cardiovascular and cerebrovascular diseases, etc. and their corresponding probabilities.
  • the matching results may be updated based on the medical records of critically ill patients.
  • the matching result may be updated according to the historical condition, illness, and / or symptoms in the medical record database (a database for recording electronic medical records), the information data table corresponding to the patient-related information is updated, and the disease matching is performed according to the updated related information. Get updated match results.
  • step 750 a suspected condition of the critically ill patient is initially determined according to the at least one disorder or / and at least one symptom. Specifically, this step is executed by the disease determination module 530.
  • the condition includes at least one condition or at least one symptom, and therefore, a suspected condition can be initially determined based on the matching at least one condition or at least one condition.
  • a suspected condition may be initially determined in combination with at least one symptom and at least one condition.
  • the symptoms can determine the degree of the condition and further determine the condition.
  • the matched patient's symptoms include severe chest pain, vomiting, and syncope.
  • the matched patient's symptoms include acute myocardial infarction. The criticality of the patient cannot be determined from the condition alone, but in combination with the condition "syncope", it can be given that the patient may be life-threatening. Initial condition.
  • a preliminary determination may be made by means of manual determination.
  • the suspected condition can be initially determined manually by combining the matched symptoms and at least one condition matched from the disease database.
  • the medical records of critically ill patients can be directly queried to directly determine the suspected condition.
  • the suspected condition of the patient may be initially determined according to the coincidence of the disease or the condition information in the related information of the patient with the medical record in the medical record database.
  • the suspected condition may be initially determined by combining the patient's symptoms and the patient's medical record information.
  • a preliminary determination of a suspected condition may also be implemented by a machine learning model, and the machine learning model may be named a preliminary diagnosis model of the condition.
  • the preliminary diagnosis model is based on training of a large amount of historical patient data, and the labels of historical sample data are suspected conditions.
  • the historical data is not limited to the data of emergency patients, but may also be the data of non-emergency patients.
  • Historical data sources can include, but are not limited to, emergency centers, medium-sized public and private hospitals, and clinics.
  • Patient data may include, but is not limited to, personal information data, historical symptoms, illness or / condition data, current symptoms, illness or / and condition data, vital signs data, family history, and the like.
  • personal information data may include, but is not limited to, age, height, weight, gender, etc .
  • vital signs data may include, but is not limited to, body temperature, blood pressure, temperature, pulse, blood oxygen, etc .
  • symptoms, illness or / condition data may include but not be It is limited to viral colds, fractures, dizziness, palpitations, etc .
  • family history includes, but is not limited to, heart disease, mental illness, and so on.
  • the historical signs, symptoms, or condition data may also include time information, such as a certain year, a certain month, a certain day, and so on.
  • the family history data may also include the relationship between the patient and the patient, for example, father and daughter, mother and daughter, and the like.
  • the type of the preliminary disease model may include, but is not limited to, a ranking model, a regression model, and a classification model.
  • the machine learning model may be a supervised learning model for classification.
  • linear classifiers such as LR, Naive Bayes (NB), K-nearest neighbors (KNN), decision trees (DT), integrated models (RF / GDBT, etc.), and so on.
  • It can also be a supervised learning model for regression, such as linear regression, support vector machine (SVM), K nearest neighbor (KNN), regression tree (DT), integrated model (ExtraTrees / RF / GDBT), and so on.
  • the machine learning model is not limited to the examples given, and may be calculated by a machine learning model based on unsupervised learning.
  • At least one suspected condition and its probability can be obtained after inputting relevant information of the patient into the trained initial condition model.
  • a suspected condition with the highest probability or a probability higher than a threshold may be taken as the preliminary judgment result.
  • the model can be updated in real time based on the results of each site.
  • image matching can be used to assist in identifying the condition.
  • Objects for image matching can be performed based on real-time transmission images and disease images corresponding to the disease database.
  • Real-time transmission of images can also be assisted by preliminary diagnosis through manual diagnosis.
  • the human diagnosis can be performed by medical personnel or other relevant personnel who can complete the diagnosis of the disease.
  • FIG. 8 is an exemplary flowchart of another method for optimizing and matching medical resources for rescue of critically ill patients according to some embodiments of the present application. As shown in FIG. 8, a specific scenario for treating a stroke patient is taken as an example to describe the implementation steps of the method for optimally matching medical resources for emergency treatment of critically ill patients in the embodiment of the present invention.
  • Step 810 Acquire patient information and establish a patient information data table.
  • the patient information includes patient information, time information, location information, condition description, and the like, and the patient information includes basic information such as name, insurance ID, and age.
  • the time information may include the time of onset or the time of calling for help.
  • the location information indicates the geographic location where the patient is currently located.
  • the condition description can be structured data or unstructured data, as well as descriptive information such as medical history or family history.
  • a patient ⁇ Name, ID, Age> is created for a patient.
  • t represents the time, which can be the time of calling for help or the time of onset, for example: time ⁇ >.
  • l indicates the current location of the patient, for example: location ⁇ >.
  • pdata represents the condition description,
  • Step 820 Intelligent reasoning and manual judgment, a preliminary judgment of a suspected condition.
  • step S201 Using artificial judgment and the intelligent engine of the cloud platform, based on the patient information data table established in step S201, matching multiple symptoms included in the condition, and further matching the symptoms from the disease database (ie, the database recording the disease), or according to the medical record database (Database for recording electronic medical records)
  • Step 830 Intelligent reasoning, matching the best medical resources.
  • the intelligent engine of the emergency cloud platform is used to match the best medical resources based on the knowledge base (preset matching rules are stored), extract the best combination of emergency medical resources from the medical resource database, and establish a data table of the best matching resources.
  • NearestHospital indicates the nearest hospital capable of treating patients; RightDoctor indicates a medically-matched doctor, and SuitableEquipment indicates suitable first-aid equipment, such as ventilator, defibrillator, B-mode, ECMO (Extracorporeal Membrane Oxygenation), etc. Equipment required for first aid.
  • RelatedDrug means related drugs.
  • Step 840 Dispatch, create a dispatch data table.
  • the emergency rescue platform of the emergency cloud platform dispatches and calculates the emergency route by obtaining real-time traffic conditions data.
  • the code is as follows: Order ⁇ SpecialAmbulance, RightDoctor, Suitable Equipment, RelatedDrug, Route> Represents the best driving route from the point of departure of the special ambulance to the patient's location.
  • Step 850 Establish a collaborative work group centered on the patient, exchange various medical information in real time, and establish a group information table.
  • the medical staff After the medical staff arrived at the first scene where the patient was, they set up a collaborative work group centered on the patient, exchanged various medical information in real time, uploaded the information to the emergency cloud platform, and established a group information table.
  • the patient is Zhang San.
  • the group members include the emergency doctor who arrived at the scene.
  • the APP establishes a rescue work group named Zhang San.
  • Members of the group include emergency doctors who arrive at the scene, doctors on duty or directors of emergency hospitals, etc., which facilitates real-time communication of ambulance information and required medical resource information, as well as remote consultation.
  • the code for establishing a data table is, for example, Co-ordination ⁇ p, doctor1 ... doctorn, pdata, action>, where action represents first aid business behavior and records operational behavior data for first aid.
  • Step 860 Obtain the examination result of the patient at the first site, and establish a patient emergency data table.
  • the code instruction for obtaining the patient's examination result at the first scene is, for example: Get ⁇ VitalSign>, where the parameters include vital sign data, CT ⁇ B ultrasound and other live image examination data or biochemical data.
  • Step 870 Update the data table based on the condition judgment of the artificial intelligence and the expert consultation.
  • Step 880 Monitor the condition during the transfer and update the emergency data table.
  • the emergency hospital such as the nearest hospital with treatment capacity
  • continuously monitor the condition and obtain new data and then upload the new data to the emergency cloud platform in real time to update the emergency data Table, code such as Monitoring (VitalSign).
  • Step 890 Quality control.
  • Quality control is to use the data collected during the entire first aid process for quality control, to monitor for any abnormalities that deviate from the requirements of the first aid guideline specifications in the knowledge base, and to alert if an abnormality occurs.
  • the code instructions for quality control are as follows: Quality_Control ⁇ p, pdata, action>.
  • the beneficial effects of the embodiments of the present application include, but are not limited to: (1) improving the utilization efficiency of medical resources; (2) shortening the rescue time for critically ill patients; (3) reducing or avoiding medical accidents Appear; (4) The timeliness, fairness and rationality of emergency medical services have been achieved, and the quality of emergency medical services has been improved. It should be noted that different embodiments may have different beneficial effects. In different embodiments, the possible beneficial effects may be any one or a combination of the foregoing, or any other beneficial effects that may be obtained.
  • aspects of this application can be illustrated and described through several patentable categories or situations, including any new and useful process, machine, product, or combination of materials, or to them Any new and useful improvements. Accordingly, various aspects of the present application can be executed entirely by hardware, can be executed entirely by software (including firmware, resident software, microcode, etc.), and can also be executed by a combination of hardware and software.
  • the above hardware or software can be called “data block”, “module”, “engine”, “unit”, “component” or “system”.
  • aspects of the present application may manifest as a computer product located in one or more computer-readable media, the product including computer-readable program code.
  • Computer storage media may contain a transmitted data signal that contains a computer program code, such as on baseband or as part of a carrier wave.
  • the propagation signal may have multiple manifestations, including electromagnetic forms, optical forms, etc., or a suitable combination.
  • a computer storage medium may be any computer readable medium other than a computer readable storage medium, and the medium may be connected to an instruction execution system, apparatus, or device to enable communication, propagation, or transmission of a program for use.
  • Program code on a computer storage medium may be transmitted through any suitable medium, including radio, cable, fiber optic cable, RF, or similar media, or any combination of the foregoing.
  • the computer program code required for the operation of each part of this application can be written in any one or more programming languages, including object-oriented programming languages such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C ++, C #, VB.NET, Python Etc., conventional programming languages such as C, Visual Basic, Fortran 2003, Perl, COBOL 2002, PHP, ABAP, dynamic programming languages such as Python, Ruby and Groovy, or other programming languages.
  • the program code can run entirely on the user's computer, or run as a separate software package on the user's computer, or partly on the user's computer, partly on a remote computer, or entirely on the remote computer or server.
  • the remote computer can be connected to the user's computer through any network form, such as a local area network (LAN) or wide area network (WAN), or to an external computer (for example, via the Internet), or in a cloud computing environment, or as a service Uses such as software as a service (SaaS).
  • LAN local area network
  • WAN wide area network
  • SaaS software as a service
  • numbers describing components and attribute quantities are used. It should be understood that, for such numbers used in the description of the embodiments, the modifiers "about”, “approximately” or “substantially” Modification. Unless stated otherwise, “about”, “approximately” or “substantially” indicates that the stated number allows for a variation of ⁇ 20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximate values, and the approximate values may be changed according to the characteristics required by individual embodiments. In some embodiments, the numerical parameter should take the specified significant digits into account and adopt a general digits retention method. Although the numerical ranges and parameters used to confirm the breadth of the range in some embodiments of this application are approximate values, in specific embodiments, the setting of such values is as accurate as possible within the feasible range.

Landscapes

  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Public Health (AREA)
  • Biomedical Technology (AREA)
  • Medical Informatics (AREA)
  • General Business, Economics & Management (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Business, Economics & Management (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Pathology (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Alarm Systems (AREA)

Abstract

一种急危重症施救的医疗资源优化匹配的方法和系统。所述急危重症施救的医疗资源优化匹配方法包括：接收关于急危重症患者的呼救请求（610）；采集所述急危重症患者的相关信息（620）；根据所述急危重症患者的相关信息对所述急危重症患者的病情进行初判（630）；根据所述急危重症患者的病情初判结果匹配最佳急救医疗资源（640）；以及指定所述最佳急救医疗资源到达所述急危重症患者所在第一现场（650）。该方法可以解决目前急救医疗系统流程长效率低的问题，能够提供与病征合理化适配的医疗资源，并使得急救医疗资源获得最佳匹配调度。

Description

一种急危重症施救的医疗资源优化匹配方法和系统
交叉引用
本申请要求于2018年7月13日提交的中国专利申请No.201810768475.3的优先权，其全部内容通过引用结合于此。
技术领域
本申请涉及医疗智能技术领域，特别涉及一种急危重症施救的医疗资源优化匹配方法和系统。
背景技术
随着医疗信息化建设迅速发展，并在各个国家政策引导及行业强势推动下，医疗机构通过信息化、网络化建设及应用提升医疗过程的效率，在流程改进方面已经取得显著效果。在急救医疗领域，尤其在急危重症的急救领域，由于信息化应用不断深入，使得急救各环节已经初步实现流程衔接，数据共享，各医疗机构协同救治，危重症急救整体能力明显提升，对急救医疗资源匹配调度使用的效率提升起到了至关重要的作用。其中，广泛开展的胸痛中心、卒中中心建设与应用为突出代表。但是目前在急救医疗服务领域仍普遍存在学科繁多、流程冗长、效率偏低的问题，导致在急救事件发生时，实施救治缺乏病症与医疗资源之间的合理化配置以及医疗经济学的科学评估，从而使得急救医疗资源不能够获得最佳利用，造成医疗资源浪费，影响急救医疗服务的及时性、公平性和合理性。
发明内容
本申请提供了一种急危重症施救的医疗资源优化匹配方法和系统，解决了现有急救医疗系统学科多、流程长、效率低的问题，能够提供与病征合理适配的医疗资源，实现了急救资源的最佳调度，医疗资源的优化匹配以及急救医疗服务的及时性、公平性和合理性。
本申请的第一方面提供一种急危重症施救的医疗资源优化匹配方法。所述急危重症施救的医疗资源优化匹配的方法在包括至少一个处理器和至少一个存储设备的机器上实现，包括：接收关于急危重症患者的呼救请求；采集所述急危重症患者的相关信息；根据所述急危重症患者的相关信息对所述急危重症患者的病情进行初判；根据所述急危重症患者的病情初判结果匹配最佳急救医疗资源；以及指定所述最佳急救医疗资源到达所述急危重症患者所在第一现场。
在一些实施例中，所述急危重症施救的医疗资源优化匹配方法还包括：建立所述最佳急救医疗资源的通讯群组。
在一些实施例中，所述急危重症施救的医疗资源优化匹配方法还包括：所述最佳急救医疗资源现场检查或/和施救所述急危重症患者，并获取急救信息；以及根据所述急救信息更新所述急危重症患者的病情初判结果。
在一些实施例中，所述急危重症施救的医疗资源优化匹配方法还包括：根据所述更新的所述急危重症患者的病情结果，更新所述匹配的所述最佳急救医疗资源中的医院资源。
在一些实施例中，所述急危重症施救的医疗资源优化匹配方法还包括：送达所述匹配医院资源途中实时监测所述急危重症患者的病情，并持续更新所述急救信息；以及基于所述急救信息，预警异常情况。
在一些实施例中，所述急危重症施救的医疗资源优化匹配方法还包括：根据道路相关信息数据，规划所述最佳急救医疗资源行驶的最佳路径。所述最佳路径包括所述最佳急救资源到达所述急危重症患者所在第一现场的最佳路径，以及所述最佳急救医疗资源到达所述医院资源的最佳路径。
在一些实施例中，所述根据道路相关信息数据，规划所述最佳急救医疗资源行驶的最佳路径包括：基于所述急救医疗资源的预估路段通行时间，规划所述最佳急救医疗资源行驶的最佳路径。
在一些实施例中，所述根据所述相关信息对所述急危重症患者的病情进行的初判包括：提取所述急危重症患者的相关信息的关键字；根据所述关键字匹配至少一种病征；根据所述关键字匹配至少一种病症；以及根据所述至少一种病症或/和所述至少一种病征，初步判定所述急危重症患者的疑似病情。
在一些实施例中，所述根据所述相关信息对所述急危重症患者的病情进行的初判包括：查找所述急危重症患者的病历、病征和/或病症信息；以及根据所述病历、病征和/或病症信息，初步判定所述急危重症患者的疑似病情。
在一些实施例中，所述根据所述相关信息对所述急危重症患者的病情进行初判包括：获取所述急危重症患者的相关信息；基于训练好的病情初判模型，确定所述急危重症患者的病情初判结果。
在一些实施例中，所述急危重症施救的医疗资源优化匹配方法还包括：通过判断所述病情初判结果或所述更新的所述急危重症患者的病情结果是否与施救流程规范相符进行实时告警，以实现质量控制。
本申请的第二方面提供一种急危重症施救的医疗资源优化匹配的系统。所述急危重症施救的医疗资源优化匹配的系统包括：请求接收模块，用于接收关于急危重症患者的呼救请求；信息采集模块，用于采集所述急危重症患者的相关信息；病情判定模块，用于根据所述急危重症患者的相关信息对所述急危重症患者的病情进行初判；资源匹配模块，用于根据所述急危重症患者的病情初判结果匹配最佳急救医疗资源；以及资源调度模块，用于指定所述最佳急救医疗资源到达所述急危重症患者所在第一现场。
在一些实施例中，所述信息采集模块还用于：基于所述最佳急救医疗资源对所述急危重症患者的现场检查或/和施救获取急救信息。
在一些实施例中，所述病情判定模块还用于：根据所述急救信息更 新所述急危重症患者的病情初判结果。
在一些实施例中，所述资源匹配模块还用于：根据所述更新的所述急危重症患者的病情结果，更新所述匹配的所述最佳急救医疗资源中的医院资源。
在一些实施例中，所述急危重症施救的医疗资源优化匹配的系统还包括：实时监测和预警模块，用于送达所述匹配医院资源途中实时监测所述急危重症患者的病情，并持续更新所述急救信息；以及基于所述急救信息，预警异常情况。
在一些实施例中，所述资源调度模块还用于：根据道路相关信息数据，规划所述最佳急救医疗资源行驶的最佳路径；所述最佳路径包括所述最佳急救资源到达所述急危重症患者所在第一现场的最佳路径，以及所述最佳急救医疗资源到达所述医院资源的最佳路径。
在一些实施例中，所述资源调度模块还用于：基于所述急救医疗资源的预估路段通行时间，规划所述最佳急救医疗资源行驶的最佳路径。
在一些实施例中，所述病情判定模块还用于：提取所述急危重症患者的相关信息的关键字；根据所述关键字匹配至少一种病征；根据所述关键字匹配至少一种病症；以及根据所述至少一种病症，初步判定所述急危重症患者的疑似病情。
在一些实施例中，所述病情判定模块还用于：查找所述急危重症患者的病历、病征和/或病症信息；以及根据所述病历、病征和/或病症信息，初步判定所述急危重症患者的疑似病情。
在一些实施例中，所述病情判定模块还用于：获取所述急危重症患者的相关信息；基于训练好的病情初判模型，确定所述急危重症患者的病情初判结果。
在一些实施例中，所述急危重症施救的医疗资源优化匹配的系统还 包括：质量控制模块，用于通过判断所述病情初判结果或所述更新的所述急危重症患者的病情结果是否与施救流程规范相符进行实时告警，以实现质量控制。
本申请的第三方面提供一种急危重症施救的医疗资源优化匹配的装置。所述急危重症施救的医疗资源优化匹配的装置包括至少一个存储介质和至少一个处理器，其特征在于，所述至少一个存储介质用于存储计算机指令；所述至少一个处理器用于执行所述计算机指令以实现急危重症施救的医疗资源优化匹配的方法。
本申请的第四方面提供一种计算机可读存储介质。所述存储介质存储计算机指令，当所述计算机指令被计算机执行时，实现急危重症施救的医疗资源优化匹配的方法。
附图说明
本申请将以示例性实施例的方式进一步说明，这些示例性实施例将通过附图进行详细描述。这些实施例并非限制性的，在这些实施例中，相同的编号表示相同的结构，其中：
图1是根据本申请一些实施例所示的急危重症施救的医疗资源优化匹配系统的应用场景图；
图2是根据本申请一些实施例所示的急危重症施救的医疗资源优化匹配系统的结构图；
图3是根据本申请一些实施例所示的急危重症施救的医疗资源优化匹配系统的示意图；
图4是根据本申请一些实施例所示的示例性计算设备的示意图；
图5是根据本申请一些实施例所示的急危重症施救的医疗资源优化匹配系统的模块图；
图6是根据本申请一些实施例所示的急危重症施救的医疗资源优化 匹配方法的示例性流程图；
图7是根据本申请一些实施例所示的急危重症患者的病情初判方法的示例性流程图；以及
图8是根据本申请一些实施例所示的另一种急危重症施救的医疗资源优化匹配方法的示例性流程图。
具体实施方式
为了更清楚地说明本申请实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其它类似情景。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。
应当理解，本文使用的“系统”、“装置”、“单元”和/或“模块”是用于区分不同级别的不同组件、元件、部件、部分或装配的一种方法。然而，如果其他词语可实现相同的目的，则可通过其他表达来替换所述词语。
如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其它的步骤或元素。
虽然本申请对根据本申请的实施例的系统中的某些模块或单元做出了各种引用，然而，任何数量的不同模块或单元可以被使用并运行在客户端和/或服务器上。所述模块仅是说明性的，并且所述系统和方法的不同方面可以使用不同模块。
本申请中使用了流程图用来说明根据本申请的实施例的系统所执行 的操作。应当理解的是，前面或后面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各个步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。
图1所示为根据本申请一些实施例所示的急危重症施救的医疗资源优化匹配系统的应用场景图。如图1所述，该急危重症施救的医疗资源优化匹配系统100可以设置在各种急救中心为呼救人员提供与病征合理适配的医疗资源。本系统可以包括急救医疗资源终端110、网络120、呼救信息终端130、服务器140、存储设备150和医院资源终端160。在一些实施例中，服务器140和存储设备150可以合并称为急救云平台。
急求资源终端110可以用于提供急救医疗资源。急救医疗资源包括但不限于特种急救设备(载有核磁、CT(Computed Tomography，电子计算机断层扫描)、B超的急救车或者直升机等)、常规急救医疗设备或系统、药品、医护人员、医院资源等。其中，医院资源可以指具备接诊急救患者能力的医院，例如急救医院、综合性医院等。关于急救医疗资源的更多细节参见图6及其相关描述，此处不再赘述。
网络120连接系统的各组成部分，使得各部分之间可以进行通信。在系统中各部分之间的网络可以是有线网络或无线网络中的任意一种或多种。例如，网络120可以包括电缆网络、有线网络、光纤网络、电信网络、内部网络、互联网、局域网络(LAN)、广域网络(WAN)、无线局域网络(WLAN)、城域网(MAN)、公共交换电话网络(PSTN)、蓝牙网络、紫峰网络(ZigBee)、近场通信(NFC)、设备内总线、设备内线路、线缆连接等或其任意组合。每两个部分之间的网络连接可以是采用上述一种方式，也可以是采取多种方式。
在一些实施例中，如图2所述，呼救信息终端130、急救医疗资源端110及医院资源端160可以通过网络120(例如无线网络)与急救云平台 210(包含服务器140和存储设备150)建立连接，建立了针对急危重症施救的医疗资源优化匹配的网络结构基础，实现了协同工作，提高了医疗资源合理化配置的基础上提升了急救医疗服务的能力和质量。其中，交通数据平台只是作为提供实时路况的数据源，不作为系统的一部分，通过实时路况数据的获取，不断优化急救医疗路线，保证了医疗资源匹配调度效率和医疗服务的效率。
呼救信息终端130可以是接收有呼救诉求的急危重症患者的相关信息，例如呼叫中心的电话台、计算机、智能手机、车载终端设备等。在一些实施例中，呼救诉求可以来自于一个或多个呼救请求者。呼救请求者可以是直接使用服务的急危重症患者，也可以是协助急危重症患者呼救的其他人，例如，急危重症患者的家属、路人等。在一些实施例中，呼救信息终端130可以是各类具有通讯功能的设备，通讯功能包括但不限于拨打电话、信息接收和/或发送功能等。在一些实施例中，呼救信息终端130可以是具有定位功能的设备。具体定位功能的技术可以基于全球定位系统(GPS)、全球导航卫星系统(GLONASS)、北斗卫星导航系统(COMPASS)、伽利略卫星定位系统、准天顶卫星系统(QZSS)、无线保真(WiFi)定位技术等，或其任何组合。一个或以上上述定位系统可以在本申请中互换使用。定位功能可以提供与位置相关的信息。位置相关的信息可包括对象的位置、高度、速度或加速度、当前时间等。在一些实施例中，系统100中也可以包括其他具有定位功能的设备，这类设备可以与其它设备通信以确定其它设备位置。
服务器140可以处理来自本系统至少一个组件或外部数据源(例如，云数据中心)的数据和/或信息。在一些实施例中，服务器110可以是一台单独的服务器，可以是多台服务器组成的计算平台，多台服务器可以是集中式的或分布式的，可以是专用的也可以由其他设备或系统同时提供服务。 在一些实施例中，服务器可以在云平台上实施。仅作为示例，云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。
在一些实施例中，服务器140可以包含智能引擎和急救调度功能。关于智能引擎和急救调度的更多细节请参见图5及其相关描述，此处不再赘述。
存储设备150可以存储数据和/或指令。存储设备150可以包括一个或多个存储组件，每个存储组件可以是一个独立的设备，也可以是其他设备的一部分。在一些实施例中，存储设备可包括大容量存储器、可移动存储器、易失性读写存储器、只读存储器(ROM)等或其任意组合。在一些实施例中，存储设备150可以在云平台上实现。
在一些实施例中，存储设备150可以存储各种信息库。信息库包括但不限于用于存储与多种病征匹配的病症库、用于存储历史病症的电子病历的病历库、用于存储急救过程所需的各类知识的知识库。其中，各类知识包括但不限于匹配医疗资源的规则、施救流程的规范及异常的监控准则、救治流程规则、系统管理运营规则。在一些实施例中，信息库还包括用于存储可供调度的急救医疗资源和医院资源的信息的医疗资源库。医疗资源库中存储的是可供调度的医疗资源的信息，比如，具有急救医技的医生的信息、救护车的信息、直升机的信息等。在一些实施例中，存储设备150可以存储患者的信息数据、急救数据、最佳急救匹配资源数据、派单数据和群组信息数据，以及所述几种数据的持续更新数据。在一些实施例中，所述几种数据的存储方式可以是数据表的形式，也可以是其他形式，本申请不做限制。
医院资源终端160可以基于急危重症患者的病情提供医院资源。医院资源可以包括急救医院或公立医院，例如，各卫生院、县级医院、市级医 院以及省级医院等，还可以包括各个医院的医生信息、设备信息、场所信息等。例如，当急危重症患者的病情初判结果为心脏病，则提供能够治疗心脏病的医院名单信息、医生信息以及设备信息等。在一些实施例中，医院资源终端160可以接收急救云平台传送的数据，例如，患者的信息数据、急救数据等，医院资源终端160的急救医生可以根据数据做好急救准备，或者提供现场救助措施建议。
在一些实施例中，服务器140可以处理从急救医疗资源终端110、呼救信息终端302、服务器140、存储设备150和医院资源终端160中获得的数据和/或信息，并对这些数据和/或信息进行处理或者基于这些数据、信息和/或处理结果对本系统中的其他设备进行控制。
在一些实施例中，如图3所述，急救云平台的服务器140收到呼救信息终端130传输的患者的相关信息之后，智能引擎先根据急救云平台的存储设备150的病症库、病历库以及呼救交互信息，进行计算和匹配后输出病症智能匹配结果及建议，可选地，急救云平台210将病症智能匹配结果及建议输出给呼救信息终端130，提供给患者。
在一些实施例中，急救云平台210的急救调度根据存储设备150的知识库预设的匹配规则，从医疗资源库中匹配最佳医疗资源，通过交通数据平台获取的实时的路况计算最佳行车路径，进行派单，将调度信息及智能建议发送给急救医疗资源终端110。
在一些实施例中，急救医疗资源到达患者所在的第一现场之后，返回设备状态和患者数据给急救云平台210。这里的急救资源终端110上包括通过网络建立的在线协同救治工作群组。在第一现场对患者病情的检查数据及协同工作群组对病情的诊断信息通过群组信息表上传到急救云平台210，更新病症信息数据表及急救数据表，并基于智能引擎推理对病情的二次判别重新匹配救治医院。
在一些实施例中，急救资源终端110通过在线协同救治工作群组将急救数据发送给救治医院终端160内的技能匹配的医生，从而获得救治建议，实现了在第一现场进行远程会诊和获取医院救治建议的有益效果。在患者被转运到救治医院进行施救的途中，急救云平台210也将急救数据发送给救治医院资源终端160，救治医院终端160返回资源状态。比如，特种急救设备已经到达救治医院这样的资源状态信息，方便急救云平台210对急救医疗资源的状态监控以及质量控制，从而提高了施救流程的质量可控性和杜绝异常状况的出现。
图4是根据本申请一些实施例所示的一种示例性计算设备的示意图。如图4所述，计算设备400可以包括处理器420、只读存储器430、随机存储器440、通信端口450、输入/输出接口460和硬盘470。
处理器420可以执行计算指令(程序代码)并执行本申请描述的确定推荐上车点系统100的功能。所述计算指令可以包括程序、对象、组件、数据结构、过程、模块和功能(所述功能指本申请中描述的特定功能)。例如，处理器420可以处理从确定推荐上车点系统100的其他任何组件获取的图像或文本数据。在一些实施例中，处理器420可以包括微控制器、微处理器、精简指令集计算机(RISC)、专用集成电路(ASIC)、应用特定指令集处理器(ASIP)、中央处理器(CPU)、图形处理单元(GPU)、物理处理单元(PPU)、微控制器单元、数字信号处理器(DSP)、现场可编程门阵列(FPGA)、高级RISC机(ARM)、可编程逻辑器件以及能够执行一个或多个功能的任何电路和处理器等，或其任意组合。仅为了说明，图4中的计算设备400只描述了一个处理器，但需要注意的是，本申请中的计算设备400还可以包括多个处理器。
计算设备400的存储器(例如，只读存储器(ROM)430、随机存储器(RAM)440、硬盘470等)可以存储从确定推荐上车点系统100的任何 其他组件获取的数据和/或信息。示例性的ROM可以包括掩模ROM(MROM)、可编程ROM(PROM)、可擦除可编程ROM(PEROM)、电可擦除可编程ROM(EEPROM)、光盘ROM(CD-ROM)和数字通用盘ROM等。示例性的RAM可以包括动态RAM(DRAM)、双倍速率同步动态RAM(DDR SDRAM)、静态RAM(SRAM)、晶闸管RAM(T-RAM)和零电容(Z-RAM)等。
输入/输出接口460可以用于输入或输出信号、数据或信息。在一些实施例中，输入/输出接口460可以使用户与确定推荐上车点的系统100进行联系。在一些实施例中，输入/输出接口460可以包括输入装置和输出装置。示例性输入装置可以包括键盘、鼠标、触摸屏和麦克风等，或其任意组合。示例性输出装置可以包括显示设备、扬声器、打印机、投影仪等或其任意组合。示例性显示装置可以包括液晶显示器(LCD)、基于发光二极管(LED)的显示器、平板显示器、曲面显示器、电视设备、阴极射线管(CRT)等或其任意组合。通信端口450可以连接到网络以便数据通信。所述连接可以是有线连接、无线连接或两者的组合。有线连接可以包括电缆、光缆或电话线等或其任意组合。无线连接可以包括蓝牙、Wi-Fi、WiMax、WLAN、ZigBee、移动网络(例如，3G、4G或5G等)等或其任意组合。在一些实施例中，通信端口450可以是标准化端口，如RS232、RS485等。在一些实施例中，通信端口450可以是专门设计的端口。
图5是根据本申请一些实施例所示的急危重症施救的医疗资源优化匹配系统的模块图。如图5所述，该系统可以包括请求接收模块510、信息采集模块520、病情判定模块530、资源匹配模块540、资源调度模块550、实时监测和预警模块560、质量控制模块570。在一些实施例中，该系统还可以包括数据预处理模块580。在一些实施例中，病情判定模块530、资源匹配模块540、资源调度模块550可以合并称为智能引擎，该智能引擎可以 用于包括但不限于搜索、计算及判断的智能推理。具体的，可以用于根据输入的数据，对病情进行基于人工智能技术进行匹配并输出建议。
请求接收模块510可以用于接收关于急危重症患者的呼救请求。
信息采集模块520可以用于采集急危重症患者的相关信息。在一些实施例中，信息采集模块520可以基于最佳急救医疗资源对急危重症患者的现场检查或/和施救获取急救信息。
病情判定模块530可以用于根据急危重症患者的相关信息对急危重症患者的病情进行初判。在一些实施例中，病情判定模块530用于根据急救信息更新急危重症患者的病情初判结果。在一些实施例中，病情判定模块530可以用于提取急危重症患者的相关信息的关键字初步判定急危重症患者的疑似病情。在一些实施例中，病情判定模块530可以用于根据病历、病征和/或病症信息，初步判定急危重症患者的疑似病情。在一些实施例中，病情判定模块530可以用于基于病情初判模型确定急危重症患者的病情初判结果。
资源匹配模块540可以用于根据急危重症患者的病情初判结果匹配最佳急救医疗资源。在一些实施例中，资源匹配模块540还可以根据更新后的急危重症患者的病情结果更新匹配的最佳急救医疗资源中的医院资源。
资源调度模块550可以用于指定最佳急救医疗资源到达急危重症患者所在第一现场。在一些实施例中，资源调度模块550也称急救调度，用于指示匹配医疗资源调度，具体的，是用于根据智能引擎的动态计算匹配最佳医疗资源进行实时调度。在一些实施例中，资源调度模块550可以用于根据道路相关信息数据规划最佳急救医疗资源行驶的最佳路径。在一些实施例中，资源调度模块550可以于根据急救医疗资源的预估路段通行时间，规划最佳急救医疗资源行驶的最佳路径。
实时监测和预警模块560可以用于送达匹配医院资源途中实时监测 急危重症患者的病情，并持续更新所述急救信息。该模块可以用于基于急救信息，预警异常情况。
质量控制模块570可以用于通过判断的病情初判结果或更新的急危重症患者的病情结果是否与施救流程规范相符进行实时告警，以实现质量控制。
数据预处理模块580，可以用于采集数据的预处理。
模块图的各个模块功能的更多细节参见图6、图7及其相关描述，此处不再赘述。
应当理解，图1-图5所示的系统及其模块可以利用各种方式来实现。例如，在一些实施例中，系统及其模块可以通过硬件、软件或者软件和硬件的结合来实现。其中，硬件部分可以利用专用逻辑来实现；软件部分则可以存储在存储器中，由适当的指令执行系统，例如微处理器或者专用设计硬件来执行。本领域技术人员可以理解上述的方法和系统可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、CD或DVD-ROM的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本申请的系统及其模块不仅可以有诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用例如由各种类型的处理器所执行的软件实现，还可以由上述硬件电路和软件的结合(例如，固件)来实现。
需要注意的是，以上对于候选项显示、确定系统及其模块的描述，仅为描述方便，并不能把本申请限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解该系统的原理后，可能在不背离这一原理的情况下，对各个模块进行任意组合，或者构成子系统与其他模块连接。例如，在一些实施例中，例如，请求接收模块510、信息采集模块520、病 情判定模块530、资源匹配模块540、资源调度模块550、实时监测和预警模块560、质量控制模块570可以是一个系统中的不同模块，也可以是一个模块实现上述的两个或两个以上模块的功能。例如，资源匹配模块540、资源调度模块550可以是两个模块，也可以是一个模块同时具有匹配资源和调度的功能。例如，资源匹配模块540还可以具备建立在线的协同救治工作群组的功能。例如，各个模块可以共用一个存储模块，各个模块也可以分别具有各自的存储模块。诸如此类的变形，均在本申请的保护范围之内。
图6是根据本申请一些实施例所示的急危重症施救的医疗资源优化匹配方法的示例性流程图。如图6所示，该急危重症施救的医疗资源优化匹配方法可以包括：
步骤610，接收关于急危重症患者的呼救请求。具体的，该步骤可以由请求接收模块510执行。
在一些实施例中，急危重症患者可以包括所得疾病为某种紧急、濒危病症的患者。该患者的病症应当尽早进行医学处理，否则可能对患者身体产生重度伤害或导致死亡。在本实施例中，患者有哪种紧急、濒危的病症不做限制。在一些实施例中，呼救请求可以是急危重症患者发出呼救的请求，也可以是非患者本人发出的请求，例如，患者的家属等。在一些实施例中，呼救请求可以通过手机、电脑、手持终端、车载终端设备等发送。在一些实施例中，呼救请求可以通过带有监控功能的设备自动发出。当呼救请求者发出呼救请求后，急危重症施救的医疗资源优化匹配系统的呼救信息终端可以接收该呼救请求。
步骤620，采集急危重症患者的相关信息。具体的，该步骤可以由信息采集模块520执行。
在一些实施例中，呼救信息终端在接收急危重症患者的呼救请求的同时，还可以采集患者的相关信息。采集的方式可以包括但不限于基于患 者口述、应用程序、可穿戴设备、健康检测装置、家用监控设备、家用机器人及其他智能终端等采集。应用程序可以包括具有追踪用户的健康状态的智能应用程序，例如，Pacifica Tm。所述可穿戴设备可以包括智能手环、智能手表(例如，Apple watch Tm)及其他设备。所述健康检测装置可以包括血压计、体温计等可获取健康情况信息的设备。基于上述采集方式，可以采集心电数据、心率数据、血压、脉搏、血氧、体温等生命体征数据。
采集的方式还可以包括获取数据的方式。数据可以包括患者的病历数据，病历数据可以是历史病情或/和病症信息。例如，可以基于患者的病历(记录电子病历的数据库)采集患者的历史病情或/和病症信息。在一些实施例中，病历数据可以从存储设备150中读取。其中，存储设备150可以是急危重症施救的医疗资源优化匹配系统100自带的存储设备，也可以是不属于系统100的外部存储设备，例如，硬盘、光盘等。在一些实施例中，病历数据可以通过接口读取，接口包括但不限于程序接口、数据接口、传输接口等。在一些实施例中，系统100工作时，可以自动从接口中提取病历数据。在一些实施例中，急危重症施救的医疗资源优化匹配系统100可以被外部其他设备或系统调用，在调用时病历数据被传递给系统100。在一些实施例中，还可以采用本领域技术人员熟知的任意方式获取病历数据，本申请对此不做限制。
在一些实施例中，急危重症患者的相关信息可以包括但不限于病人信息、时间信息、位置信息以及病情描述等。其中，病人信息包括但不限于姓名、保险ID、年龄等；时间信息可以包括但不限于发病时间或呼救时间；位置信息可以指示患者当前所在的地理位置；病情描述可以是结构化数据或者非结构化数据，以及病史或者家族史等这样的描述信息。
在一些实施例中，急危重症患者的相关信息类别可以包括文本信息、语音信息、图片信息及视频信息等。在一些实施例中，对于语音信息及视 频信息等非文本信息，系统可以通过一种或多种转化方式，读取相关信息，并以文本的形式输出。一种或多种方式可以包括人工规则及机器学习模型等。在一些实施例中，机器学习模型可以是基于声学模型，例如卷积神经网络和连接性时序分类等。在一些实施例中，通过人工规则及通过机器学习模型可以相互结合。例如，可以在转换前对输入的相关信息进行基于人工规则的转换处理，可以对多种机器学习模型组合使用，也可以包括对一种或多种机器学习模型输出的结果进行基于人工规则的转换处理。
在一些实施例中，急救云平台获取患者的相关信息之后可以对该信息进行预处理。具体的，发送给急救云平台上数据预处理模块580进行预处理。在一些实施例中，该预处理过程可以包括去除一些噪音数据。所述噪音数据可以包括与病情相关信息相关性低的部分数据。例如，用户在描述病情时，提到的与病情无关的内容。所述预处理方法包括但不限于判别法、剔除法、平均值法、拉平法、比例法、移动平均法、指数平滑法、差分法等中的一种或几种的组合。
在一些实施例中，急救云平台获取患者的相关信息后，可以建立相应的数据结构存储该信息。在替代的实施例中，云平台可以在相关信息经过预处理后，建立相应的数据结构保存。数据结构可以包括但不限于信息数据表、数据图、数据堆、数据树等。其中，该数据表可以包含但不限于线性表、链表、散列表等。数据结构也可采用其他形式，本申请不做任何限制。
步骤630，根据所述急危重症患者的相关信息对所述急危重症患者的病情进行初判。具体的，该步骤可以由病情判断模块530执行。
病情是指疾病的变化情况、疾病的起因、疾病的临床表现以及相关情况等，其中，疾病的变化情况包括好转、恶化和稳定等。病征是疾病的具体表现，例如，高热、呼吸急促、剧烈胸痛，呕吐，晕厥等。在一些实施例 中，病征可以是根据患者的描述对应到的专业医学描述。病症是指疾病，人类、动物、植物、微生物等生命形式出现异常状态的外在表现症状。例如，急性心肌梗死。在一些实施例中，病症可以根据病征推测，例如，根据患者的描述确定患者有剧烈胸痛和晕厥的病征，可以进一步推测该患者可能有急性心肌梗死的病征。病情可以包含至少一种病征或/和病征。在急救领域，患者发出呼救请求时获取的病情属于患者的主观描述内容。当急救人员赶往现场或者患者前往医院，经过医护诊断后获取的病情包含疑似的诊断结果。
在一些实施例中，可以根据信息数据表匹配出病情包含的多种病征，进一步从病症库中匹配病症，从而基于所述信息数据表初步推导出疑似病情。关于病情初步判断的方法的更多细节，可以参见图7及其相关描述。
步骤640，根据所述急危重症患者的病情初判结果匹配最佳急救医疗资源。具体的，该步骤可以由资源匹配模块540执行。
急救医疗资源是指急救时所能用到的各种人力和物力资源，可以包括但不限于特种急救设备、常规急救医疗设备或系统、药品、医护人员、医院资源等。其中，特种急救设备可以是急救车辆或者急救直升机，具体根据病情的初判结果适配出的最佳急救医疗资源来确定。例如，最佳急救医疗资源中可以指示载有核磁、CT\B超或其他检测设备的车辆或直升机等作为特种急救设备。医院资源可以指具备接诊急救患者能力的医院，该医院能够提供救治所需的人员、设备、场所、药品等人力和物力资源，且这些资源均处于可用状态。医院资源可以包括但不限于急救医院、综合性医院等。
在一些实施例中，根据急危重症患者的病情初判结果匹配最佳急救医疗资源是指基于匹配规则实现。具体的，预设匹配规则可以包括但不限于距离最近规则、对治疗该病症最优经验和效果规则或者是成本最低规则等。实际应用中可以根据不同的情况选择一种规则或者多种规则的组合以 匹配出最佳急救医疗资源。在一些实施例中，匹配的最佳急救医疗资源至少包含一个。最佳急救医疗资源可以是指与危重症患者的病情适配的且能够满足救治需求的医疗资源，因此，匹配的最佳医疗资源在施救的不同阶段是变化的。例如，在急危重症患者发出呼救急救诉求的初始阶段，最佳急救医疗资源是云平台知识库预设的急危重症患者的可能初判结果与急救资源的匹配规则选出与当前危重症患者的病情初判结果最优匹配的资源。
步骤650，指定所述最佳急救医疗资源到达所述急危重症患者所在第一现场。该步骤可以由资源调度模块550执行。
最佳急救医疗资源匹配完成之后，急救云平台可以指定最佳急救医疗资源(例如，特种急救设备中的急救车辆等)到达急危重症患者所在第一现场。在一些实施例中，云平台对最佳匹配资源数据表中指定的急救资源进行派单，接单的急救资源前往患者的第一现场。
在一些实施例中，云平台可以根据道路相关信息数据，规划指定的最佳急救医疗资源行驶的最佳路径。道路相关信息可以包含但不限于实时路况信息、道路限速信息、道路交通信号信息、道路长度信息、路面施工维护信息、路面坡度以及其他道路属性信息等，其中，实时路况信息包括道路拥堵信息、交通事故信息等。道路相关信息还可以包括紧急停车带信息、紧急停车带占用信息、反向道路路况信息、道路隔离设施信息等。
在一些实施例中，云平台可以根据急危重症患者的紧急情况选择合适的道路相关系规划最佳路径。例如，对于非常紧急的情况，在确保安全的情况下，可以不考虑实时路况信息、道路行驶方向限制信息、道路限速信息或道路交通信号等交通规则造成的非客观因素，仅考虑道路长度信息或道路施工和维护信息等客观因素规划最佳路径。
在一些实施例中，云平台可以通过预估最佳急救资源行驶的路段通行时间来进行最佳路径规划。对于车辆在相应路段的通行时间，使用针对 特种车辆(例如，救护车)的估算方法。例如，在路段中选择通行时间最短的路径时，该路径可以走紧急停车带、闯红灯、逆行车道等。还可以根据实时道路相关信息数据，灵活进行路程规划。具体的，可以基于时间相关标准、服务成本相关标准、路径相关标准(例如，道路类型、道路宽度、交通状况、速度限制、弯道半径、交叉点数量)，从一个或以上路径中选择所述路径。例如，可以根据最短里程、最短时间、最少服务成本、最安全路径、场景最多的路径、具有较少交通的路径等来从一个或以上路径中选择至少一条路径。在该实施例下，预估路段的通行时间可以通过ETA(Estimated Time of Arrival)模型实现。ETA模型可以包括决策树、关联规则、人工神经网络、深度学习、归纳逻辑编程、支持向量机、聚类、贝叶斯网络、强化学习、表示学习、相似性和度量学习，稀疏字典学习、遗传算法、基于规则的机器学习等，或它们的任何组合。在一些实施例中，机器学习可以根据损失函数(例如，平均绝对百分误差(MAPE)损失)确定输出预估路段通行时间的ETA。
在一些实施例中，云平台将规划的最佳路径发送给接单的最佳急救医疗资源的设备(例如，特种急救设备、车载设备等)终端并显示在该终端界面上，使得最佳急救医疗资源按照最佳路径到达第一现场。
在一些实施例中，云平台可以基于数据结构在云平台上存储派单信息，例如，建立派单数据表并上传至云平台。所述派单信息可以包括：接单的最佳急救医疗资源信息、规划的行驶路径信息、预估的行驶时间信息等。
在一些实施例中，最佳急救医疗资源到达第一现场后，急救医疗资源终端可以立即建立包括最佳急救医疗资源中所有成员在内的通讯群组，实现以急危重症患者为中心的在线协同救治工作组，方便实时交流各种医疗信息，进行远程会诊。急救医疗资源终端上包括通过网络建立的在线协同救治工作群组。在第一现场对患者病情的检查数据及协同工作群组对病 情的诊断信息通过群组信息表上传到急救云平台，更新病症信息数据表及急救数据表，并基于智能引擎推理对病情的二次判别重新匹配救治医院。
在一些实施例中，最佳急救医疗资源匹配后，急救医疗资源终端可以立即建立通讯群组，包括通讯群组成员的名单、职责和一种或多种联系方式。其中，通讯群组成员的名单可以包括最佳急救医疗资源中成员、病人家庭成员、亲属、病人指定联系人或历史记录的紧急联系人等。最佳急救医疗资源中成员可以包括前往现场的医护人员(例如，急救医生等)和指定医院的医生(例如，值班医生、主任医生等)等。在一些实施例中，通讯群组的成员可以基于通信设备组成通信群组，该通信设备可以包括但不限于对讲机、各种手持终端通信设备(例如，手机、平板电脑等)、车载终端、智能机器人、可穿戴设备等。进一步地，通信群组可以基于通信设备上的终端建立，可以是常用的移动应用程序建立，例如，QQ、微信等各种社交应用程序，也可以是专门建立的应用程序。
在一些实施例中，通信群组的成员可以包含急救医疗资源以外的医生，例如，与患者病情对应的专科或/和专家医生等。在本实施例中，可以根据初判结果匹配对应的专家医生，也可以根据经过现场检查后更新的病情结果匹配对应的专家医生。
在一些实施例中，可以基于更新的最佳急救医疗资源实时更新通信群组成员。关于更新最佳急救医疗资源的更多细节参见步骤660，此处不再赘述。
步骤660，在最佳急救医疗资源现场检查或/和施救所述急危重症患者，获取急救信息，并根据所述急救信息更新所述急危重症患者的病情初判结果。具体的，该步骤有病情判定模块530执行。
在一些实施例中，医护人员、特种急救设备和常规急救医疗设备等最佳急救医疗资源到达患者所在的第一现场之后，返回设备状态和患者数 据给急救云平台。具体的，最佳急救资源到达急危重症患者所在第一现场后可以对患者进行检查，检查的结果作为急救信息。检查包括但不限于：生化检查，生命体征检查，核磁，CT(Computed Tomography，电子计算机断层扫描)或者B超等现场影像检查等。在该实施例下，云平台可以通过数据结构存储急救信息。例如，建立急救数据表并上传至云平台。
在一些实施例中，最佳急救资源到达急危重症患者所在第一现场后可以基于现场的检查结果给出医疗诊断，并对患者采取施救措施。在一些实施例中，医疗诊断和施救措施可以通过在线协同救治工作组交流确定。
在一些实施例中，基于现场检查结果给出的医疗诊断的病症或/和病情与基于患者的相关信息得出的初判结果可能不一致，可以基于现场施救和医疗诊断获得更新后的急危重症患者的病情初判结果。在一些实施例中，云平台可以对存储的急危重症患者的相关信息进行实时更新。
在一些实施例中，基于所述急救数据表和所述信息数据表的智能推理，对病情进行二次判别得出判断结果。相比初判结果，二次判别的结果相对精确，尤其是基于第一现场对患者的检查的急救数据表、协同救治工作组对患者病情的医疗诊断及现场施救更新对应的患者信息数据表，结合人工智能推理共同做出的判断结果。
应当注意的是，上述有关步骤660的描述仅仅是为了示例和说明，步骤660不属于本申请的必选步骤。对于本领域技术人员来说，在本申请的指导下可以基于步骤650直接进行步骤670及其以下步骤。
步骤670，根据所述更新后的所述急危重症患者的病情结果更新所述匹配的所述最佳急救医疗资源中的医院资源。具体的，该步骤由资源匹配模块540执行。
在一些实施例中，根据更新的急危重症患者的病情结果匹配更新最佳急救医疗资源中的医院资源。经过现场检查后，若病情判定结果与初判 时不一致时，可能急救医院会发生变化，也可能急救医院的急救医生会发生变化。在一些实施例中，可以根据现场检查或/和施救的情况，重新匹配医院资源。在一些实施例中，可以根据患者病情的紧急情况、病情的严重情况或患者的医院等，调整匹配规则进行医院资源的匹配。例如，当患者快停止呼吸了此时需要送达最快能到达的医院，当患者发生骨折需要送往骨科专科医院。
在一些实施例中，可以根据道路相关信息数据规划最佳急救资源送达急救医院的最佳路径，排除因路程长或者堵车等造成的延迟到达目标医院的可能性。关于最佳路径规划的更多细节详见步骤650及其相关描述，此处不再赘述。
步骤680，送达所述匹配医院资源途中实时监测所述急危重症患者的病情，并持续更新所述急救信息，同时基于所述急救信息，预警异常情况。具体的该步骤可以由实时监测和预警模块560执行。
在一些实施例中，实时监测可以是利用各种医疗设备或医护人员对急危重症患者的病情的变化过程进行同步的监控。在一些实施例中，实时监测可以基于医护人员监测、基于应用程序测量患者数据进行监测、基于佩戴设备测量患者数据进行监测、基于车载联网控制设备监控等。在一些实施例中，可以基于实时监控更新急救数据。例如，若运送过程中，患者的情况发生恶化或者好转，检查结果和诊断结果可能会相应发生变化，可以对急救数据持续更新。
预警异常是可以是指对于急危重症患者病情的异常情况进行预先告警。在一些实施例中，异常情况可以是指患者病情的突发情况，该情况可能危及患者生病、需要紧急采取措施，或者该情况可能影响治疗的医院、医生或方案等。例如，患者心跳突然停止、血压突然升高等异常情况。
在一些实施例中，预警异常可以根据持续更新的急救数据和/或急救 平台知识库中规范列出的异常情况发生的条件或阈值判断并发出预警。在该实施例下，可以根据患者的生命体征数据值触发预警，例如，某项数据值高于或低于正常值阈值；可以根据患者的感受情况触发预警，例如，患者的疼痛感已经无法忍受；还可以根据患者的需求变化触发预警，例如，患者要求更换匹配的医院资源。触发预警的条件或阈值还可以是其他情况，本申请不做限制。
在一些实施例中，预警异常的方法可以包括但不限于向通讯群组成员的终端、医院资源终端、急救资源终端等发送预警信息或信号。其中，预警信息可以是语音、视频、文字信息等。在一些实施例中，接收到预警后，急救的医护人员可以根据预警异常情况对患者采取相应的急救措施，通信群组可以根据预警异常情况指导医护人员对患者采取相应的急救措施，医院资源终端可以根据预警异常情况提前做好抢救患者前的准备工作等。
在一些实施例中，可以根据持续更新的急救数据，与通讯群组实时交流，对患者实时采取施救措施，并持续更新患者的信息数据。
在一些实施例中，可以根据持续更新的急救数据重新匹配最佳医疗资源中的医院资源，并持续更新派单数据。
由上可知，最佳医疗资源的调度和分配是动态和实时计算的，根据患者的病情的变化和医生对患者救治的变化而动态匹配和改变，从而进一步提高了急救医疗资源的利用效率，满足了用户的需求，提高了用户满意度。
在一些实施例中，通过判断病情初判结果或更新的急危重症患者的病情结果是否与施救流程规范相符进行实时告警，以实现质量控制。具体的，各种类型的病情应该采取与施救流程规范相符的措施。施救流程规范是指给予患者抢救的确定方法、步骤、措施等。实时告警的方式可以包括语音提醒、文字提醒、图片提醒、视频提醒等。在一些实施例中，实时告警 可以是但不限于向施救的医护人员、通信群组、急救医疗资源终端、急救云平台以及医院资源终端等告警。例如，当医护人员对患者的施救流程不符合规范时，则告警提醒。
质量控制是利用整个急救过程中采集的数据进行质量控制，监测是否出现偏离知识库中急救指南规范要求的异常情况，如果出现异常则进行告警。通过针对异常状况的监测，进行质量控制并提供基于智能的告警，能够提升医疗服务质量，减少或避免医疗事故出现，提高服务质量和效果。
在一些实施例中，在对急危重症患者施救的整个过程中可以增加对外通讯，将诊断结果、途中医院调度变化结果等发送患者家属。
应当注意的是，上述有关流程600的描述仅仅是为了示例和说明，而不限定本申请的适用范围。对于本领域技术人员来说，在本申请的指导下可以对流程600进行各种修正和改变。然而，这些修正和改变仍在本申请的范围之内。
图7是本申请一些实施例所示的对急危重症患者的病情进行初判的示例性流程图。如图7所述，该急危重症施救的医疗资源优化匹配方法可以包括：
步骤710，获取所述急危重症患者的相关信息。具体的，该步骤由病情判定模块530执行。
在一些实施例中，急危重症患者的相关信息可以通过呼救请求者输入获取。例如，呼救请求者可从呼救信息终端上传。在一些实施例中，该信息可以从存储设备中读取。在一些实施例中，该信息还可以通过接口读取，接口包括但不限于程序接口、数据接口、传输接口等。
在一些实施例中，急危重症患者的相关信息以信息数据表的形式存储于存储设备中。关于急危重症患者的相关信息的更多细节参见图6及其相关描述，此处不再赘述。
步骤720，提取所述急危重症患者的相关信息的关键字。具体的，该步骤由病情判定模块530执行。
在一些实施例中，提取的相关信息的关键字可以是反映病征信息的关键字，可以是反映急危重症患者病情的关键字。例如，患者描述的病情内容为“真的非常头晕，可能是感染上瘟疫了，能不能快点去医院”，提取关键字“头晕”、“感染上瘟疫”“医院”。在一些实施例中，提取急危重症患者的相关信息的关键词的方式可以包括关键词算法提取、人工规则提取等。所述关键词提取算法可以包括TF-IDF(term frequency–inverse document frequency)算法、TextRank算法及LDA(Linear Discrimination Analysis)算法等，或其任意组合。人工提取可以用于部分难以识别的相关信息，例如，未被读取的特殊格式文件。
在一些实施例中，通过机器学习和通过规则处理可以相互结合。例如可以在计算前对输入的数据进行基于规则的计算处理，可以对多种机器学习模型组合使用，也可以包括对一种或多种机器学习模型输出的结果进行基于规则的计算处理。
在一些实施例中，可以将该关键字信息输入中文分词工具进行分词，以适用于系统识别匹配的模式输出(例如词向量)，便于后续匹配。所述中文分词工具可以包括jieba、SnowNLP(Snow Natural Language Processing)、THULAC(THU Lexical Analyzer for Chinese)、NLPIR(Natural Language Processing and Information Retrieval)等。
步骤730，根据所述关键字匹配至少一种病征。具体的，该步骤由病情判定模块530执行。
在一些实施例中，可以根据提取的关键字识别至少一种病征。例如，根据关键字“非常头晕”、“感染上瘟疫”“医院”，可以识别出病征“头晕”。在一些实施例中，可以通过人工的方式识别。在一些实施例中，还可 以根据模型确定。关于根据模型匹配的更多细节可以参见步骤730，此处不再赘述。
步骤740，根据所述关键字匹配至少一种病症。具体的，该步骤由病情判定模块530执行。
在一些实施例中，基于提取出的病征关键字，匹配出病情包含的多种病征，并进一步从病症库中匹配出疑似病症作为初判结果。在一些实施例中，可以基于提取的病征关键词从病症库(即，记录病症的数据库)中匹配出病症，作为初步判断疑似病情的基础。
在一些实施例中，可以通过云平台的智能引擎匹配至少一种病症。具体的，可以基于病征关键词在病症库中搜索疑似病症。在一些实施例中，还可以基于深度学习模型实现匹配。深度学习模型可以是预测模型，包括短文本匹配模型ESIM(Enhanced LSTM for Natural Language Inference)，以及其他可以通过关键字匹配病症特征的方式实现的模型。例如，将关键词“头晕”、“乏力”等对应分词后的词向量数据输入训练好的预测模型中进行预测，输出可能病症及其概率，例如，发热、感冒、颈椎退行性变、脑供血不足、高血压、心脑血管疾病等及其相应概率。进一步的，基于预测模型的输出结果进行排序，取Top N(N＝1,2,3…等)作为匹配结果，或者，设定阈值，概率大于设定阈值的结果作为匹配结果。
在一些实施例中，可以基于急危重症患者的病历更新匹配结果。具体的，可以根据病历库(记录电子病历的数据库)中的历史病情、病症和/或病征更新匹配结果，更新与患者相关信息对应的信息数据表，再根据更新后的相关信息进行病症匹配，获得更新后的匹配结果。
步骤750，根据所述至少一种病症或/和至少一种病征，初步判定所述急危重症患者的疑似病情。具体的，该步骤由病情判定模块530执行。
在一些实施例中，病情包含至少一种病症或至少一种病征，因此，可 以根据匹配的至少一种病症或至少一种病征初步确定疑似的病情。在一些优选的实施例中，可以结合至少一种病征和至少一种病症初步确定疑似的病情。该实施例中，病征可以确定病症的程度，进一步确定病情。例如，匹配的患者病证包括剧烈胸痛，呕吐，晕厥，匹配的患者病症包括急性心肌梗死，单从病症无法确定患者的危急程度，但结合病症“晕厥”，可以给出该患者可能有生命危险的初步病情。
在一些实施例中，可以通过人工判断的方式进行初步判定。在一些实施例中，可以结合匹配的病征和从病症库中匹配的至少一种病症，人工初步判断出疑似病情。
在一个替代的实施例中，可以直接查询急危重症患者的病历信息，直接初步判断疑似病情。具体的，可以根据患者的相关信息中的病症或/和病情信息与病历库中的病历的吻合情况，初步确定患者的疑似病情。在一些实施例中，可以结合患者的病征和查询到的患者的病历信息，初步判断疑似病情。
在一些实施例中，还可以通过机器学习模型实现疑似病情的初步判定，该机器学习模型可以命名为病情初判模型。具体的，病情初判模型是基于大量的历史患者数据训练而得，历史样本数据的标签为疑似病情。历史数据不限于急救患者的数据，还可以是非急救患者的数据。历史数据来源可以包括但不限于急救中心、各中规模的公立和私立医院、诊所等。患者数据可以包括但不限于个人信息数据、历史病征、病症或/病情数据、当前病征、病症或/和病情数据、生命体征数据、家族病史等。其中，个人信息数据可以包括但不限于年龄、身高、体重、性别等；生命体征数据可以包括但不限于体温、血压、温度、脉搏、血氧等；病征、病症或/病情数据可以包括但不限于病毒感冒、骨折、头晕、心悸等；家族病史包括但不限于心脏病、精神病等。在一些实施例中，历史病征、病症或病情数据还可以包括 时间信息，例如，某年、某月、某日等。在一些实施例中，家族病史数据还可以包括患病者与患者的关系，例如，父女、母女等。
病情初判模型类型可以包括但不限于排序模型、回归模型和分类模型等。在一些实施例中，所述机器学习模型可以是用于分类的监督学习模型。例如线性分类器(如LR)、朴素贝叶斯(NB)、K近邻(KNN)、决策树(DT)、集成模型(RF/GDBT等)等等。也可以是用于回归的监督学习模型，例如线性回归、支持向量机(SVM)、K近邻(KNN)、回归树(DT)、集成模型(ExtraTrees/RF/GDBT)等。在一些实施例中，所述机器学习模型并不限于所举实例，可以是通过基于无监督学习的机器学习模型进行计算的。
在一些实施例中，将患者的相关信息输入到训练好的病情初判模型后可以得到至少一个疑似病情及其概率。在一些实施例中，可以取概率最高结果或者概率高于阈值的疑似病情作为初判结果。在一些实施例中，模型可以基于每次现场的结果进行实时更新。
在一些实施例中，可以通过图像匹配协助判别病情。图像匹配的对象可以基于实时传送影像与病症库对应疾病图像进行。实时传送影像还可以通过人工诊断的方式进行辅助初判。人工诊断的执行者可以是医护人员或其他可完成疾病诊断的相关人员。
应当注意的是，上述有关流程700的描述仅仅是为了示例和说明，而不限定本申请的适用范围。对于本领域技术人员来说，在本申请的指导下可以对流程700进行各种修正和改变。
图8是根据本申请一些实施例所示的另一种急危重症施救的医疗资源优化匹配方法的示例性流程图。如图8所述，以一个具体的脑卒中患者救治场景为例对本发明实施例的急危重症施救的医疗资源优化匹配方法的实现步骤进行说明。
步骤810：获取患者信息，建立患者信息数据表。
在一些实施例中，患者信息包括病人信息、时间信息、位置信息以及病情描述等，其中，病人信息包括姓名、保险ID、年龄这些基本信息。时间信息可以包括发病时间或呼救时间。位置信息指示患者当前所在的地理位置。病情描述，可以是结构化数据或者非结构化数据，以及病史或者家族史等这样的描述信息。在获取患者的上述信息之后发送给急救云平台上数据预处理模块，经过预处理后，建立患者信息数据表<p,t,l,pdata>并保存到急救云平台上。信息数据表中，p表示包含病人姓名，保险ID，年龄等个人信息的数据，例如：对应一个患者建立patient<Name，ID，Age>。t表示时间，可以是呼救时间也可以是发病时间，例如：time<>。l表示患者当前位置，例如：location<>。pdata表示病情描述，|可以是结构化数据|非结构化数据|关键字|保险|病史的数据集合，例如：pdata<>。
步骤820：智能推理和人工判断，初判疑似病情。
利用人工判断和云平台的智能引擎，基于步骤S201中建立的患者信息数据表匹配病情包含的多个病征，进一步从病症库(即，记录病症的数据库)中匹配出病症，或者，根据病历库(记录电子病历的数据库)中的历史病症更新信息数据表，匹配出多个病征后进一步从病症库中匹配病症，从而初步提取和判断出疑似病情。例如：<p,t,l,pdata>＝><p,ddata>，其中，ddata表示疑似病种判别数据，如ddata<>。
步骤830：智能推理，匹配最佳医疗资源。
利用急救云平台的智能引擎，基于知识库(存储有预设匹配规则)，匹配最佳医疗资源，从医疗资源库中提取最佳急救医疗资源组合，并建立最佳匹配资源数据表。实现该功能的部分代码示意如下：<p,ddata>＝><SpeicialAmbulance,NearestHospital,RightDoctor,SuitableEquipment,RelatedDrug>,其中，SpecialAmbulance<车载CT|车载DSA|MobileICU|MobileNICU|直升飞机>；即，表示的是特种救护设备，例 如，车载CT，或者车载DSA(数字减影血管造影，digital substraction angiography)。NearestHospital表示最近的有能力救治患者的医院；RightDoctor表示医技匹配的医生，SuitableEquipment表示适合的急救设备，例如呼吸机、除颤仪、B超、ECMO(体外膜肺氧合，Extracorporeal Membrane Oxygenation)等急救所需设备。RelatedDrug表示相关药品。
步骤840：派单，建立派单数据表。
根据最佳匹配资源数据表，急救云平台的急救调度进行派单，并通过获取交通实时路况数据，计算急救路线，代码示意如下：Order<SpecialAmbulance,RightDoctor,SuitableEquipment,RelatedDrug,Route>,其中，Route表示从特种救护设备出发地到患者位置的最佳行车路径。
步骤850：以患者为中心建立协同工作群，并实时交流各种医疗信息，建立群组信息表。
医护人员到达患者所在的第一现场之后，以患者为中心建立协同工作群，并实时交流各种医疗信息，将信息上传到急救云平台并建立群组信息表。例如，患者为张三，则医护人员到达第一现场之后，利用移动APP建立名称为张三的救治工作群，群成员包括，到达现场的急救医生，APP建立名称为张三的救治工作群，群成员包括，到达现场的急救医生，急救医院的值班医生或主任等医生，方便实时交流救护信息和所需的医疗资源信息，以及进行远程会诊。建立数据表的代码如：Co-ordination<p,doctor1…doctorn,pdata,action>，其中，action表示急救业务行为，是记录急救的操作行为数据。
步骤860：获得患者在第一现场的检查结果，建立患者急救数据表。
医护人员到达患者所在的第一现场后对患者进行各项检查之后，通过信息采集终端的数据传输模块，将检查信息实时上传至急救云平台，以使得建立患者急救数据表。获得患者在第一现场的检查结果的代码指令例 如：Get<VitalSign>，其中参数包含生命体征数据，CT\B超等现场影像检查数据或者生化数据。
步骤870：基于人工智能和专家会诊的病情判别，更新数据表。
医护人员到达第一现场之后，根据急救云平台上基于现场数据和人工智能技术，对患者进行的病情判别，或者，根据专家会诊对病情的判别，在现场施救，如在CT车上溶栓，更新病症信息数据表<p,ddata>。代码指令例如：Get<VitalSign>＝><p,ddata>。
步骤880：转运途中监控病情，更新急救数据表。
在将患者从第一现场转运到急救医院(如具有救治能力的最近的医院)的途中，持续监控病情并获得新的数据，然后将新的数据实时上传至急救云平台，以使得更新急救数据表，代码如Monitoring(VitalSign)。
步骤890：质量控制。
质量控制是利用整个急救过程中采集的数据进行质量控制，监测是否出现偏离知识库中急救指南规范要求的异常情况，如果出现异常则进行告警。质量控制的代码指令示意如下：Quality_Control<p,pdata,action>。通过针对异常状况的监测，进行质量控制并提供基于智能的告警，能够提升医疗服务质量，减少或避免医疗事故出现，提高服务质量和效果。
本申请实施例可能带来的有益效果包括但不限于：(1)提高了医疗资源的利用效率；(2)缩短了对急危重症患者的施救时间；(3)减少或避免了医疗事故出现；(4)实现了急救医疗服务的及时性、公平性和合理性，提高了急救医疗服务的质量。需要说明的是，不同实施例可能产生的有益效果不同，在不同的实施例里，可能产生的有益效果可以是以上任意一种或几种的组合，也可以是其他任何可能获得的有益效果。
上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述详细披露仅仅作为示例，而并不构成对本申请的限定。虽然此处并没有明 确说明，本领域技术人员可能会对本申请进行各种修改、改进和修正。该类修改、改进和修正在本申请中被建议，所以该类修改、改进、修正仍属于本申请示范实施例的精神和范围。
同时，本申请使用了特定词语来描述本申请的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本申请至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一个替代性实施例”并不一定是指同一实施例。此外，本申请的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。
此外，本领域技术人员可以理解，本申请的各方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的工序、机器、产品或物质的组合，或对他们的任何新的和有用的改进。相应地，本申请的各个方面可以完全由硬件执行、可以完全由软件(包括固件、常驻软件、微码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“数据块”、“模块”、“引擎”、“单元”、“组件”或“系统”。此外，本申请的各方面可能表现为位于一个或多个计算机可读介质中的计算机产品，该产品包括计算机可读程序编码。
计算机存储介质可能包含一个内含有计算机程序编码的传播数据信号，例如在基带上或作为载波的一部分。该传播信号可能有多种表现形式，包括电磁形式、光形式等，或合适的组合形式。计算机存储介质可以是除计算机可读存储介质之外的任何计算机可读介质，该介质可以通过连接至一个指令执行系统、装置或设备以实现通讯、传播或传输供使用的程序。位于计算机存储介质上的程序编码可以通过任何合适的介质进行传播，包括无线电、电缆、光纤电缆、RF、或类似介质，或任何上述介质的组合。
本申请各部分操作所需的计算机程序编码可以用任意一种或多种程 序语言编写，包括面向对象编程语言如Java、Scala、Smalltalk、Eiffel、JADE、Emerald、C++、C#、VB.NET、Python等，常规程序化编程语言如C语言、Visual Basic、Fortran 2003、Perl、COBOL 2002、PHP、ABAP，动态编程语言如Python、Ruby和Groovy，或其他编程语言等。该程序编码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机运行、或完全在远程计算机或服务器上运行。在后种情况下，远程计算机可以通过任何网络形式与用户计算机连接，比如局域网(LAN)或广域网(WAN)，或连接至外部计算机(例如通过因特网)，或在云计算环境中，或作为服务使用如软件即服务(SaaS)。
此外，除非权利要求中明确说明，本申请所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本申请流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本申请实施例实质和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的服务器或移动设备上安装所描述的系统。
同理，应当注意的是，为了简化本申请披露的表述，从而帮助对一个或多个发明实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本申请对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。
一些实施例中使用了描述成分、属性数量的数字，应当理解的是，此类用于实施例描述的数字，在一些示例中使用了修饰词“大约”、“近似”或“大体上”来修饰。除非另外说明，“大约”、“近似”或“大体上”表 明所述数字允许有±20％的变化。相应地，在一些实施例中，说明书和权利要求中使用的数值参数均为近似值，该近似值根据个别实施例所需特点可以发生改变。在一些实施例中，数值参数应考虑规定的有效数位并采用一般位数保留的方法。尽管本申请一些实施例中用于确认其范围广度的数值域和参数为近似值，在具体实施例中，此类数值的设定在可行范围内尽可能精确。
针对本申请引用的每个专利、专利申请、专利申请公开物和其他材料，如文章、书籍、说明书、出版物、文档等，特此将其全部内容并入本申请作为参考。与本申请内容不一致或产生冲突的申请历史文件除外，对本申请权利要求最广范围有限制的文件(当前或之后附加于本申请中的)也除外。需要说明的是，如果本申请附属材料中的描述、定义、和/或术语的使用与本申请所述内容有不一致或冲突的地方，以本申请的描述、定义和/或术语的使用为准。
最后，应当理解的是，本申请中所述实施例仅用以说明本申请实施例的原则。其他的变形也可能属于本申请的范围。因此，作为示例而非限制，本申请实施例的替代配置可视为与本申请的教导一致。相应地，本申请的实施例不仅限于本申请明确介绍和描述的实施例。

Claims (24)

  1. 一种急危重症施救的医疗资源优化匹配方法，在包括至少一个处理器和至少一个存储设备的机器上实现，其特征在于，包括：
    接收关于急危重症患者的呼救请求；
    采集所述急危重症患者的相关信息；
    根据所述急危重症患者的相关信息对所述急危重症患者的病情进行初判；
    根据所述急危重症患者的病情初判结果匹配最佳急救医疗资源；以及
    指定所述最佳急救医疗资源到达所述急危重症患者所在第一现场。
  2. 根据权利要求1所述的方法，其特征在于，进一步包括：
    建立所述最佳急救医疗资源的通讯群组。
  3. 根据权利要求2所述的方法，其特征在于，进一步包括：
    所述最佳急救医疗资源现场检查或/和施救所述急危重症患者，并获取急救信息；以及
    根据所述急救信息更新所述急危重症患者的病情初判结果。
  4. 根据权利要求3所述的方法，其特征在于，进一步包括：
    根据所述更新的所述急危重症患者的病情结果，更新所述匹配的所述最佳急救医疗资源中的医院资源。
  5. 根据权利要求4所述的方法，其特征在于，进一步包括：
    送达所述匹配医院资源途中实时监测所述急危重症患者的病情，并持续更新所述急救信息；以及
    基于所述急救信息，预警异常情况。
  6. 根据权利要求4所述的方法，其特征在于，进一步包括：根据道路相关信息数据，规划所述最佳急救医疗资源行驶的最佳路径；
    所述最佳路径包括所述最佳急救资源到达所述急危重症患者所在第一现场的最佳路径，以及所述最佳急救医疗资源到达所述医院资源的最佳路径。
  7. 根据权利要求1-6所述的方法，其特征在于，所述根据道路相关信息数据，规划所述最佳急救医疗资源行驶的最佳路径包括：
    基于所述急救医疗资源的预估路段通行时间，规划所述最佳急救医疗资源行驶的最佳路径。
  8. 根据权利要求1-7所述的方法，其特征在于，所述根据所述相关信息对所述急危重症患者的病情进行的初判包括：
    提取所述急危重症患者的相关信息的关键字；
    根据所述关键字匹配至少一种病征；
    根据所述关键字匹配至少一种病症；以及
    根据所述至少一种病症或/和所述至少一种病征，初步判定所述急危重症患者的疑似病情。
  9. 根据权利要求1-8所述的方法，其特征在于，所述根据所述相关信息对所述急危重症患者的病情进行的初判包括：
    查找所述急危重症患者的病历、病征和/或病症信息；以及
    根据所述病历、病征和/或病症信息，初步判定所述急危重症患者的疑似病情。
  10. 根据权利要求1-9所述的方法，其特征在于，所述根据所述相关信 息对所述急危重症患者的病情进行初判包括：
    获取所述急危重症患者的相关信息；
    基于训练好的病情初判模型，确定所述急危重症患者的病情初判结果。
  11. 根据权利要求3-10所述的方法，其特征在于，通过判断所述病情初判结果或所述更新的所述急危重症患者的病情结果是否与施救流程规范相符进行实时告警，以实现质量控制。
  12. 一种急危重症施救的医疗资源优化匹配系统，其特征在于，包括：
    请求接收模块，用于接收关于急危重症患者的呼救请求；
    信息采集模块，用于采集所述急危重症患者的相关信息；
    病情判定模块，用于根据所述急危重症患者的相关信息对所述急危重症患者的病情进行初判；
    资源匹配模块，用于根据所述急危重症患者的病情初判结果匹配最佳急救医疗资源；以及
    资源调度模块，用于指定所述最佳急救医疗资源到达所述急危重症患者所在第一现场。
  13. 根据权利要求12所述的系统，其特征在于，所述信息采集模块还用于：
    基于所述最佳急救医疗资源对所述急危重症患者的现场检查或/和施救获取急救信息。
  14. 根据权利要求13所述的系统，其特征在于，所述病情判定模块还用于：
    根据所述急救信息更新所述急危重症患者的病情初判结果。
  15. 根据权利要求14所述的系统，其特征在于，所述资源匹配模块还用于：
    根据所述更新的所述急危重症患者的病情结果，更新所述匹配的所述最佳急救医疗资源中的医院资源。
  16. 根据权利要求12所述的系统，其特征在于，还包括：
    实时监测和预警模块，用于送达所述匹配医院资源途中实时监测所述急危重症患者的病情，并持续更新所述急救信息；以及
    基于所述急救信息，预警异常情况。
  17. 根据权利要求15所述的系统，其特征在于，所述资源调度模块还用于：
    根据道路相关信息数据，规划所述最佳急救医疗资源行驶的最佳路径；
    所述最佳路径包括所述最佳急救资源到达所述急危重症患者所在第一现场的最佳路径，以及所述最佳急救医疗资源到达所述医院资源的最佳路径。
  18. 根据权利要求12-17所述的系统，其特征在于，所述资源调度模块还用于：
    基于所述急救医疗资源的预估路段通行时间，规划所述最佳急救医疗资源行驶的最佳路径。
  19. 根据权利要求12-18所述的系统，其特征在于，所述病情判定模块还用于：
    提取所述急危重症患者的相关信息的关键字；
    根据所述关键字匹配至少一种病征；
    根据所述关键字匹配至少一种病症；以及
    根据所述至少一种病症或/和至少一种病征，初步判定所述急危重症患者的疑似病情。
  20. 根据权利要求12-19所述的系统，其特征在于，所述病情判定模块还用于：
    查找所述急危重症患者的病历、病征和/或病症信息；以及
    根据所述病历、病征和/或病症信息，初步判定所述急危重症患者的疑似病情。
  21. 根据权利要求12-20所述的系统，其特征在于，所述病情判定模块还用于：
    获取所述急危重症患者的相关信息；
    基于训练好的病情初判模型，确定所述急危重症患者的病情初判结果。
  22. 根据权利要求14-21所述的系统，其特征在于，还包括：
    质量控制模块，用于通过判断所述病情初判结果或所述更新的所述急危重症患者的病情结果是否与施救流程规范相符进行实时告警，以实现质量控制。
  23. 一种急危重症施救的医疗资源优化匹配装置，包括处理器，其特征在于，所述处理器用于执行如权利要求1-11任一项所述的方法。
  24. 一种计算机可读存储介质，所述存储介质存储计算机指令，当计算机读取存储介质中的计算机指令后，计算机执行如权利要求1-11任一项所 述的急危重症施救的医疗资源优化匹配方法。
PCT/CN2019/095722 2018-07-13 2019-07-12 一种急危重症施救的医疗资源优化匹配方法和系统 WO2020011244A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810768475.3A CN108986897B (zh) 2018-07-13 2018-07-13 一种急危重症施救的医疗资源优化匹配方法和系统
CN201810768475.3 2018-07-13

Publications (1)

Publication Number Publication Date
WO2020011244A1 true WO2020011244A1 (zh) 2020-01-16

Family

ID=64537269

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/095722 WO2020011244A1 (zh) 2018-07-13 2019-07-12 一种急危重症施救的医疗资源优化匹配方法和系统

Country Status (2)

Country Link
CN (1) CN108986897B (zh)
WO (1) WO2020011244A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11706604B2 (en) 2020-09-02 2023-07-18 Koninklijke Philips N.V. Responding to emergency calls

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108986897B (zh) * 2018-07-13 2021-01-05 飞救医疗科技（北京）有限公司 一种急危重症施救的医疗资源优化匹配方法和系统
CN109686454A (zh) * 2018-12-29 2019-04-26 宁波中数云创信息技术有限公司 一种大数据精准分析和事件即时响应的方法
CN111598752A (zh) * 2019-02-20 2020-08-28 泽世百易医疗科技(北京)有限公司 城市急救网络、急救方法及云中心服务器
CN110752017B (zh) * 2019-09-04 2020-12-18 重庆特斯联智慧科技股份有限公司 一种基于深度学习的社区医生调度方法及系统
CN111063407B (zh) * 2019-12-02 2020-11-20 湖南蓝途方鼎科技有限公司 一种基于区块链的医疗资源数据处理方法及系统
CN110931115A (zh) * 2019-12-03 2020-03-27 上海工艺美术职业学院 智能医疗帐篷及其通信方法
CN111489815B (zh) * 2020-04-18 2021-03-16 北京经纬传奇医药科技有限公司 基于用户行为分析的医疗资源分配方法及云计算服务器
CN113364861B (zh) * 2021-06-03 2022-04-05 重庆东登科技有限公司 紧急医疗的移动医院系统
CN114821994B (zh) * 2022-04-19 2022-10-28 浙江远图技术股份有限公司 一种基于可穿戴设备的健康监测方法、系统及存储介质
CN114664425B (zh) * 2022-05-25 2022-09-02 四川省医学科学院·四川省人民医院 一种静脉治疗管理云平台及构建方法
CN116313018B (zh) * 2023-05-18 2023-09-15 北京大学第三医院（北京大学第三临床医学院） 用于滑雪场与近地医院的急救系统及方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106407703A (zh) * 2016-09-29 2017-02-15 湖南优图信息技术有限公司 一种急救中心信息管理方法及平台
CN106462817A (zh) * 2015-07-23 2017-02-22 深圳循证医学信息技术有限公司 一种急救分级优先调度方法及装置
US20180137250A1 (en) * 2016-11-15 2018-05-17 Hefei University Of Technology Mobile health intelligent medical guide system and method thereof
CN108986897A (zh) * 2018-07-13 2018-12-11 飞救医疗科技（北京）有限公司 一种急危重症施救的医疗资源优化匹配方法和系统

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20070002067A (ko) * 2004-03-26 2007-01-04 셀진 코포레이션 줄기 세포 은행의 제공 시스템 및 제공 방법
CN101977181A (zh) * 2010-08-27 2011-02-16 杭州美诺泰科科技有限公司 一种紧急医疗救援通讯系统
US20120157795A1 (en) * 2010-12-15 2012-06-21 Ross Medical Corporation Patient Emergency Response System
CN103578239B (zh) * 2012-07-24 2016-03-23 北京大学人民医院 严重创伤救治远程信息联动院内预警呼叫系统
CN103942454A (zh) * 2014-05-07 2014-07-23 东南大学 一种基于流动监测车的急症患者应急救援系统
CN106066931A (zh) * 2016-05-25 2016-11-02 张福林 一种主动式智能医疗急救系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106462817A (zh) * 2015-07-23 2017-02-22 深圳循证医学信息技术有限公司 一种急救分级优先调度方法及装置
CN106407703A (zh) * 2016-09-29 2017-02-15 湖南优图信息技术有限公司 一种急救中心信息管理方法及平台
US20180137250A1 (en) * 2016-11-15 2018-05-17 Hefei University Of Technology Mobile health intelligent medical guide system and method thereof
CN108986897A (zh) * 2018-07-13 2018-12-11 飞救医疗科技（北京）有限公司 一种急危重症施救的医疗资源优化匹配方法和系统

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11706604B2 (en) 2020-09-02 2023-07-18 Koninklijke Philips N.V. Responding to emergency calls

Also Published As

Publication number Publication date
CN108986897A (zh) 2018-12-11
CN108986897B (zh) 2021-01-05

Similar Documents

Publication Publication Date Title
WO2020011244A1 (zh) 一种急危重症施救的医疗资源优化匹配方法和系统
EP3255573A1 (en) Clinical decision supporting ensemble system and clinical decison supporting method using the same
US11200987B2 (en) Virtual telemedicine mechanism
US20190122770A1 (en) Lightweight Clinical Pregnancy Preterm Birth Predictive System and Method
US20220157474A1 (en) Automated susceptibility identification and alerting in infectious disease outbreaks
Okamoto et al. Profile of the ORION (Osaka emergency information Research Intelligent Operation Network system) between 2015 and 2016 in Osaka, Japan: a population‐based registry of emergency patients with both ambulance and in‐hospital records
KR102479692B1 (ko) 빅데이터 및 클라우드 시스템 기반 인공지능 응급의료 의사결정 및 응급환자 이송 시스템과 그 방법
EP4345840A1 (en) Emergency treatment system, emergency treatment method, and electronic device
US11996200B2 (en) Method, apparatus, and computer readable media for artificial intelligence-based treatment guidance for the neurologically impaired patient who may need neurosurgery
US20170024523A1 (en) Requirement Forecast for Health Care Services
Ianculescu et al. Opportunities brought by big data in providing silver digital patients with ICT-based services that support independent living and lifelong learning
JP6375080B1 (ja) 医療支援システム及び医療支援方法
Park Real-time monitoring electronic triage tag system for improving survival rate in disaster-induced mass casualty incidents
US20170351829A1 (en) Smart device for monitoring and capturing patient data
JP7122279B2 (ja) 医療機関選定サーバ及び医療機関選定方法
KR20220086186A (ko) 사용자 맞춤형 건강 관리 장치 및 방법
Levonevskiy et al. Automation of data processing for patient monitoring in the smart ward environment
Lee et al. Active treatment and shared decision-making for infants born extremely preterm at 22 to 25 weeks
Al-Qudah et al. Computer Vision-Based Architecture for IoMT Using Deep Learning
US20230307102A1 (en) Systems and Methods for Automated Identification of ST-Segment Elevation Myocardial Infarction
Massey et al. Mobile Health Systems that optimize resources in emergency response situations
US20220189637A1 (en) Automatic early prediction of neurodegenerative diseases
US20220375617A1 (en) Computerized decision support tool for preventing falls in post-acute care patients
WO2022152280A1 (zh) 病种识别方法、设备、系统及存储介质
US20230069370A1 (en) Ai-enabled access to healthcare services

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: 19834829

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19834829

Country of ref document: EP

Kind code of ref document: A1