Drug dispatch methods, systems and media for public health emergencies

Abstract

This invention provides a method, system, and medium for drug dispatching in response to public health emergencies. The method includes: acquiring characteristic data of the target event, population health data of the affected area, and real-time drug consumption data; generating an initial drug demand forecast based on the characteristic data and population health data using a first prediction model; constructing a dynamic supply-demand matching matrix based on the initial drug demand forecast and real-time inventory data from multiple reserve terminals, whereby the dynamic supply-demand matching matrix characterizes the comprehensive dispatch cost of dispatching drugs from different reserve terminals to different medical terminals; inputting the dynamic supply-demand matching matrix into a deep reinforcement learning model to generate a dynamic dispatching strategy; and issuing dispatching instructions to reserve terminals according to the dynamic dispatching strategy. This invention solves the technical problems of delayed response, supply-demand mismatch, and regional imbalance in existing technologies, significantly improving the accuracy, timeliness, and balance of emergency drug supply.

Description

Technical Field

[0001] This invention relates to the field of medical resource allocation technology, and in particular to a method, system and medium for drug allocation in response to public health emergencies. Background Technology

[0002] In recent years, with the intensification of global climate change and the frequent emergence of new infectious diseases, my country faces a continuously rising risk of public health emergencies such as earthquakes, floods, and major epidemics. During emergency response, the timely, accurate, and efficient supply of medicines, as emergency supplies, directly affects patient treatment outcomes and social stability. Multiple real-world scenarios have exposed problems such as delayed response, supply-demand mismatch, and regional imbalances.

[0003] Existing drug dispatching methods largely rely on static plans and human experience, making it difficult to cope with the highly dynamic and heterogeneous drug demand under target events. On the one hand, due to differences in population structure, underlying disease spectrum, distribution of medical resources, and disaster types, different regions exhibit significant heterogeneity in the demand structure for categories such as antipyretics, antiviral drugs, antibiotics, and chronic disease medications, while current systems lack the ability to model drug demand at a fine-grained, population-specific, and region-specific level. On the other hand, dispatching decisions are usually made based on initial forecasts in a one-time manner, failing to access actual consumption data from hospital pharmacies and primary healthcare institutions. This results in subsequent delivery plans not being dynamically adjusted according to the actual consumption rate, leading to drug stockpiles in some areas and severe shortages in others. The drug flow chain from reserves to end users is slow to respond, making it difficult to achieve rapid and accurate delivery on an hourly or daily basis, severely restricting the effectiveness of emergency medical rescue. Summary of the Invention

[0004] This invention provides a drug dispatching method, system, and medium for public health emergencies, which addresses the shortcomings of existing drug dispatching methods in accurately depicting the heterogeneous needs of regions and populations and lacking a dynamic feedback mechanism based on actual consumption data, resulting in the inability to deliver drugs quickly, efficiently, and on demand.

[0005] This invention provides a drug dispatching method for public health emergencies. The method is applied to a dispatching server, which is communicatively connected to multiple reserve terminal units and multiple medical terminals. The method includes: Acquire characteristic data of the target event, population health data of the disaster-stricken area, and real-time drug consumption data of the multiple medical terminals; Based on the feature data and the population health data, an initial drug demand forecast is generated using a first prediction model. Based on the initial drug demand forecast and the real-time inventory data of the multiple reserve terminals, a dynamic supply and demand matching matrix is ​​constructed. The dynamic supply and demand matching matrix is ​​used to characterize the comprehensive scheduling cost of dispatching drugs from different reserve terminals to different medical terminals. The dynamic supply and demand matching matrix is ​​input into a deep reinforcement learning model to generate a dynamic scheduling strategy, which includes scheduling source, scheduling category, scheduling quantity, and transportation route planning. According to the dynamic scheduling strategy, a scheduling instruction is issued to the reserve terminal, and the real-time drug consumption data updated by the medical terminal during the scheduling process is fed back to the deep reinforcement learning model.

[0006] According to the drug dispatching method for public health emergencies provided by the present invention, the method further includes: Based on the real-time drug consumption data, the initial drug demand forecast is rolled over and corrected using the second prediction model to generate a dynamic drug demand forecast. The drug demand forecast value used to construct the dynamic supply and demand matching matrix is ​​the dynamic drug demand forecast value. According to the drug dispatching method for public health emergencies provided by the present invention, the first prediction model is a heterogeneous graph neural network model. The heterogeneous graph neural network model constructs a heterogeneous graph with nodes of different regions and nodes of different populations. The nodes of different populations include at least vulnerable population nodes classified based on age distribution, gender ratio and prevalence of underlying diseases. The heterogeneous graph neural network model is used to capture the heterogeneity characteristics of drug demand in different regions and different populations.

[0007] The step of generating a dynamic drug demand forecast by continuously revising the initial drug demand forecast value using a second prediction model based on the real-time drug consumption data specifically includes: The real-time drug consumption rate of the multiple medical terminals is obtained with a preset time window as the period. The real-time drug consumption rate is input into the second prediction model, which is a time-series prediction model based on long short-term memory networks and attention mechanisms. The second prediction model is used to predict the drug consumption trend in the future period, and the initial drug demand forecast is dynamically corrected based on the drug consumption trend to obtain the dynamic drug demand forecast.

[0008] According to the drug dispatching method for public health emergencies provided by the present invention, the comprehensive dispatching cost is calculated based on the weighted average of estimated transportation time, transportation distance and route safety factor, wherein the weighting coefficients of the estimated transportation time, the transportation distance and the route safety factor can be dynamically adjusted according to the urgency of the event.

[0009] According to the drug dispatching method for public health emergencies provided by the present invention, after acquiring the characteristic data of the target event, the population health data of the disaster area, and the real-time drug consumption data of the multiple medical terminals, the method further includes: Based on the population health data and the feature data, the risk-weighted population of different populations in different regions is calculated. The risk-weighted population is used to characterize the effective population number of people with underlying diseases who face the risk of disease aggravation under the target event. The risk-weighted population is used as a feature weight and input into the first prediction model.

[0010] According to the drug dispatching method for public health emergencies provided by the present invention, the dispatching server includes a system architecture layer, which includes a demand forecasting module and a dispatching optimization module. After acquiring the characteristic data of the target event, the population health data of the disaster-stricken area, and the real-time drug consumption data of the multiple medical terminals, the method further includes: The feature data, the population health data, and the real-time drug consumption data are sent to the demand forecasting module. The initial drug demand forecast value is generated by the first forecast model in the demand forecasting module. The dynamic scheduling strategy is generated by the deep reinforcement learning model in the scheduling optimization module.

[0011] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the drug dispatching method for public health emergencies as described above.

[0012] The present invention also provides a drug dispatch system for public health emergencies, including a dispatch server as described above, and multiple reserve terminal and multiple medical terminal that are communicatively connected to the dispatch server.

[0013] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described methods for drug dispatching in response to public health emergencies.

[0014] The present invention provides a drug dispatching method, system, and medium for public health emergencies. By acquiring target event characteristic data, population health data of the affected area, and real-time drug consumption data from medical terminals, and by incorporating population health data into a first prediction model, it achieves accurate characterization of drug demand in different regions and among different populations, solving the supply-demand mismatch problem caused by neglecting differences in population structure and underlying disease spectrum in existing technologies. By constructing a dynamic supply-demand matching matrix that includes comprehensive dispatching costs and feeding real-time consumption data back to a deep reinforcement learning model, a dynamic closed-loop dispatching optimization mechanism is formed, enabling dispatching decisions to adaptively adjust according to the actual consumption rate. This overcomes the technical bottleneck of traditional dispatching relying on static plans and being unable to dynamically respond to highly dynamic demands. Through the deep reinforcement learning model, the global optimal dispatching strategy is solved in real time under multiple constraints, significantly improving the timeliness of emergency response and the balance of resource allocation, effectively solving the technical problems of response lag and regional imbalance in existing dispatching methods. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0016] Figure 1 This is a flowchart illustrating the drug dispatching method for public health emergencies provided by the present invention. Figure 2 This is a schematic diagram of the electronic device (as a scheduling server) provided by the present invention. Detailed Implementation

[0017] The technical solutions in the embodiments of this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the word "and / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0018] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0019] In the following embodiments of this application, the term "user interface" refers to the medium interface through which an application or operating system interacts and exchanges information with a user. It realizes the conversion between the internal form of information and the form that the user can accept. The most common form of user interface is the graphical user interface, which refers to a user interface related to computer operation that is displayed graphically. It can be visual interface elements such as text, icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, and widgets displayed on the screen of a scheduling server.

[0020] Currently, drug dispatch methods during public health emergencies largely rely on static plans and human experience, resulting in the following technical shortcomings: coarse-grained demand forecasting, failing to incorporate fine-grained drug demand structure modeling based on multi-dimensional data such as the type of target event, population structure of the disaster area, and underlying disease spectrum; open-loop dispatching decisions, lacking real-time integration with actual consumption data at medical terminals, and unable to dynamically adjust subsequent delivery plans based on actual consumption rates; and delayed response times, lacking precise delivery route planning that considers real-time road conditions. These problems lead to delayed response, supply-demand mismatch, and regional imbalances during emergency response, severely restricting the effectiveness of emergency medical rescue.

[0021] Therefore, this application provides a drug dispatching method for public health emergencies, applicable to emergency drug dispatching scenarios. The dispatching server can acquire feature data of the target event, population health data of the affected area, and real-time drug consumption data from multiple medical terminals; based on the feature data and population health data, it generates an initial drug demand forecast using a first prediction model; based on the initial drug demand forecast and real-time inventory data from multiple reserve terminals, it constructs a dynamic supply-demand matching matrix; it inputs the dynamic supply-demand matching matrix into a deep reinforcement learning model to generate a dynamic dispatching strategy; it issues dispatching instructions to reserve terminals according to the dynamic dispatching strategy and feeds back the real-time drug consumption data updated by the medical terminals during the dispatching process to the deep reinforcement learning model. In this way, the dispatching server can achieve accurate characterization of drug demand and dynamic optimization of dispatching, solving the technical problems of delayed response, supply-demand mismatch, and regional imbalance in the prior art.

[0022] The following describes the hardware structure of a scheduling server provided in the embodiments of this application.

[0023] In this embodiment, the scheduling server can be any of the following: a cloud server, a data center server, an edge computing node, or a dedicated scheduling and command device. For example, this application uses a dedicated scheduling and command device as an example for illustration.

[0024] The scheduling server may include: processor, memory, communication interface, bus, and display screen, etc.

[0025] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the scheduling server. In other embodiments of this application, the scheduling server may include more or fewer components, or combine some components, or split some components, or have different component arrangements.

[0026] A processor may include one or more processing units, such as a central processing unit, a graphics processing unit, an image signal processor, a controller, a memory, a digital signal processor, a baseband processor, and / or a neural network processor. These different processing units may be independent devices or integrated into one or more processors.

[0027] The controller can serve as the nerve center and command center of the scheduling server. Based on the instruction opcode and timing signals, the controller generates operation control signals to control the fetching and execution of instructions.

[0028] The processor may also include memory for storing instructions and data. In some embodiments, operation events and shortcut instructions may be stored in memory.

[0029] The wireless communication function of the dispatch server can be implemented through a communication interface. This interface may include an antenna, a mobile communication module, and a wireless communication module, providing solutions for wireless communication applications on the dispatch server, including 2G / 3G / 4G / 5G, as well as solutions for other wireless communication technologies such as Wi-Fi, Bluetooth, GPS, FM, short-range wireless communication, and infrared technology. The communication interface can be used for the dispatch server to communicate with other devices, such as storage terminal units, medical terminals, traffic management systems, and meteorological service systems, for data exchange.

[0030] The memory can be used to store executable program code, which includes instructions. The processor executes various functional applications and data processing of the scheduling server by running the instructions stored in the memory. The memory may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a given function, etc. The data storage area may store data created during the use of the scheduling server, such as a static health profile database, a dynamic feature database, a drug inventory database, a historical scheduling database, etc.

[0031] Display screens are used to show images, videos, and other data. For example, a display screen can show a visual command and dispatch platform, based on a geographic information system, which can intuitively display information such as demand heat maps, inventory distribution, progress of dispatch tasks, and supply and demand gap warnings to assist command personnel in decision-making.

[0032] A layered architecture divides software into several layers, each with a clear role and function; layers communicate with each other through software interfaces. In some embodiments, the scheduling server system is divided into four layers, from top to bottom: the application layer, the application framework layer, the runtime and system libraries, and the kernel layer.

[0033] The application layer can include a series of application packages, such as a visual command and dispatch platform, a data access platform, a resource monitoring platform, and an instruction issuance platform.

[0034] The application framework layer provides application programming interfaces and programming frameworks for the application layer's applications. The application framework layer includes some predefined functions and may include modules such as demand forecasting, scheduling optimization, data fusion, and graph generation.

[0035] The demand forecasting module generates initial and dynamic drug demand forecasts based on multimodal data. Internally, the module can integrate a first forecasting model and a second forecasting model. The first forecasting model can be a heterogeneous graph neural network model, used to capture the heterogeneous characteristics of drug demand across different regions and populations; the second forecasting model can be a time-series forecasting model based on long short-term memory networks and attention mechanisms, used to continuously adjust demand forecasts according to real-time consumption rates.

[0036] The scheduling optimization module generates dynamic scheduling strategies based on a dynamic supply-demand matching matrix. Internally, the module can integrate a deep reinforcement learning model to minimize the overall stockout rate, minimize comprehensive scheduling costs, and maximize inventory turnover. Considering constraints such as the outbound capacity of each reserve node, transportation vehicle resources, and traffic control, it outputs the optimal scheduling strategy in real time.

[0037] The data fusion module is used to acquire heterogeneous data from multiple external systems and perform preprocessing operations such as cleaning, alignment, and fusion.

[0038] The map generation module is used to calculate the risk-weighted population based on population health data and feature data, and then input the risk-weighted population as feature weights into the first prediction model.

[0039] The data processing method provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0040] Figure 1 This illustration shows a flowchart of a drug dispatching method for public health emergencies, as provided in an embodiment of this application. The method can be applied to a dispatch server, which communicates with multiple reserve terminal units and multiple medical terminals. Figure 1 As shown, the method includes, but is not limited to, the following steps: S101, The scheduling server obtains the characteristic data of the target event, the population health data of the disaster area, and the real-time drug consumption data of multiple medical terminals.

[0041] The characteristic data of the target event may include, but is not limited to: event type (earthquake, flood, infectious disease outbreak, etc.), event impact range, and event severity level (e.g., earthquake magnitude, flood level, epidemic transmission index). The data includes the event's intensity value, expected duration, spatial distribution of event intensity (e.g., earthquake intensity maps, flood inundation range, epidemic risk level distribution), and prediction of event development trends (e.g., secondary disaster warnings, epidemic transmission trend predictions). This characteristic data can be obtained in real time from external systems such as emergency command systems, meteorological service systems, earthquake monitoring systems, and disease control and prevention centers.

[0042] Population health data for disaster-stricken areas may include, but is not limited to: regional demographic data (e.g., age distribution, sex ratio, population density), prevalence of key underlying diseases (e.g., prevalence of hypertension, diabetes, cardiovascular disease, and chronic respiratory diseases), distribution of vulnerable populations (e.g., geographical distribution of the elderly aged 65 and above, children under 5 years old, pregnant women, and people with mobility impairments), and routine medication data (e.g., average monthly consumption of various chronic disease medications per person). Population health data can be retrieved from external systems such as regional health information platforms and public health databases.

[0043] Real-time drug consumption data from multiple medical terminals may include, but is not limited to: real-time drug inventory levels at each medical terminal (e.g., hospitals, community health centers, makeshift hospitals, temporary medical points, etc.), real-time consumption rates of various drugs, historical consumption curves for various drugs, and drug shortage warning information. Real-time drug consumption data can be collected and uploaded to the dispatch server in real time via IoT devices, hospital information system interfaces, RFID technology, and other methods.

[0044] In some embodiments, the scheduling server may also acquire environmental and traffic data, including but not limited to: real-time weather in the disaster area, road traffic congestion, road damage, temporary traffic control information, and bridge and tunnel access status. This data can be obtained from traffic management systems, meteorological service systems, and feedback from on-site rescue teams.

[0045] For example, taking an earthquake disaster in a certain area as an example, the characteristic data that the dispatch server can obtain includes: earthquake magnitude 7.0, epicenter location, intensity distribution map (where area X is intensity IX and area Y is intensity VIII), aftershock warning information, etc. The population health data that the dispatch server can obtain includes: the total population of area X is 50,000, of which 25% are elderly (over 65 years old), the prevalence of hypertension is 35%, and the prevalence of diabetes is 15%; the total population of area Y is 80,000, of which 18% are elderly (over 65 years old), the prevalence of hypertension is 28%, and the prevalence of diabetes is 12%. The real-time drug consumption data that the dispatch server can obtain includes: temporary medical point A at the epicenter consumed 200 sets of wound dressing medicine, 50 vials of antibiotic injection, and 30 boxes of antihypertensive drugs in the past 2 hours; rear hospital B consumed 80 boxes of antihypertensive drugs, 20 vials of insulin, and 15 boxes of cardiovascular and cerebrovascular emergency medicine in the past 2 hours.

[0046] S102. The scheduling server generates an initial drug demand forecast based on feature data and population health data through the first prediction model.

[0047] In some embodiments, the first prediction model is a heterogeneous graph neural network model. The heterogeneous graph neural network model constructs a heterogeneous graph using nodes from different regions and different population groups. The nodes from different population groups at least include vulnerable population nodes categorized based on age distribution, gender ratio, and prevalence of underlying diseases. The heterogeneous graph neural network model is used to capture the heterogeneous characteristics of drug demand across different regions and population groups.

[0048] Specifically, the process of constructing a heterogeneous graph is as follows: Node definition: Each administrative division or grid unit within the disaster-stricken area is defined as a regional node; different population categories are defined as population nodes, such as the elderly, patients with hypertension, patients with diabetes, children, pregnant women, etc.

[0049] Edge definition: The edge between a region node and a population node represents the distribution density or prevalence of that type of population in that region; the edge between region nodes represents the transportation connection between regions, the intensity of population movement, or the risk of disease transmission; the edge between population nodes represents the co-occurrence of diseases or the correlation between populations, for example, the elderly often have multiple underlying diseases.

[0050] Feature initialization: The initial features of regional nodes include the region's geographical location, total population, and medical resource carrying capacity; the initial features of population nodes include the population's drug demand patterns and disease severity.

[0051] Heterogeneous graph neural networks learn higher-order relationships between nodes through multi-layer convolution and aggregation operations, ultimately outputting the demand intensity of each drug category for each population group in each region. Specifically, for region i and drug category k, the initial predicted drug demand value... It can be represented as: Where G represents the constructed heterogeneous graph, and X represents the initial feature matrix of the nodes. This represents the mapping function of a heterogeneous graph neural network.

[0052] For example, continuing with the earthquake disaster example above, the scheduling server uses regions X and Y as region nodes and "elderly," "hypertensive patients," and "diabetic patients" as population nodes to construct a heterogeneous graph. After calculation, the heterogeneous graph neural network outputs the initial drug demand forecast: Region X needs 500 boxes of antihypertensive drugs, 200 boxes of hypoglycemic drugs, 1000 sets of wound dressing medicine, and 300 vials of antibiotic injection within the next 72 hours; Region Y needs 400 boxes of antihypertensive drugs, 150 boxes of hypoglycemic drugs, 800 sets of wound dressing medicine, and 250 vials of antibiotic injection within the next 72 hours. It can be seen that, due to the higher proportion of elderly people and the higher prevalence of hypertension in Region X, its predicted demand for antihypertensive drugs is significantly higher than that in Region Y.

[0053] S103. The scheduling server constructs a dynamic supply and demand matching matrix based on the initial drug demand forecast and real-time inventory data from multiple reserve terminals.

[0054] The dynamic supply-demand matching matrix is ​​used to characterize the overall scheduling cost of allocating medicines from different reserve warehouses to different medical terminals. The row vectors of the dynamic supply-demand matching matrix represent different reserve warehouse nodes, i.e., the suppliers, and the column vectors represent different medical terminal nodes, i.e., the demanders. The matrix elements represent the overall scheduling cost of allocating a specific medicine from a specific reserve warehouse node to a specific medical terminal.

[0055] The overall scheduling cost is calculated based on a weighted average of estimated transit time, transit distance, and route safety factor. In some embodiments, the overall scheduling cost... Calculated using the following formula: The meanings of each parameter are as follows: : Represents the comprehensive dispatch cost of transferring medicines from the i-th reserve terminal to the j-th medical terminal. The smaller the value, the lower the overall cost of the scheduling path and the higher the priority.

[0056] : Indicates the estimated travel time based on real-time traffic information, in hours or minutes. The method for obtaining the shortest travel time from i to j is as follows: The scheduling server calculates the shortest travel time from i to j using a path planning algorithm based on real-time traffic flow, road congestion, and traffic control information. For example, the normal transportation time from the primary reserve warehouse A to the temporary medical point X is 2 hours, but due to road damage requiring a detour, the real-time estimated transportation time becomes 3.5 hours.

[0057] : Indicates the transportation distance, in kilometers. This is static geographic information, which can be obtained from a geographic information system. For example, the straight-line distance from primary reserve A to temporary medical point X is 80 kilometers, while the actual road distance is 95 kilometers.

[0058] : Represents the path safety factor, with a value range of [0, 1]. The closer the value is to 1, the safer the path. The closer it is to 0, the higher the path security risk. Dynamically generated based on real-time weather conditions, road damage, and geological disaster warnings. For example, if a section of road is at risk of landslide due to aftershocks, The value is assigned to 0.3; the weather is sunny and the road is clear on a certain section of the road. The value is assigned to 0.9.

[0059] : This is a weighting coefficient that can be dynamically adjusted based on the urgency of the event. Weighting corresponding to transportation time, Weights corresponding to transportation distance The weight corresponding to path security. In the early stages of a target event, timeliness is paramount and can be set accordingly. , , This significantly increases the weighting of transportation time; in the later stages of an event, the weighting can be appropriately reduced. ,promote and The weighting is determined to control costs and ensure safety. satisfy =1.

[0060] For example, the process of constructing a dynamic supply and demand matching matrix is ​​as follows. Assume there are two reserve terminals: primary reserve A and secondary reserve B; and two medical terminals: temporary medical point X and temporary medical point Y. The real-time inventory data for each reserve is: A has 1000 boxes of antihypertensive drugs, and B has 600 boxes of antihypertensive drugs. The dynamic drug demand forecast for each medical terminal is: X needs 500 boxes of antihypertensive drugs, and Y needs 400 boxes of antihypertensive drugs.

[0061] The scheduling server calculates the overall scheduling cost for each scheduling path: From A to X: T = 3.5 hours, D = 95 kilometers, S = 0.7. Take... , , Therefore, C = 0.5 × 3.5 + 0.3 × 95 + 0.2 × (1 - 0.7) = 30.31; From A to Y: T = 2.8 hours, D = 70 kilometers, S = 0.8, then C = 0.5 × 2.8 + 0.3 × 70 + 0.2 × (1 - 0.8) = 22.44; From B to X: T = 2.0 hours, D = 45 kilometers, S = 0.9, then C = 0.5 × 2.0 + 0.3 × 45 + 0.2 × (1 - 0.9) = 14.52; From B to Y: T = 3.2 hours, D = 85 kilometers, S = 0.6, then C = 0.5 × 3.2 + 0.3 × 85 + 0.2 × (1 - 0.6) = 27.18; The dynamic supply and demand matching matrix M constructed in this way is: The first row corresponds to reserve A, the second row corresponds to reserve B; the first column corresponds to medical terminal X, and the second column corresponds to medical terminal Y.

[0062] S104. The scheduling server inputs the dynamic supply and demand matching matrix into the deep reinforcement learning model to generate a dynamic scheduling strategy.

[0063] The deep reinforcement learning model aims to minimize the overall stockout rate, minimize the comprehensive scheduling cost, and maximize the inventory turnover rate. Under constraints such as the outbound capacity of each reserve warehouse, transportation vehicle resources, and traffic control, it outputs the optimal scheduling strategy in real time. The dynamic scheduling strategy includes scheduling source, scheduling category, scheduling quantity, and transportation route planning.

[0064] The working principle of deep reinforcement learning models is as follows: State space: includes dynamic supply and demand matching matrix, real-time inventory of each reserve warehouse, real-time demand of each medical terminal, available transportation resources, real-time traffic conditions, etc.

[0065] Operational space: This includes which reserve warehouse to transfer which medicine, how much to transfer, which transportation route to choose, and what transportation method to use, such as a combination of trunk line transportation and drone last-mile delivery.

[0066] Reward function: in For reward weighting.

[0067] Learning algorithms: Deep Q-networks or policy gradients can be used to continuously optimize policy network parameters through interaction with the environment.

[0068] The deep reinforcement learning model outputs the optimal scheduling strategy. For example, in the above example, the model might output the following scheduling strategy: transfer 400 boxes of antihypertensive drugs from reserve B to medical terminal X via route BX, at a cost of 14.52; transfer 400 boxes of antihypertensive drugs from reserve A to medical terminal Y via route AY, at a cost of 22.44; and keep the remaining 100 boxes of antihypertensive drugs in reserve A as an emergency reserve. Simultaneously, the model might output a transportation plan: route BX uses a direct truck, while route AY, due to congestion in some sections, suggests using a "truck + drone" relay transportation method.

[0069] S105. The scheduling server issues scheduling instructions to the reserve terminal according to the dynamic scheduling strategy, and feeds back the real-time drug consumption data updated by the medical terminal during the scheduling process to the deep reinforcement learning model.

[0070] The scheduling server translates the generated scheduling strategy into specific scheduling instructions, which are then sent to the warehouse management and transportation management systems of the relevant reserve terminals via communication interfaces. The reserve terminals perform operations such as drug outbound processing, packaging, and loading according to the instructions. The transportation management system plans specific transportation routes based on the instructions and reports the on-transit status in real time.

[0071] Meanwhile, the scheduling server continuously receives real-time drug consumption data updated by each medical terminal. For example, after medical terminal X receives the first batch of drugs, the drug consumption rate may change; or new patients may arrive, causing a surge in demand. This updated consumption data is fed back to the deep reinforcement learning model in real time to optimize the next scheduling decision, forming a dynamic closed loop of "prediction-scheduling-consumption-feedback".

[0072] In some embodiments, the following steps are also included: S201: The scheduling server obtains the characteristic data of the target event, the population health data of the disaster area, and the real-time drug consumption data of multiple medical terminals. This step is the same as S101 and will not be described again here.

[0073] S202. The scheduling server generates initial drug demand forecasts based on feature data and population health data using the first prediction model. This step is the same as S102 and will not be described again here.

[0074] S203. Based on real-time drug consumption data, the scheduling server uses a second prediction model to continuously revise the initial drug demand forecast and generate a dynamic drug demand forecast.

[0075] In some embodiments, the second prediction model is a temporal prediction model based on long short-term memory networks and attention mechanisms. This model can capture the temporal dependence and sudden changes in drug consumption, achieving accurate short-term predictions.

[0076] Specifically, S203 may include the following sub-steps: S2031. Acquire real-time drug consumption rates from multiple medical terminals using a preset time window as the period. The preset time window can be set according to the urgency of the event and resource conditions, such as every 4 hours, every 12 hours, or every 24 hours. In the initial stage of an emergency response, a shorter time window can be set to achieve a rapid response.

[0077] S2032. Input the real-time drug consumption rate into the second prediction model. The second prediction model uses historical consumption data as training samples to learn the temporal pattern of drug consumption. The model input is the consumption rate sequence of the past N time windows, and the output is the predicted consumption rate for the next M time windows.

[0078] S2033. Predict the drug consumption trend in the future period through the second prediction model, and dynamically correct the initial drug demand forecast based on the drug consumption trend to obtain the dynamic drug demand forecast.

[0079] Dynamic correction can be achieved through weighted fusion or residual correction. For example: in, Let be the dynamic demand forecast value for drug k in region i during time period t. This is the initial demand forecast. The demand value for time period t predicted by the LSTM model (Long Short-Term Memory network). The weighting coefficients can be dynamically adjusted based on the prediction error.

[0080] For example, continuing the earthquake disaster example above. Initially, it was predicted that area X would require 500 boxes of antihypertensive medication. In step S2031, real-time consumption data was acquired every 12 hours: In the first 12 hours, area X actually consumed 200 boxes of antihypertensive medication, at a consumption rate of 16.7 boxes / hour. In step S2032, the consumption rate sequence was input into the LSTM model. In step S2033, the LSTM model predicted a consumption rate of 20 boxes / hour for the second 12 hours, meaning 240 boxes of antihypertensive medication would be needed. The scheduling server retrieves... Therefore, the dynamically revised demand forecast for the second 12 hours is 0.3 × 500 + 0.7 × 240 = 318 boxes. This value retains the overall framework of the initial forecast while being dynamically adjusted according to the actual consumption rate, making it more consistent with the actual situation.

[0081] S204. The scheduling server constructs a dynamic supply-demand matching matrix based on dynamic drug demand forecasts and real-time inventory data from multiple reserve terminals. This step is similar to S103, but the demand-side input is a dynamically corrected forecast value, making the supply-demand matching more accurate.

[0082] S205. The scheduling server inputs the dynamic supply-demand matching matrix into the deep reinforcement learning model to generate a dynamic scheduling strategy. This step is the same as S104 and will not be described again here.

[0083] S206. The scheduling server issues scheduling instructions to the reserve terminal according to the dynamic scheduling strategy, and feeds back the real-time drug consumption data updated by the medical terminal during the scheduling execution process to the deep reinforcement learning model and the second prediction model. Unlike S105, here the real-time consumption data is fed back to both the deep reinforcement learning model and the second prediction model simultaneously for online optimization and fine-tuning of the two models.

[0084] In other embodiments, a risk-weighted population calculation method is also included, which may be performed prior to S102 as an input feature enhancement for the first prediction model.

[0085] S301, The scheduling server extracts the static population number of people with underlying diseases d within region i from the population health data. .

[0086] For example, data obtained from a regional health information platform shows that the number of people with hypertension in region X is 50,000 × 35% = 17,500, and the number of people with diabetes is 50,000 × 15% = 7,500.

[0087] S302, The scheduling server extracts the severity function of event E from the feature data. .

[0088] Severity function Used to quantify the impact of a target event on public health. For earthquake disasters, It can be related to earthquake intensity, for example: IX intensity zone VIII degree zone VII degree zone Regarding infectious disease outbreaks, With the transmission index Related, for example hour , hour , hour .

[0089] For example, region X is a degree IX region. Region Y is a degree VIII zone. .

[0090] S303, The scheduling server obtains the preset event-disease risk coefficient. .

[0091] Event-Disease Risk Factor This coefficient is used to characterize the risk multiple of complications arising from an underlying disease (d) under event E. It is pre-constructed based on medical literature, historical emergency data, and expert experience, and stored in a risk knowledge base. For example: The risk multiple of stroke in hypertensive patients during earthquake events ; Increased risk of ketoacidosis in diabetic patients during earthquakes ; Increased risk of acute exacerbations in COPD patients during floods ; Increased risk of heart failure patients experiencing a flu outbreak .

[0092] S304, The scheduling server obtains the regional vulnerability correction coefficient. .

[0093] Regional vulnerability correction coefficient This is used to characterize the actual impact of factors such as regional medical resources, transportation conditions, and infrastructure on risk. For example, remote areas with scarce medical resources and inconvenient transportation... It can be set to 1.2; urban central areas with abundant medical resources and convenient transportation. It can be set to 0.8.

[0094] S305, The scheduling server calculates the risk-weighted population according to the formula. .

[0095] The calculation formula is: The formula means that the effective number of people with underlying diseases facing the risk of worsening of their condition under a target event is equal to the static population multiplied by the risk amplification factor. The risk amplification factor is determined by the severity of the event, the disease risk coefficient, and regional vulnerability.

[0096] For example, calculate the risk-weighted population of hypertensive patients in region X: Assuming region X is a mountainous area with relatively scarce medical resources, then Calculate the risk-weighted population of diabetic patients in region X: but Calculate the risk-weighted population of hypertensive patients in region Y: Assuming region Y is a plain with convenient transportation and relatively good medical resources, then S306. The scheduling server inputs the risk-weighted population as feature weights into the first prediction model.

[0097] Specifically, when constructing the heterogeneous graph, risk-weighted population is used as the feature weight of the population nodes, enabling the graph neural network to pay more attention to the drug needs of high-risk groups when aggregating information. For example, the node feature of hypertension patients in region X is no longer a simple prevalence of 17,500 people, but a risk-weighted 65,625 people, which significantly improves the predictive weight of hypertension drugs in this region.

[0098] In some embodiments, the scheduling server can also identify migration trajectories of demand hotspot areas. The dynamic demand intensity map is the output of a spatiotemporally coupled attention network, containing multiple spatiotemporal grid cells, each associated with a demand intensity vector. The process of identifying demand hotspot migration trajectories is as follows: The scheduling server generates dynamic demand intensity maps at fixed time intervals, such as every 6 hours.

[0099] For each time point in the demand intensity map, grid cells with demand intensity exceeding a preset threshold are identified as hotspot areas.

[0100] By associating and matching hotspot areas at consecutive time points, a hotspot migration trajectory can be formed.

[0101] For example, in the early stages of an infectious disease outbreak, demand is primarily concentrated in the initial outbreak area, region A. As the epidemic spreads and people move around, the demand hotspot gradually expands to surrounding regions B and C. On days 1-2, the hotspot is in region A; on days 3-4, it migrates to region B; and on days 5-6, it further migrates to region C. Once the scheduling server identifies this migration trajectory, it can proactively deploy drug resources to the predicted next hotspot region C, rather than passively waiting for shortages to occur in region C before allocating resources.

[0102] In some embodiments, the hardware and software system architecture for the scheduling server to process data may include an application layer, an application framework layer, system libraries and runtime, a kernel layer, and a hardware layer. The application layer may include a visual command and dispatch platform, a data access platform, a resource monitoring platform, and an instruction issuance platform. Commanders can view information such as demand heatmaps, inventory distribution, and scheduling task progress through the visual command and dispatch platform. The application framework layer may include a demand forecasting module, a scheduling optimization module, a data fusion module, and a graph generation module. The system libraries and runtime include core libraries, virtual machines, and system libraries such as surface managers and media libraries. The kernel layer includes communication interface drivers, display drivers, and sensor drivers. The hardware layer includes hardware devices such as processors, memory, communication interfaces, and displays.

[0103] The following section explains the collaborative relationships between the modules using a specific interaction flow.

[0104] S401, the data access platform obtains characteristic data of target events, population health data of disaster-stricken areas, and real-time drug consumption data of multiple medical terminals from external systems through communication interfaces.

[0105] S402. The data access platform sends the acquired multi-source data to the data fusion module.

[0106] S403 The data fusion module performs preprocessing operations such as cleaning, alignment, and fusion on multi-source data, and sends the preprocessed data to the map generation module and the demand forecasting module.

[0107] S404. The map generation module calculates the risk-weighted population of different groups in different regions based on population health data and feature data. The calculation process performed by the map generation module can be referred to S301 to S306.

[0108] S405. The map generation module uses the calculated risk-weighted population as feature weights and sends it to the demand forecasting module.

[0109] S406. The demand forecasting module inputs feature data, population health data, and risk-weighted population weights into the first forecasting model (heterogeneous graph neural network) to generate initial drug demand forecasts.

[0110] S407. The demand forecasting module inputs real-time drug consumption data into the second forecasting model (LSTM time series forecasting model) to perform rolling corrections on the initial drug demand forecast, generating dynamic drug demand forecasts. The demand forecasting module then sends the dynamic drug demand forecast to the scheduling optimization module.

[0111] S408: The scheduling optimization module acquires real-time inventory data from multiple reserve terminals and, combined with dynamic drug demand forecasts, constructs a dynamic supply-demand matching matrix. The scheduling optimization module then inputs this dynamic supply-demand matching matrix into a deep reinforcement learning model to generate a dynamic scheduling strategy.

[0112] S409. The scheduling optimization module sends the dynamic scheduling strategy to the instruction issuance platform.

[0113] S410, the instruction issuing platform generates specific scheduling instructions based on the dynamic scheduling strategy, and sends them to the reserve terminal and transportation management system through the communication interface.

[0114] S411 The instruction issuing platform will send the real-time feedback data obtained during the scheduling and execution process, especially the real-time drug consumption data updated by the medical terminal, back to the demand prediction module and the scheduling optimization module for online fine-tuning of the model and optimization of the strategy.

[0115] The S412 visual command and dispatch platform acquires data from various modules and displays information such as demand heatmaps, inventory distribution, scheduling task execution progress, and supply-demand gap warnings on the display screen using a graphical interface.

[0116] Through the coordinated operation of the aforementioned hardware and software systems, the scheduling server can accurately characterize drug demand and dynamically optimize scheduling, significantly improving the accuracy, timeliness, and balance of emergency drug supply.

[0117] This application also provides a drug dispatch system for public health emergencies. The system includes a dispatch server, multiple reserve terminal units, and multiple medical terminals. The dispatch server is communicatively connected to the multiple reserve terminal units and the multiple medical terminals.

[0118] The scheduling server is the execution entity of the data processing method provided in this application embodiment. Its hardware structure can be referred to above, including a processor, memory, communication interface, bus, and display screen. The scheduling server is used to execute the various steps in the method embodiments described above.

[0119] The dispatch server can be deployed in an emergency command center, a disease prevention and control center, or a third-party cloud service platform. In some embodiments, the dispatch server can adopt a distributed architecture, with multiple physical servers working together to achieve high availability and load balancing.

[0120] Reserve terminals are located in various drug reserve warehouses, including primary reserve warehouses, secondary reserve warehouses, municipal reserve warehouses, and social reserve resources. Each reserve terminal includes the following components: Inventory Management Subsystem: Used for real-time monitoring and management of drug inventory in the reserve warehouse. The inventory management subsystem includes: Radio Frequency Identification (RFID) Reader: Automatically identifies information such as the name, specifications, batch number, and expiration date of incoming medicines using RFID technology.

[0121] Inventory database: Stores real-time inventory quantities, storage locations, and expiration date warnings for medicines.

[0122] Inventory monitoring unit: When the inventory of a certain type of medicine falls below a preset threshold, it automatically generates a replenishment warning and reports it to the scheduling server.

[0123] Warehouse control subsystem: This subsystem receives scheduling instructions from the scheduling server and controls automated warehousing equipment to perform outbound operations. The warehouse control subsystem includes: Instruction receiving unit: Receives scheduling instructions issued by the scheduling server through the communication interface, and parses information such as drug type, quantity, and target medical terminal in the instructions.

[0124] Outbound control unit: controls automated warehouses, AGVs, conveyor belts and other equipment to pick designated medicines from their storage locations to the packaging area.

[0125] Packaging and labeling unit: Packs outbound medicines and generates electronic tags containing information such as target medical terminal information, estimated arrival time, and transportation route.

[0126] Communication interface: Used to interact with the scheduling server, report real-time inventory data, and receive scheduling instructions.

[0127] In some embodiments, the storage terminal also includes a temperature and humidity monitoring unit for real-time monitoring of the temperature and humidity conditions of the cold storage and cool storage facilities, ensuring the quality and safety of medicines requiring cold chain storage (such as insulin and vaccines). When the temperature and humidity exceed the set range, an alarm is automatically issued and reported to the dispatch server.

[0128] For example, the inventory management subsystem of the primary reserve warehouse shows: 1,000 boxes of antihypertensive drugs in stock, including 500 boxes of Class A antihypertensive drugs (expiring December 2026) and 500 boxes of Class B antihypertensive drugs (expiring October 2026); 2,000 vials of antibiotics in stock; and 300 vials of insulin in stock (requiring cold chain storage at 2-8℃). When the dispatch server issues the instruction to "allocate 400 boxes of antihypertensive drugs to temporary medical point X", the warehouse control subsystem automatically prioritizes allocating 400 boxes of Class B antihypertensive drugs with the closest expiration date from the inventory. These are then transported to the packing area by AGV carts. The packing and labeling unit generates electronic tags with information including: destination "temporary medical point X", estimated transportation time 3.5 hours, and transportation route "G5-G4218-county road-temporary access road".

[0129] Medical terminals are installed in various medical institutions, including hospitals, community health centers, makeshift hospitals, temporary medical points, and mobile medical vehicles. Each medical terminal includes the following components: Consumption Monitoring Subsystem: Used for real-time collection and reporting of drug consumption data. The consumption monitoring subsystem includes: Smart medicine cabinet: Equipped with weight sensors and RFID readers, it automatically records information such as the time of retrieval, type of medicine, and amount of medicine when medical staff take medicine.

[0130] Hospital Information System Interface: Connects with the HIS system of medical institutions to obtain prescription data, inpatient medication data, outpatient medication data, etc.

[0131] Consumption data reporting unit: Reports data such as drug consumption rate and current inventory to the scheduling server at preset time intervals (e.g., every 1 hour, every 4 hours) or in real-time triggering mode.

[0132] Demand Early Warning Subsystem: This subsystem automatically generates demand early warnings based on current inventory and consumption rates. The demand early warning subsystem includes: Consumption Trend Analysis Unit: Based on historical consumption data, analyze the temporal patterns of drug consumption, such as daily peak periods and holiday fluctuations.

[0133] Inventory warning unit: When the estimated remaining availability time (current inventory / average consumption rate) of a certain type of medicine is lower than a preset threshold, an out-of-stock warning is automatically generated and reported to the scheduling server.

[0134] Emergency Call Unit: In the event of an emergency such as a large influx of injured people, medical personnel can send an emergency request signal to the dispatch server through the one-click call function.

[0135] Receiving Confirmation Subsystem: Used to confirm the receipt of dispatched medicines. The receiving confirmation subsystem includes: Arrival Scanning Unit: When the transport vehicle arrives at the medical terminal, medical staff scan the electronic tag on the medicine packaging using a handheld terminal or a fixed reader to confirm receipt.

[0136] Quality Inspection Unit: Performs visual inspection and quantity verification on incoming medicines. If damage, expiration, or quantity discrepancies are found, it sends an anomaly report to the scheduling server through the receiving confirmation subsystem.

[0137] Warehouse registration unit: Registers the received drug information into the warehouse and updates the inventory data of the smart medicine cabinet.

[0138] Communication interface: Used to interact with the scheduling server, report real-time consumption data, and receive scheduling instruction confirmation information.

[0139] For example, the medical terminal consumption monitoring subsystem of temporary medical point X shows that 200 sets of wound dressing medicine, 50 vials of antibiotic injection, and 30 boxes of antihypertensive drugs were consumed in the past 2 hours. The current inventory of the smart medicine cabinet is: 100 sets of wound dressing medicine remaining (estimated remaining time: 5 hours), and 80 vials of antibiotic injection remaining (estimated remaining time: 3.2 hours). The inventory warning unit automatically generates a warning: "Insufficient antibiotic injection inventory, estimated remaining time less than 4 hours," and reports the warning information to the dispatch server.

[0140] Figure 2 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 2 As shown, the electronic device is a dispatch server, which may include: a processor 810, a communication interface 820, a memory 830, and a communication bus 840. The processor 810, communication interface 820, and memory 830 communicate with each other via the communication bus 840. The processor 810 can call logical instructions in the memory 830 to execute a drug dispatching method for public health emergencies.

[0141] Furthermore, the logical instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0142] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer is able to execute the drug dispatching method for public health emergencies provided by the above methods.

[0143] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the drug dispatching methods for public health emergencies provided by the methods described above.

[0144] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0145] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0146] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A drug dispatching method for public health emergencies, characterized in that, The method is applied to a scheduling server, which is communicatively connected to multiple reserve terminal units and multiple medical terminals. The method includes: Acquire characteristic data of the target event, population health data of the disaster-stricken area, and real-time drug consumption data of the multiple medical terminals; Based on the feature data and the population health data, an initial drug demand forecast is generated using a first prediction model. Based on the initial drug demand forecast and real-time inventory data from multiple reserve terminals, a dynamic supply and demand matching matrix is ​​constructed. The dynamic supply and demand matching matrix is ​​used to characterize the comprehensive scheduling cost of dispatching drugs from different reserve terminals to different medical terminals. The dynamic supply and demand matching matrix is ​​input into a deep reinforcement learning model to generate a dynamic scheduling strategy, which includes scheduling source, scheduling category, scheduling quantity, and transportation route planning. According to the dynamic scheduling strategy, a scheduling instruction is issued to the reserve terminal, and the real-time drug consumption data updated by the medical terminal during the scheduling process is fed back to the deep reinforcement learning model.

2. The drug dispatching method for public health emergencies according to claim 1, characterized in that, The method further includes: Based on the real-time drug consumption data, the initial drug demand forecast is continuously revised using the second prediction model to generate a dynamic drug demand forecast. The drug demand forecast value on which the construction of the dynamic supply and demand matching matrix is ​​based is the dynamic drug demand forecast value.

3. The drug dispatching method for public health emergencies according to claim 1 or 2, characterized in that, The first prediction model is a heterogeneous graph neural network model. The heterogeneous graph neural network model constructs a heterogeneous graph with nodes from different regions and different populations. The nodes from different populations include at least vulnerable population nodes classified based on age distribution, gender ratio, and prevalence of underlying diseases. The heterogeneous graph neural network model is used to capture the heterogeneous characteristics of drug demand in different regions and different populations.

4. The drug dispatching method for public health emergencies according to claim 2, characterized in that, The step of generating a dynamic drug demand forecast by continuously revising the initial drug demand forecast value using a second prediction model based on the real-time drug consumption data specifically includes: The real-time drug consumption rate of the multiple medical terminals is obtained with a preset time window as the period. The real-time drug consumption rate is input into the second prediction model, which is a time-series prediction model based on long short-term memory networks and attention mechanisms. The second prediction model is used to predict the drug consumption trend in the future period, and the initial drug demand forecast is dynamically corrected based on the drug consumption trend to obtain the dynamic drug demand forecast.

5. The drug dispatching method for public health emergencies according to claim 1, characterized in that, The overall scheduling cost is calculated based on a weighted average of estimated transport time, transport distance, and route safety factor, wherein the weighting coefficients of the estimated transport time, transport distance, and route safety factor can be dynamically adjusted according to the urgency of the event.

6. The drug dispatching method for public health emergencies according to claim 1, characterized in that, After acquiring the characteristic data of the target event, the population health data of the disaster-stricken area, and the real-time drug consumption data of the multiple medical terminals, the method further includes: Based on the population health data and the feature data, the risk-weighted population of different populations in different regions is calculated. The risk-weighted population is used to characterize the effective population number of people with underlying diseases who face the risk of disease aggravation under the target event. The risk-weighted population is used as a feature weight and input into the first prediction model.

7. The drug dispatching method for public health emergencies according to claim 1, characterized in that, The scheduling server includes a system architecture layer, which comprises a demand forecasting module and a scheduling optimization module. After acquiring the characteristic data of the target event, the population health data of the disaster-stricken area, and the real-time drug consumption data of the multiple medical terminals, the method further includes: The feature data, the population health data, and the real-time drug consumption data are sent to the demand forecasting module. The initial drug demand forecast value is generated by the first forecast model in the demand forecasting module. The dynamic scheduling strategy is generated by the deep reinforcement learning model in the scheduling optimization module.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the drug dispatching method for public health emergencies as described in any one of claims 1 to 7.

9. A drug dispatch system for public health emergencies, characterized in that, It includes the scheduling server as described in claim 8, as well as multiple reserve terminals and multiple medical terminals that are communicatively connected to the scheduling server.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the drug dispatching method for public health emergencies as described in any one of claims 1 to 7.

Images