Dynamic dispatching system and method for emergency multi-region human resources

Abstract

This application provides a dynamic human resource scheduling system and method for multiple emergency areas, which can be applied to the fields of smart healthcare and scheduling optimization technology. The system includes: a data acquisition module configured to acquire object traffic data from the medical system in the data source layer of the hospital's emergency department; a traffic prediction module configured to statistically analyze and sample the object traffic data to obtain the object arrival rate of the object traffic at the target service node; a traffic early warning module configured to determine the queue load of the target service node based on the object arrival rate and the comprehensive service capacity of the target service node; and a resource scheduling module configured to determine the human resource scheduling strategy for the target area based on the queue load.

Description

Technical Field

[0001] This application relates to the field of smart healthcare and scheduling optimization, specifically to a dynamic scheduling system and method for human resources in multiple emergency areas. Background Technology

[0002] Hospitals generally use information systems to record patient flow and visit volume data in various treatment areas and service nodes. Based on the above data, only basic statistical methods are needed to achieve simple statistics on the flow of people in each area and static resource allocation. The above processing method has been widely used in the daily operation and maintenance management of outpatient, emergency and other areas, becoming the basic technical support for hospital operation and management.

[0003] In the process of implementing this application, it was found that the relevant technology has at least the following problems: queuing in hospital emergency rooms is more common and more difficult to predict. The human resource management model for emergency rooms mostly adopts static configuration and post-event handling, relying solely on the current real-time flow of people for resource allocation. Usually, the response is only made after the flow of people becomes congested, which causes a delay in dynamic resource management and affects the stability of regional service operation. Summary of the Invention

[0004] In view of the above problems, this application provides a dynamic scheduling system and method for human resources in multiple areas of emergency departments.

[0005] According to a first aspect of this application, a dynamic human resource scheduling system for multiple areas of an emergency department is provided, comprising: a data acquisition module configured to acquire object traffic data of a hospital emergency department from a medical system in a data source layer, the object traffic data including the arrival times of multiple objects at service nodes, the service nodes including a target service node corresponding to a target area and an upstream service node upstream of the target service node; and a traffic prediction module configured to perform statistical analysis and sampling on the object traffic data to obtain the object arrival rate of the target service node, wherein the object arrival rate is a traffic prediction value of the object traffic of the target service node, and the object arrival rate is based on the number of first objects, the number of second objects, and the upstream node traffic. The quantities are determined by sampling the traffic data of the target service node using a first sliding window and a second sliding window, respectively. The width of the first sliding window is greater than the width of the second sliding window. The upstream node traffic is determined based on the object conversion time of the upstream service node, which represents the time required for an object to travel from the upstream service node to the target service node. The traffic early warning module is configured to determine the queue load of the target service node based on the object arrival rate and the comprehensive service capacity of the target service node. The comprehensive service capacity is determined based on the number of service stations configured on the target service node. The resource scheduling module is configured to determine the human resource scheduling strategy for the target area based on the queue load.

[0006] According to an embodiment of this application, the dynamic scheduling system for human resources in multiple emergency areas further includes: a baseline parameter calculation module, configured to obtain historical object traffic data of the hospital's emergency department from the medical system, and determine baseline service parameters based on the historical object traffic data. The baseline service parameters include the comprehensive service capability of the target service node and the object conversion time between the upstream service node and the target service node. The comprehensive service capability represents the efficiency of the target service node in providing services to objects.

[0007] According to an embodiment of this application, the historical object traffic data includes the arrival times of multiple historical objects at service nodes and the departure times of multiple historical objects from service nodes. The baseline parameter calculation module includes: a service parameter calculation submodule, configured to determine the basic service rate per unit resource based on the historical traffic data of the target service node, the historical resource quantity corresponding to the historical traffic data, and the service efficiency data of serving the historical traffic data with the historical resource quantity, and to determine the comprehensive service capability based on the number of service stations and the basic service rate; and a conversion duration calculation submodule, configured to determine the first historical moment when the historical object receives service at the upstream service node based on the historical traffic data of the upstream service node, determine the second historical moment when the historical object receives service at the target service node based on the historical traffic data of the target service node, and determine the object conversion duration based on the time difference between the first historical moment and the second historical moment.

[0008] According to an embodiment of this application, the traffic prediction module includes: an object quantity sampling submodule, configured to use a first sliding window, with the current time as the lower limit of the window, to define a first sampling time range, and to use the number of objects in the object traffic data of the target service node within the first sampling time range as the first object quantity; and to use a second sliding window, with the current time as the lower limit of the window, to define a second sampling time range, and to use the number of objects in the object traffic data of the target service node within the second sampling time range as the second object quantity; an upstream traffic calculation submodule, configured to use the first object quantity and the second object quantity to determine the upstream arrival quantity, and to determine the upstream node traffic based on the upstream arrival quantity and the object conversion time; and a traffic prediction submodule, configured to determine a traffic fusion weight based on the object conversion time, the upstream node traffic, and a preset traffic threshold, and to fuse the first object quantity and the second object quantity based on the traffic fusion weight to obtain the object arrival rate.

[0009] According to an embodiment of this application, the traffic prediction submodule includes: a first weight judgment unit configured to use the current fusion weight as the traffic fusion weight when the upstream node traffic is less than or equal to a preset traffic threshold; a second weight judgment unit configured to determine a first weight adjustment range based on the difference between the upstream node traffic and the preset traffic threshold when the upstream node traffic is greater than the preset traffic threshold; an object quantity deviation calculation unit configured to determine a quantity deviation rate based on a first object quantity and a second object quantity, and to determine a second weight adjustment range based on the object deviation rate; and a weight adjustment unit configured to adjust the current fusion weight according to the first weight adjustment range and the second weight adjustment range to obtain the traffic fusion weight.

[0010] According to an embodiment of this application, the data acquisition module includes: a data maintenance submodule, configured to communicate with a medical system, acquire event data generated by the medical system, perform structured processing on the event data to obtain object traffic data, the medical system including a hospital information system, an emergency triage system, and a nursing mobile terminal; a network construction submodule, configured to construct a service topology between multiple service nodes based on the business relationships between multiple hospital emergency areas, the multiple service nodes corresponding one-to-one with multiple hospital emergency areas, the service topology including multiple service nodes and directed edges between multiple service nodes, the service node corresponding to the starting point of the directed edge is the upstream node of the service node corresponding to the ending point of the directed edge; and a data acquisition submodule, configured to determine the upstream service node of the target service node based on the target area and the service topology, and provide object traffic data related to the target service node and the upstream service node respectively.

[0011] According to an embodiment of this application, the resource scheduling module includes: a load comparison submodule, configured to determine the current load level of the target service node based on queue load and load threshold; and a strategy formulation submodule, configured to determine the human resource scheduling strategy for the target service node based on the load level.

[0012] According to an embodiment of this application, the load comparison submodule includes: a first load determination unit configured to set the load level to a first level when the queue load is within a first load interval; a second load determination unit configured to set the load level to a second level when the queue load is within a second load interval; a third load determination unit configured to set the load level to a third level when the queue load is within a third load interval; and a fourth load determination unit configured to set the load level to a fourth level when the queue load is within a fourth load interval, wherein the first load interval, the second load interval, the third load interval, and the fourth load interval are determined based on load thresholds.

[0013] According to an embodiment of this application, the strategy formulation submodule includes: a first strategy formulation unit configured to display the load level on the front-end page and suggest maintaining the number of service desks unchanged when the load level is at level one; a second strategy formulation unit configured to display the load level on the front-end page and remind administrators to pay attention to the number of service desks and object arrival rate when the load level is at level two; a third strategy formulation unit configured to display the load level, alarm information, and pending resource quantity on the front-end page when the load level is at level three, so that administrators can perform resource management based on the pending resource quantity, which is determined based on queue load, load threshold, and comprehensive service capacity; and a fourth strategy formulation unit configured to display the load level, alarm information, and buffered resource quantity on the front-end page when the load level is at level four, so that administrators can perform resource management based on the buffered resource quantity, which is determined based on the pending resource quantity and a pre-set emergency resource quantity.

[0014] The second aspect of this application provides a method for dynamic scheduling of human resources in multiple areas of an emergency department, comprising: determining the target areas in the hospital's emergency department that require resource management; inputting the target areas into the aforementioned dynamic scheduling system for human resources in multiple areas of an emergency department to obtain a human resource scheduling strategy for the target areas.

[0015] A third aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0016] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0017] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method.

[0018] According to embodiments of this application, a closed-loop management system is formed through multi-module collaboration to collect time-series data on passenger flow from upstream and downstream service nodes. Sampling is performed using dual sliding windows of different widths, taking into account both short-term fluctuations and long-term trends in passenger flow. The system also incorporates the impact of upstream passenger flow transmission by factoring in the time it takes for passengers to transfer between nodes, thus improving the accuracy of flow prediction. The system quantifies queue load by combining the comprehensive service capacity corresponding to the existing resources of the target service node, and outputs human resource scheduling strategies based on the load status. This allows for the early identification of regional operational pressure, enabling dynamic pre-allocation of resources across multiple regions, effectively balancing the load of each region, and improving resource utilization and the stability of regional service operations. Attached Figure Description

[0019] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments of this application with reference to the accompanying drawings.

[0020] Figure 1 The diagram illustrates an application scenario of a dynamic scheduling system and method for human resources in multiple emergency areas, according to an embodiment of this application.

[0021] Figure 2 An architecture diagram of a dynamic scheduling system for human resources in multiple emergency areas according to an embodiment of this application is shown.

[0022] Figure 3A A schematic diagram illustrating the business relationships between multiple hospital emergency areas according to an embodiment of this application is shown.

[0023] Figure 3B A schematic diagram of a service topology according to an embodiment of this application is shown.

[0024] Figure 4 A flowchart of a method for dynamic scheduling of human resources in multiple emergency areas according to an embodiment of this application is shown.

[0025] Figure 5 A block diagram of an electronic device suitable for implementing a dynamic scheduling system and method for human resources in multiple emergency areas, according to an embodiment of this application, is shown. Detailed Implementation

[0026] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0027] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0028] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0029] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0030] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, application, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0031] In scenarios involving automated decision-making using personal information, the methods, devices, and systems provided in this application all offer users corresponding entry points for choosing to agree to or reject the automated decision-making results. If the user chooses to reject, the process proceeds to the expert decision-making stage. Here, "automated decision-making" refers to the activity of automatically analyzing and evaluating an individual's behavioral habits, interests, or economic, health, and credit status through computer programs, and then making a decision. Here, "expert decision-making" refers to the activity of making decisions by personnel who specialize in a particular field, possess specialized experience, knowledge, and skills, and have reached a certain level of professional expertise.

[0032] This application provides an embodiment of a dynamic human resource scheduling system for multiple emergency areas, comprising: a data acquisition module configured to acquire object traffic data of the hospital's emergency department from a medical system in the data source layer, the object traffic data including the arrival times of multiple objects at service nodes, the service nodes including a target service node corresponding to the target area and an upstream service node upstream of the target service node; and a traffic prediction module configured to statistically analyze and sample the object traffic data to obtain the object arrival rate of the target service node, wherein the object arrival rate is the predicted traffic value of the object traffic of the target service node, and the object arrival rate is determined based on the number of first objects, the number of second objects, and the traffic of the upstream node. The number of objects and the number of objects are obtained by sampling the traffic data of the target service node using a first sliding window and a second sliding window, respectively. The width of the first sliding window is greater than the width of the second sliding window. The upstream node traffic is determined based on the object conversion time of the upstream service node, which represents the time required for an object to travel from the upstream service node to the target service node. The traffic early warning module is configured to determine the queue load of the target service node based on the object arrival rate and the comprehensive service capacity of the target service node. The comprehensive service capacity is determined based on the number of service stations configured on the target service node. The resource scheduling module is configured to determine the human resource scheduling strategy for the target area based on the queue load.

[0033] Figure 1 The diagram illustrates an application scenario of a dynamic scheduling system and method for human resources in multiple emergency areas, according to an embodiment of this application.

[0034] like Figure 1 As shown, application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0035] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103.

[0036] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0037] Server 105 can be a server that provides various services, such as a backend management server that supports the pages browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as human resource scheduling strategies calculated based on user requests) to the terminal devices.

[0038] It should be noted that the dynamic scheduling system for emergency multi-area human resources provided in this application embodiment can generally be set up in server 105. Correspondingly, the dynamic scheduling system for emergency multi-area human resources provided in this application embodiment can generally be executed by server 105. The dynamic scheduling device for emergency multi-area human resources provided in this application embodiment can also be set up in a server or server cluster that is different from server 105 and can communicate with the first terminal device 101, the second terminal device 102, the third terminal device 103 and / or server 105. Correspondingly, the dynamic scheduling method for emergency multi-area human resources provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and can communicate with the first terminal device 101, the second terminal device 102, the third terminal device 103 and / or server 105.

[0039] It should be understood that Figure 1 The number of first terminal devices, second terminal devices, third terminal devices, networks, and servers shown in the diagram is merely illustrative. Depending on implementation needs, any number of first terminal devices, second terminal devices, third terminal devices, networks, and servers can be included.

[0040] Figure 2 An architecture diagram of a dynamic scheduling system for human resources in multiple emergency areas according to an embodiment of this application is shown.

[0041] like Figure 2 As shown, the dynamic scheduling system 200 for emergency multi-area human resources in this embodiment includes a data acquisition module 210, a traffic prediction module 220, a traffic early warning module 230, and a resource scheduling module 240.

[0042] The data acquisition module 210 is configured to obtain object traffic data of the hospital emergency department from the medical system in the data source layer. The object traffic data includes the arrival time of multiple objects at the service nodes. The service nodes include the target service node corresponding to the target area and the upstream service node located upstream of the target service node.

[0043] The traffic prediction module 220 is configured to statistically analyze and sample object traffic data to obtain the object arrival rate of the target service node. The object arrival rate is the predicted value of the object traffic of the target service node. The object arrival rate is determined based on the number of first objects, the number of second objects, and the traffic of the upstream node. The number of first objects and the number of second objects are obtained by sampling the traffic data of the target service node using a first sliding window and a second sliding window, respectively. The width of the first sliding window is greater than the width of the second sliding window. The traffic of the upstream node is determined based on the object conversion time of the upstream service node. The object conversion time represents the time required for an object to travel from the upstream service node to the target service node.

[0044] The traffic warning module 230 is configured to determine the queue load of the target service node based on the object arrival rate and the comprehensive service capability of the target service node. The comprehensive service capability is determined according to the number of service stations configured on the target service node.

[0045] The resource scheduling module 240 is configured to determine the human resource scheduling strategy for the target area based on queue load.

[0046] The medical system may include hospital information systems, emergency triage systems, and mobile nursing terminals used to record medical records and queue numbers. The target population may include patients visiting the hospital's emergency department. Service nodes may include triage areas, various departments that issue medical orders (e.g., internal medicine clinics, surgical clinics, pediatric clinics), and rooms for performing various nursing procedures (e.g., blood collection rooms, injection rooms).

[0047] The target service node represents the node corresponding to the target area that needs to be predicted and managed for resources. The upstream service node represents the node corresponding to the upstream area of ​​the target area. The upstream area represents the area that the object must pass through or reach before reaching the target area. For example, before the object reaches the injection room for injection, it needs to be diagnosed in various departments that issue medical orders. Therefore, the upstream area of ​​the injection room can include various departments that issue medical orders.

[0048] By using the first and second sliding windows to statistically analyze and sample the object traffic data of the target service node, the first number of objects and the second number of objects of the target service node can be obtained. Since the width of the first sliding window is greater than the width of the second sliding window, the first number of objects can collect the number of users over a longer period of time, thereby stabilizing the baseline of the object arrival rate. The second number of objects can capture recent instantaneous peaks, thereby making the object arrival rate more sensitive.

[0049] By statistically analyzing and sampling the object traffic data of upstream service nodes, we can obtain the upstream node traffic of upstream service nodes. Based on the time when an object arrives at the upstream service node and the time required for the object to travel from the upstream service node to the target service node, we can predict the time when an object arrives at the target service node, and thus predict the number of objects arriving at the target service node at each time.

[0050] The first and second object counts are the number of objects arriving at the target service node, which are observed and counted in real time. The upstream node traffic is the number of objects arriving at the target service node, which is predicted. Based on the number of objects from different channels, the object traffic to the target service node can be accurately calculated to obtain the object arrival rate.

[0051] The number of service counters configured at the target service node can be determined based on the human resources available at the target service node. The human resources available at the target service node include the number of service personnel currently present in the target area, such as the number of nurses in the injection room.

[0052] The overall service capacity of a target service node can represent the number of objects that the target service node can serve per unit of time. Therefore, based on the object arrival rate and the overall service capacity, the time required for the target service node to process the number of objects corresponding to the object arrival rate can be determined. This time can be used to reflect the queuing situation of objects at the target service node, i.e., the queue load.

[0053] Based on queue load, a human resource scheduling strategy for the target area can be determined. The human resource scheduling strategy may include increasing the amount of resources in the target area, maintaining the amount of resources in the target area unchanged, or decreasing the amount of resources in the target area.

[0054] According to embodiments of this application, a closed-loop management system is formed through multi-module collaboration to collect time-series data on passenger flow from upstream and downstream service nodes. Sampling is performed using dual sliding windows of different widths, taking into account both short-term fluctuations and long-term trends in passenger flow. The system also incorporates the impact of upstream passenger flow transmission by factoring in the time it takes for passengers to transfer between nodes, thus improving the accuracy of flow prediction. The system quantifies queue load by combining the comprehensive service capacity corresponding to the existing resources of the target service node, and outputs human resource scheduling strategies based on the load status. This allows for the early identification of regional operational pressure, enabling dynamic pre-allocation of resources across multiple regions, effectively balancing the load of each region, and improving resource utilization and the stability of regional service operations.

[0055] According to an embodiment of this application, the data acquisition module includes: a data maintenance submodule, configured to communicate with the medical system, acquire event data generated by the medical system, and perform structured processing on the event data to obtain object traffic data; a network construction submodule, configured to construct a service topology between multiple service nodes based on the business relationships between multiple hospital emergency areas, wherein the multiple service nodes correspond one-to-one with the multiple hospital emergency areas, and the service topology includes multiple service nodes and directed edges between the multiple service nodes, wherein the service node corresponding to the starting point of the directed edge is the upstream node of the service node corresponding to the ending point of the directed edge; and a data acquisition submodule, configured to determine the upstream service node of the target service node based on the target area and the service topology, and provide object traffic data related to the target service node and the upstream service node respectively.

[0056] The data maintenance submodule communicates with the medical system. When a new event occurs in the medical system, the medical system will synchronously push the event data to the data maintenance submodule. The data maintenance submodule can also perform structured processing on the event data to unify the format of data recorded by different medical systems according to different standards, facilitating subsequent analysis and statistics.

[0057] For example, the event data recorded by the data system in an internal medicine clinic might include a patient's start time at 10:20, end time at 10:40, and a subsequent event recorded as an intramuscular injection. By structuring this event data, we can obtain the patient's arrival time at the service node as 10:20, departure time as 10:40, and the next service node the patient needs to proceed to after leaving the current service node as the injection room.

[0058] The network construction submodule stores the business relationships between multiple hospital emergency areas. These business relationships can include the upstream and downstream order of multiple hospital emergency areas. For example, after receiving medical advice, a patient needs to pick up medication at the outpatient pharmacy and then go to the injection room for intramuscular injection. Therefore, the downstream area of ​​the internal medicine clinic can include the outpatient pharmacy, and the downstream area of ​​the outpatient pharmacy can include the injection room.

[0059] Figure 3A A schematic diagram illustrating the business relationships between multiple hospital emergency areas according to an embodiment of this application is shown.

[0060] like Figure 3A As shown, the hospital's emergency area includes a triage area, internal medicine departments, surgical departments, pediatric departments, an emergency pharmacy, an injection room, and an infusion room.

[0061] Figure 3AThe business relationships shown indicate that after arriving at the triage area, the patient will be directed to one of the following departments: internal medicine, surgery, or pediatrics. After being diagnosed by the above department, the patient will arrive at the emergency pharmacy. After arriving at the emergency pharmacy, the patient will proceed to the injection room or infusion room.

[0062] Multiple hospital emergency areas are represented as service nodes. Based on the above business relationships, the service nodes are sorted topologically, and directed edges are used to connect service nodes with upstream and downstream relationships to obtain the service topology among the multiple service nodes.

[0063] Figure 3B A schematic diagram of a service topology according to an embodiment of this application is shown.

[0064] like Figure 3B As shown, the service topology includes service nodes 301 to 307, and service nodes 301 to 307 are connected to... Figure 3A The triage area, internal medicine department, surgery department, pediatrics department, emergency pharmacy, injection room, and infusion room are all located in the hospital.

[0065] according to Figure 3A The business relationships shown can be used to connect multiple service nodes in the upstream and downstream order between multiple hospital emergency areas using directed edges, thus obtaining the service topology. Taking service nodes 305 and 306 as examples, service node 305 corresponds to the emergency pharmacy, and service node 306 corresponds to the injection room. According to the business relationships, it can be determined that the object arrives at the emergency pharmacy and then arrives at the injection room. Therefore, the directed edge points from service node 305 to service node 306.

[0066] After determining the target region, the target service node and its upstream service node can be identified from the service topology based on the correspondence between service regions and service nodes. Using the data acquisition submodule, the relevant object traffic data for both the target service node and its upstream service node can be obtained from the data maintenance submodule.

[0067] According to embodiments of this application, the data acquisition module can complete the entire process of data structuring, service topology construction, and upstream and downstream node matching. It interfaces with multiple medical systems and transforms raw event data into standard traffic data; it builds service topologies based on business relationships, clarifying the upstream and downstream connections of each region and node; and it accurately matches target nodes and their upstream nodes based on topological relationships, ensuring a high degree of matching between the collected data and the business architecture, thus achieving orderly collection of traffic data from multiple regions and nodes.

[0068] According to an embodiment of this application, the dynamic scheduling system for human resources in multiple emergency areas further includes: a baseline parameter calculation module, configured to obtain historical object traffic data of the hospital's emergency department from the medical system, and determine baseline service parameters based on the historical object traffic data. The baseline service parameters include the comprehensive service capability of the target service node and the object conversion time between the upstream service node and the target service node. The comprehensive service capability represents the efficiency of the target service node in providing services to objects.

[0069] The data acquisition module can obtain historical object traffic data from the medical system and provide it to the baseline parameter calculation module. The baseline parameter calculation module can statistically analyze the historical object traffic data to obtain baseline service parameters.

[0070] According to an embodiment of this application, the historical object traffic data includes the arrival times of multiple historical objects at service nodes and the departure times of multiple historical objects from service nodes. The baseline parameter calculation module includes: a service parameter calculation submodule, configured to determine the basic service rate per unit resource based on the historical traffic data of the target service node, the historical resource quantity corresponding to the historical traffic data, and the service efficiency data of serving the historical traffic data with the historical resource quantity, and to determine the comprehensive service capability based on the number of service stations and the basic service rate; and a conversion duration calculation submodule, configured to determine the first historical moment when the historical object receives service at the upstream service node based on the historical traffic data of the upstream service node, determine the second historical moment when the historical object receives service at the target service node based on the historical traffic data of the target service node, and determine the object conversion duration based on the time difference between the first historical moment and the second historical moment.

[0071] Historical traffic data for the target service node can include the number of objects served by the target service node. The historical resource quantity corresponding to the historical traffic data represents the amount of resources the target service node possesses when providing services to the objects corresponding to the historical traffic data. Service efficiency data for serving historical traffic data using historical resource quantity can be used to represent the time required for the target service node to serve historical traffic data using historical resource quantity.

[0072] The service parameter calculation submodule can determine the basic service rate per unit of resources for the target service node based on the aforementioned historical object traffic data. Taking the injection room as an example, the unit of resources represents one nurse, and the basic service rate represents the number of injection tasks that one nurse can handle in one hour.

[0073] According to embodiments of this application, an upstream service node typically refers to a service node directly connected to the target service node via a directed edge, in order to Figure 3BTaking service node 305 as an example, its upstream service nodes include service node 302, service node 303 and service node 304.

[0074] Although service node 301 is also located upstream of service node 305 in the service topology, the data of service node 301 overlaps with the data of service nodes 302, 303 and 304, which affects the accuracy of traffic data prediction for service node 305.

[0075] Therefore, if object traffic data of upstream service nodes directly connected to the target service node via directed edges can be obtained, calculations and predictions are performed only based on this portion of upstream service node object traffic data. If object traffic data of upstream service nodes directly connected to the target service node via directed edges cannot be obtained, then data of the respective upstream service nodes of the aforementioned upstream service nodes are obtained to calculate the object arrival rate of the target service node.

[0076] The conversion time calculation submodule can determine the object conversion time based on the first historical moment when the historical object receives service at the upstream service node and the second historical moment when the historical object receives service at the target service node, and based on the time difference between the first historical moment and the second historical moment. That is, how long it takes for the historical object to reach the target service node after receiving service at the upstream service node.

[0077] According to embodiments of this disclosure, for clinic service nodes, the baseline service rate can be inferred from the clinic's historical annual patient visits, 90th percentile busy day service volume, and 85% effective medical staff working hours. For injection room service nodes, the baseline service rate can be calculated by weighting the standard operating hours of each operation with the historical operation percentage, wherein the standard operating hours can be determined based on the injection room node's historical patient flow data or industry regulations. For infusion room service nodes, the baseline service rate can be determined based on the standard operating time for intravenous infusion, wherein the standard operating time can be determined based on the infusion room node's historical patient flow data or industry regulations.

[0078] According to another embodiment of this disclosure, the baseline service rate of each service node can also be set differently according to the day shift and night shift of medical staff. The baseline service rate can be updated periodically, for example, by acquiring new historical object traffic data every quarter and calculating and updating the baseline service rate.

[0079] According to the embodiments of this application, a benchmark parameter calculation module is used to automatically solve for two core benchmark parameters—comprehensive service capacity and object conversion time between upstream and downstream nodes—based on historical traffic data of the hospital's emergency department. Parameter calibration is completed using real historical data, replacing manual experience-based assignment, ensuring that the benchmark parameters closely match the actual operating conditions of the hospital's emergency department, and providing an accurate and reliable basis for subsequent traffic prediction and load calculation. Based on historical entry and exit times, resource volume, and service efficiency data, the unit resource service efficiency is first calculated, and then the comprehensive service capacity is obtained by combining the number of service stations; the object conversion time is accurately calculated through the service time difference between upstream and downstream nodes. The two types of benchmark parameters are solved in a refined manner across multiple dimensions, and the calculation logic closely matches the actual process of patient flow and service operation, further improving the accuracy of the benchmark parameters.

[0080] According to an embodiment of this application, the traffic prediction module includes: an object quantity sampling submodule, configured to use a first sliding window, with the current time as the lower limit of the window, to define a first sampling time range, and to use the number of objects in the object traffic data of the target service node within the first sampling time range as the first object quantity; and to use a second sliding window, with the current time as the lower limit of the window, to define a second sampling time range, and to use the number of objects in the object traffic data of the target service node within the second sampling time range as the second object quantity; an upstream traffic calculation submodule, configured to use the first object quantity and the second object quantity to determine the upstream arrival quantity, and to determine the upstream node traffic based on the upstream arrival quantity and the object conversion time; and a traffic prediction submodule, configured to determine a traffic fusion weight based on the object conversion time, the upstream node traffic, and a preset traffic threshold, and to fuse the first object quantity and the second object quantity based on the traffic fusion weight to obtain the object arrival rate.

[0081] For example, if the width of the first sliding window is 10 minutes and the width of the second sliding window is 2 minutes, then the first sliding window can be used to collect the number of objects on the target service node in the past 10 minutes as the first object count, and the second sliding window can be used to collect the number of objects on the target service node in the past 2 minutes as the second object count.

[0082] In one embodiment, the emergency multi-area human resource dynamic scheduling system counts the number of objects from the pre-examination triage to the internal medicine clinic every 10 minutes and every 2 minutes, respectively, namely the first object number and the second object number. After long and short window fusion, the object arrival rate is determined based on the first object number, the second object number and the object conversion time.

[0083] Given that the upstream node traffic is 12 and the object conversion time is 15 minutes, it can be determined that after 15 minutes, the workload equivalent to 12 people / hour will reach the target service node, namely the internal medicine clinic.

[0084] The preset traffic threshold can be set in advance according to the service characteristics and service capabilities of the target service node. When the upstream node traffic exceeds the preset traffic threshold, the traffic fusion weight can be adjusted to make the proportion of the second object higher, thereby making the contribution of the second object to the object arrival rate higher, and ensuring that the object arrival rate is more sensitive to occasional traffic surges.

[0085] The object arrival rate λ can be determined according to equation (1):

[0086] (1)

[0087] Where β represents the traffic fusion weight, Indicates the number of the second object. This represents the number of objects. According to embodiments of this application, two sliding windows of different widths are used to sample the number of objects at different time scales, and the upstream node traffic is calculated by combining the object conversion time. Then, a fusion weight is determined based on the upstream traffic, and the object number data from both windows are fused to obtain the final predicted value. This approach can consider both short-term fluctuations and long-term trends in customer flow, while also incorporating the influence of upstream flow transmission, thus improving the comprehensiveness and accuracy of traffic prediction results.

[0088] According to an embodiment of this application, the traffic prediction submodule includes: a first weight judgment unit configured to use the current fusion weight as the traffic fusion weight when the upstream node traffic is less than or equal to a preset traffic threshold; a second weight judgment unit configured to determine a first weight adjustment range based on the difference between the upstream node traffic and the preset traffic threshold when the upstream node traffic is greater than the preset traffic threshold; an object quantity deviation calculation unit configured to determine a quantity deviation rate based on a first object quantity and a second object quantity, and to determine a second weight adjustment range based on the object deviation rate; and a weight adjustment unit configured to adjust the current fusion weight according to the first weight adjustment range and the second weight adjustment range to obtain the traffic fusion weight.

[0089] If the upstream node traffic is less than or equal to the preset traffic threshold, it means that after the upstream node traffic reaches the target service node, the service efficiency of the current target service node can handle the traffic. Therefore, the current fusion weight can be used as the traffic fusion weight, that is, the traffic fusion weight is not adjusted.

[0090] If the upstream node traffic is greater than or equal to the preset traffic threshold, it means that after the upstream node traffic reaches the target service node, the current target service node's service efficiency is insufficient to handle the traffic. Therefore, the first weight adjustment range can be determined based on the difference between the upstream node traffic and the preset traffic threshold. For example, the percentage of the difference to the preset traffic threshold can be calculated first, and then the first weight adjustment range can be determined based on this percentage and the current fusion weight.

[0091] The deviation rate between the number of the first object and the number of the second object can be used as the quantity deviation rate. The quantity deviation rate is compared with a preset deviation rate threshold. If it is determined that the quantity deviation rate is greater than the deviation rate threshold, the second weight adjustment range can be determined based on the difference between the quantity deviation rate and the deviation rate threshold.

[0092] The current fusion weight is adjusted using the first and second weight adjustment ranges to obtain the traffic fusion weight.

[0093] For example, if the quantity deviation rate is less than or equal to the deviation rate threshold, the current fusion weight is 0.1, and the calculated difference accounts for 50% of the preset traffic threshold, the first weight adjustment range is 0.1 * 50% = 0.05, the second weight adjustment range is 0, and the current fusion weight is adjusted to obtain a traffic fusion weight of 0.1 + 0.05 = 0.15.

[0094] When the quantity deviation rate is greater than the deviation rate threshold and the difference between the two is 0.2, the current fusion weight is 0.1, and the calculated percentage of the difference to the preset traffic threshold is 50%, the first weight adjustment range is 0.05, the second weight adjustment range is 0.2, and the current fusion weight is adjusted to obtain a traffic fusion weight of 0.1 + 0.05 + 0.2 = 0.35.

[0095] According to embodiments of this application, the traffic prediction submodule distinguishes weight adjustment logic based on the relationship between upstream node traffic and a preset threshold. When upstream traffic is normal, the original weights are used; when upstream traffic is overloaded, the weight magnitude is dynamically adjusted based on the difference. This achieves adaptive changes in the fused weights, automatically strengthening the reference proportion of corresponding data in abnormal scenarios such as a surge in upstream traffic, making the traffic prediction results adaptable to sudden changes in passenger flow.

[0096] According to an embodiment of this application, the resource scheduling module includes: a load comparison submodule, configured to determine the current load level of the target service node based on queue load and load threshold; and a strategy formulation submodule, configured to determine the human resource scheduling strategy for the target service node based on the load level.

[0097] According to an embodiment of this application, the queue load can be determined based on queuing theory, as shown in equation (2):

[0098] (2)

[0099] Where ρ represents queue load, c*μ represents comprehensive service capacity, c represents the number of service stations of the target service node, and μ represents basic service rate.

[0100] Based on the relationship between queue load and load threshold, it is possible to determine whether the current load of the target service node exceeds the limit, thereby determining the current load level of the target service node.

[0101] When the load level indicates that the current load exceeds the limit, the human resource scheduling strategy for the target service node can be determined based on the degree of exceedance.

[0102] According to embodiments of this application, the load level is determined by a load comparison submodule, and then the corresponding management strategy is matched by a strategy formulation submodule. This transforms abstract queue loads into standardized load levels, enabling quantitative grading of load status, providing a basis for resource scheduling, and improving the standardization and implementability of strategy output.

[0103] According to an embodiment of this application, the load comparison submodule includes: a first load determination unit configured to set the load level to a first level when the queue load is within a first load interval; a second load determination unit configured to set the load level to a second level when the queue load is within a second load interval; a third load determination unit configured to set the load level to a third level when the queue load is within a third load interval; and a fourth load determination unit configured to set the load level to a fourth level when the queue load is within a fourth load interval, wherein the first load interval, the second load interval, the third load interval, and the fourth load interval are determined based on load thresholds.

[0104] Multiple load thresholds can be set, and multiple different load intervals can be divided based on these thresholds. Different load levels can be determined based on the different load intervals in which the queue load is located, thus realizing multi-level adjustment based on queue load.

[0105] According to an embodiment of this application, the first load range is (0, 0.7), the second load range is [0.7, 0.8), the third load range is [0.8, 0.9), and the fourth load range is [0.9, +∞). Based on the load range in which the queue load ρ is located, the current load level can be accurately determined.

[0106] According to embodiments of this application, four load ranges are divided based on load thresholds, and four load levels are correspondingly set to achieve refined range division of queue load. The classification criteria are clear and the boundaries are well-defined, which can accurately distinguish different operating conditions from normal load to severe congestion, providing detailed classification basis for the formulation of differentiated resource strategies.

[0107] According to an embodiment of this application, the strategy formulation submodule includes: a first strategy formulation unit configured to display the load level on the front-end page and suggest maintaining the number of service desks unchanged when the load level is at level one; a second strategy formulation unit configured to display the load level on the front-end page and remind administrators to pay attention to the number of service desks and object arrival rate when the load level is at level two; a third strategy formulation unit configured to display the load level, alarm information, and pending resource quantity on the front-end page when the load level is at level three, so that administrators can perform resource management based on the pending resource quantity, which is determined based on queue load, load threshold, and comprehensive service capacity; and a fourth strategy formulation unit configured to display the load level, alarm information, and buffered resource quantity on the front-end page when the load level is at level four, so that administrators can perform resource management based on the buffered resource quantity, which is determined based on the pending resource quantity and a pre-set emergency resource quantity.

[0108] When the load level is set to Level 1, it indicates that the current resource configuration is relatively reasonable and the target service node can handle the service pressure brought by the object traffic corresponding to the object traffic data. Therefore, the load level can be displayed as Level 1 on the front-end page, along with a text suggestion that the number of service desks can be kept unchanged.

[0109] When the load level is Level 2, it means that the target service node can still handle the service pressure brought by the object traffic corresponding to the object traffic data according to the current resource configuration. However, if the object traffic increases further, it will approach the limit of the overall service capacity. Therefore, the load level of Level 2, the number of service desks and the object arrival rate can be displayed on the front-end page, along with text suggestions to remind administrators to pay attention to the above data so that resources can be adjusted in advance.

[0110] When the load level is level 3, it means that the service pressure brought by the current object traffic is close to the limit of the overall service capacity. Therefore, the load level can be displayed as level 3 on the front-end page, along with alarm information and the amount of resources to be supplemented determined based on queue load, load threshold and overall service capacity. Administrators can coordinate resources according to the amount of resources to be supplemented to alleviate the service pressure on the target service node.

[0111] Among them, the amount of resources to be supplemented is C newIt can be determined according to equation (3):

[0112] (3)

[0113] Where, ρ target This represents the expected load value, which can be set as the lower limit of the third load range. When the third load range is [0.8, 0.9), ρ target 0.8 can be taken.

[0114] Typically, the calculated amount of resources to be replenished is not an integer. Since the amount of resources can be represented as the number of service personnel, the calculated amount of resources to be replenished, C, can be expressed as follows: new Round up to ensure that scheduled resources can handle the excess load.

[0115] When the load level is level four, it means that the service pressure brought by the current object traffic is about to exceed the limit of the overall service capacity. Therefore, the load level can be displayed as level four on the front-end page, along with alarm information and the amount of buffer resources determined based on the amount of resources to be replenished and the amount of emergency resources.

[0116] When the load level is level 4, there are cases where the queue load is greater than 1. In this case, the number of objects in the waiting state will continue to increase. Therefore, in addition to replenishing the resources to be replenished to the target service node, additional buffer resources are also added to utilize the additional service capacity provided by the buffer resources to consume the number of waiting objects accumulated during the level 4 period, so that the target service node can restore the normal service state as soon as possible.

[0117] For example, if the buffer resource amount is set to 3, the resource amount C to be replenished can be calculated using equation (3). new The value is 1.8. Rounding up, we get 2 units of resource to be replenished. In this case, if only the resource to be replenished is added to the target service node, it can only ensure that the number of objects in a waiting state at the target service node will not continue to increase, but there is no additional service capacity to consume the objects already in a waiting state. Therefore, adding the buffered resource to the target service node can utilize the service capacity corresponding to the buffered resource to provide services to the objects that are queuing at the target service node, so that the target service node can resume normal service as soon as possible.

[0118] In one embodiment of this disclosure, the visual effect of different load levels can be enhanced by using the display colors of the front-end page. For example, the background or font color can be set to green for the first load level, yellow for the second, orange for the third, and red for the fourth. Different background or font colors provide a visual reference for managers, allowing them to intuitively judge the urgency of the current queuing situation.

[0119] According to embodiments of this application, differentiated handling strategies are designed for multiple load levels: low load maintains existing resources, medium load is monitored in real time, high load pushes alarms and resource replenishment information, and severe load triggers emergency buffer resources. Through a tiered response mechanism, comprehensive coverage from routine maintenance to emergency response can be achieved, avoiding resource waste, quickly addressing traffic congestion issues, and improving emergency management capabilities.

[0120] According to an embodiment of this application, the traffic warning module is further configured to calculate the average number of objects on the target service node and the average waiting time for each object based on the queue load.

[0121] Average number of objects L q Determined according to equation (4):

[0122] (4)

[0123] Where P0 represents the queue idle probability, determined according to equation (5):

[0124] (5)

[0125] Average waiting time W q Determined according to equation (6):

[0126] (6)

[0127] According to an embodiment of this application, the load comparison submodule is further configured to determine the current load level of the target service node based on the average number of objects and the object number threshold, and to determine the current load level of the target service node based on the average waiting time and the time threshold.

[0128] The average number of objects can represent the number of objects queuing for service at the target service node. If the average number of objects is greater than the object number threshold and / or the average waiting time is greater than the time threshold, the load level indicates that the overall service capacity of the target service node is insufficient and needs to be supplemented through resource scheduling.

[0129] Figure 4 A flowchart of a method for dynamic scheduling of human resources in multiple emergency areas according to an embodiment of this application is shown.

[0130] like Figure 4 As shown, the method includes operations S410 to S420.

[0131] When operating S410, identify the target areas in the hospital's emergency department that require resource management.

[0132] In operation S420, the target area is input into the emergency multi-area human resource dynamic scheduling system to obtain the human resource scheduling strategy for the target area.

[0133] According to embodiments of this application, based on a target area, a dynamic human resource scheduling system for multiple areas in an emergency department can automatically complete the entire process calculation and output human resource scheduling strategies. It can be quickly applied to resource management in any area of ​​a hospital's emergency department, is highly versatile, and is easy to deploy in batches in multi-area scenarios within a hospital's emergency department.

[0134] According to an embodiment of this disclosure, when the target area is an internal medicine clinic, the internal medicine clinic is input into a dynamic scheduling system for human resources in multiple emergency areas to obtain a baseline service rate of μ=9 people / hour. Through sliding window monitoring, the predicted arrival rate of objects 12 minutes later is λ=12 people / hour. The current human resources of the internal medicine clinic are configured with two doctors.

[0135] Based on equation (2), we calculate ρ = 12 / (2*9) = 0.67, and 0.67 < 0.7. According to equations (4) and (6), we calculate that the number of people in the queue is about 1.07, and the average waiting time is about 5.33 minutes. Therefore, the front-end page can display a green prompt: The queue load has not exceeded the limit after 12 minutes. The average number of people in the queue is about 1. The average waiting time for patients is 5 minutes. It is recommended to maintain the status quo.

[0136] Figure 5 A block diagram of an electronic device suitable for implementing a dynamic scheduling system and method for human resources in multiple emergency areas, according to an embodiment of this application, is shown.

[0137] like Figure 5As shown, an electronic device 500 according to an embodiment of this application includes a processor 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage portion 508 into a random access memory (RAM) 503. The processor 501 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 501 may also include onboard memory for caching purposes. The processor 501 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0138] RAM 503 stores various programs and data required for the operation of electronic device 500. Processor 501, ROM 502, and RAM 503 are interconnected via bus 504. Processor 501 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 502 and / or RAM 503. It should be noted that the programs may also be stored in one or more memories other than ROM 502 and RAM 503. Processor 501 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0139] According to embodiments of this application, the electronic device 500 may further include an input / output (I / O) interface 505, which is also connected to a bus 504. The electronic device 500 may also include one or more of the following components connected to the input / output (I / O) interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the input / output (I / O) interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 510 as needed so that computer programs read from it can be installed into the storage section 508 as needed.

[0140] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0141] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 502 and / or RAM 503 and / or one or more memories other than ROM 502 and RAM 503 described above.

[0142] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of this application.

[0143] When the computer program is executed by the processor 501, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0144] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 509, and / or installed from a removable medium 511. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0145] In such an embodiment, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by processor 501, it performs the functions defined in the system of this application embodiment. According to embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0146] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0147] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0148] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

[0149] The embodiments of this application have been described above. However, these embodiments are merely illustrative and not intended to limit the scope of this application. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. Without departing from the scope of this application, those skilled in the art can make various substitutions and modifications, all of which should fall within the scope of this application.

Claims

1. A dynamic dispatching system for emergency multi-zone human resources, characterized in that, The dynamic human resources scheduling system includes: The data acquisition module is configured to obtain object traffic data of the hospital emergency department from the medical system in the data source layer. The object traffic data includes the arrival time of multiple objects at service nodes. The service nodes include target service nodes corresponding to the target area and upstream service nodes located upstream of the target service nodes. The traffic prediction module is configured to statistically analyze and sample the object traffic data to obtain the object arrival rate of the target service node. The object arrival rate is the predicted traffic value of the object traffic of the target service node. The object arrival rate is determined based on the first number of objects, the second number of objects, and the upstream node traffic. The first number of objects and the second number of objects are obtained by sampling the traffic data of the target service node using a first sliding window and a second sliding window, respectively. The width of the first sliding window is greater than the width of the second sliding window. The upstream node traffic is determined based on the object conversion time of the upstream service node. The object conversion time represents the time required for an object to travel from the upstream service node to the target service node. A traffic alert module is configured to determine the queue load of a target service node based on the object arrival rate and the overall service capacity of the target service node. The overall service capacity is determined according to the number of service stations configured on the target service node, and the number of service stations is determined according to the human resources available at the target service node. The resource scheduling module is configured to determine the human resource scheduling strategy for the target area based on the queue load.

2. The human resource dynamic scheduling system of claim 1, wherein, The dynamic human resources scheduling system also includes: The benchmark parameter calculation module is configured to obtain historical object traffic data and industry standard data of the emergency department from the medical system, and determine benchmark service parameters based on the historical object traffic data and the industry standard data. The benchmark service parameters include the comprehensive service capability of the target service node and the object conversion time between the upstream service node and the target service node. The comprehensive service capability represents the efficiency of the target service node in providing services to the object.

3. The human resource dynamic scheduling system of claim 2, wherein, The historical object traffic data includes the time when each of the historical objects arrived at the service node, and the time when each of the historical objects left the service node. The benchmark parameter calculation module includes: The service parameter calculation submodule is configured to determine the basic service rate per unit of resource volume based on the historical traffic data of the target service node, the historical resource volume corresponding to the historical traffic data, and the service efficiency data of serving the historical traffic data with the historical resource volume, and to determine the comprehensive service capability based on the number of service stations and the basic service rate. The conversion duration calculation submodule is configured to determine the first historical moment when the historical object receives service at the upstream service node based on the historical traffic data of the upstream service node in the historical object traffic data, determine the second historical moment when the historical object receives service at the target service node based on the historical traffic data of the target service node, and determine the object conversion duration based on the time difference between the first historical moment and the second historical moment.

4. The human resource dynamic scheduling system of claim 2, wherein, The traffic prediction module includes: The object quantity sampling submodule is configured to use the first sliding window, with the current time as the lower limit of the window, to define a first sampling time range, and to take the number of objects in the object traffic data of the target service node within the first sampling time range as the first object quantity; and to use the second sliding window, with the current time as the lower limit of the window, to define a second sampling time range, and to take the number of objects in the object traffic data of the target service node within the second sampling time range as the second object quantity. The upstream traffic calculation submodule is configured to determine the upstream arrival quantity using the first object quantity and the second object quantity, and to determine the upstream node traffic based on the upstream arrival quantity and the object conversion time. The traffic prediction submodule is configured to determine the traffic fusion weight based on the object conversion time, the upstream node traffic, and a preset traffic threshold, and to fuse the first object quantity and the second object quantity based on the traffic fusion weight to obtain the object arrival rate.

5. The human resource dynamic scheduling system of claim 4, wherein, The traffic prediction submodule includes: The first weighting determination unit is configured to use the current fusion weight as the traffic fusion weight when the upstream node traffic is less than or equal to the preset traffic threshold. The second weighting determination unit is configured to determine the first weighting adjustment range based on the difference between the upstream node traffic and the preset traffic threshold when the upstream node traffic is greater than the preset traffic threshold. The object quantity deviation calculation unit is configured to determine the quantity deviation rate based on the first object quantity and the second object quantity, and to determine the second weight adjustment range based on the object deviation rate; The weight adjustment unit is configured to adjust the current fusion weight according to the first weight adjustment range and the second weight adjustment range to obtain the traffic fusion weight.

6. The human resource dynamic scheduling system of claim 1, wherein, The data acquisition module includes: The data maintenance submodule is configured to communicate with the medical system, acquire event data generated by the medical system, perform structured processing on the event data, and obtain the object traffic data. The medical system includes a hospital information system, an emergency triage system, and a nursing mobile terminal. The network construction submodule is configured to construct a service topology between multiple service nodes based on the business relationships between multiple hospital emergency areas. Each of the multiple service nodes corresponds one-to-one with one of the multiple hospital emergency areas. The service topology includes the multiple service nodes and directed edges between the multiple service nodes. The service node corresponding to the starting point of the directed edge is the upstream node of the service node corresponding to the ending point of the directed edge. The data acquisition submodule is configured to determine the upstream service node of the target service node based on the target area and the service topology, and provide object traffic data related to the target service node and the upstream service node respectively.

7. The human resource dynamic scheduling system according to claim 1, characterized in that, The resource scheduling module includes: The load comparison submodule is configured to determine the current load level of the target service node based on the queue load and load threshold; The strategy formulation submodule is configured to determine the human resource scheduling strategy for the target service node based on the load level.

8. The human resource dynamic scheduling system according to claim 7, characterized in that, The load comparison submodule includes: The first load determination unit is configured to set the load level to the first level when the queue load is within a first load range; The second load determination unit is configured to set the load level to the second level when the queue load is within the second load range; The third load determination unit is configured to set the load level to the third level when the queue load is within the third load range; The fourth load determination unit is configured to set the load level to the fourth level when the queue load is within the fourth load interval, wherein the first load interval, the second load interval, the third load interval, and the fourth load interval are determined based on the load threshold.

9. The human resource dynamic scheduling system according to claim 8, characterized in that, The strategy formulation submodule includes: The first strategy formulation unit is configured to display the load level on the front-end page when the load level is the first level, and to suggest keeping the number of service desks unchanged. The second strategy formulation unit is configured to display the load level on the front-end page when the load level is the second level, and to remind administrators to pay attention to the number of service desks and the object arrival rate. The third strategy formulation unit is configured to display the load level, alarm information and the amount of resources to be replenished on the front-end page when the load level is the third level, so that the administrator can perform resource management based on the amount of resources to be replenished, which is determined based on the queue load, the load threshold and the comprehensive service capability. The fourth strategy formulation unit is configured to display the load level, the alarm information, and the buffer resource quantity on the front-end page when the load level is the fourth level, so that the administrator can perform resource management based on the buffer resource quantity, which is determined based on the resource quantity to be replenished and the pre-set emergency resource quantity.

10. A method for dynamic scheduling of human resources in multiple emergency areas, characterized in that, The method includes: Identify the target areas within the hospital's emergency department that require resource management; The target area is input into the emergency multi-area human resource dynamic scheduling system according to any one of claims 1 to 9 to obtain a human resource scheduling strategy for the target area.

Images