Medicine whole-process intelligent industrial control management method and system

Abstract

The invention relates to a medicine whole-process intelligent industrial control management method and system, and the system comprises a control server which is connected with a message management server, an equipment management server, a collection and detection server, and an auxiliary equipment management server. The message management server is connected with the control server and the dispensing management server; a message subscription mechanism is adopted, so that the control server and the dispensing management server decouple and asynchronously cooperate; the auxiliary equipment management server is used for controlling the medicine decocting equipment to decoct medicines under the control of the control server; and the acquisition and detection server is used for controlling the detection device to carry out detection under the control of the control server. According to the technical scheme, each server is clear in division of labor and efficient in cooperation, the message management server achieves cooperative decoupling, and the method is suitable for a full-process efficient medicine circulation scene in a hospital.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of medical treatment, and in particular to a medicine whole-process intelligent industrial control management method and system. BACKGROUND

[0002] With the improvement of people's living standards, hospital treatment and medicine taking are often encountered by people. Due to the large flow of people in the hospital, it is often necessary to wait when taking medicine at the window. The current hospital pharmacy operation is mainly faced with the problem of low efficiency. The average waiting time of patients during the peak period of outpatient service in some hospitals is more than 30 minutes, which is easy to cause window congestion. SUMMARY

[0003] In order to overcome the problems in the related art, the present disclosure provides a medicine whole-process intelligent industrial control management method and system to solve the problem of low user medicine purchasing efficiency in the related art.

[0004] According to a first aspect of an embodiment of the present disclosure, a medicine whole-process intelligent industrial control management system is provided, comprising: a control server connected with a message management server, a device management server, a collection and detection server and an auxiliary device management server respectively, for controlling the device management server, the collection and detection server and the auxiliary device management server; a dispensing management server for digitally managing the whole process of medicine dispensing, distribution, inventory, specifically including: medicine information management, dispensing process control, inventory monitoring and early warning, and record and traceability; the message management server is connected with the control server and the dispensing management server; for a message subscription mechanism is adopted to decouple the control server and the dispensing management server and make them cooperate asynchronously; the device management server is used for controlling the medicine distribution device to distribute medicine under the control of the control server; the auxiliary device management server is used for controlling the medicine decocting device to decoct medicine under the control of the control server; the collection and detection server is used for controlling the detection device to detect under the control of the control server.

[0005] In a second aspect, the present disclosure provides a medicine whole-process intelligent industrial control management method. The medicine whole-process intelligent industrial control management system comprises: a control server connected with a message management server, a device management server, a collection and detection server and an auxiliary device management server respectively, and a dispensing management server; the control server controls the device management server, the collection and detection server and the auxiliary device management server; The method includes that the dispensing management server digitally manages the whole process of dispensing, issuing and inventory of the medicine, and specifically includes medicine information management, dispensing process control, inventory monitoring and early warning, and record and traceability. The message management server adopts a message subscription mechanism to decouple the control server and the dispensing management server and to make them asynchronously cooperate. The device management server controls the medicine issuing device to issue the medicine under the control of the control server. The auxiliary device management server controls the medicine decocting device to decoct the medicine under the control of the control server. The acquisition and detection server controls the detection device to detect under the control of the control server.

[0006] The technical solution provided by the embodiments of the present disclosure can have the following beneficial effects: Compared with the prior art, the technical solution of the present application sets the control server, the message management server, the device management server, the acquisition and detection server and the auxiliary device management server connected with the control server respectively, the message management server adopts a message subscription mechanism to decouple the control server and the dispensing management server and to make them asynchronously cooperate, the auxiliary device management server is used to control the medicine decocting device to decoct the medicine under the control of the control server, and the acquisition and detection server is used to control the detection device to detect under the control of the control server. The technical solution of the present application has clear division of labor of each server, high efficiency of cooperation, the message management server realizes cooperative decoupling, and is suitable for the scene of efficient circulation of the whole process of medicine in the hospital.

[0007] It should be understood that the foregoing general description and the following detailed description are only exemplary and explanatory, and cannot limit the present disclosure. BRIEF DESCRIPTION OF DRAWINGS

[0008] The accompanying drawings incorporated in the specification and constituting a part of the specification illustrate embodiments consistent with the present disclosure and serve together with the specification to explain the principles of the present disclosure.

[0009] Figure 1 is a schematic diagram of a medicine whole-process intelligent industrial control management system according to an exemplary embodiment; Figure 2 is a flowchart of a task scheduling method according to an exemplary embodiment; Figure 3 is a block diagram of various systems in a control server according to an exemplary embodiment; Figure 4 is a device detection and early warning schematic diagram according to an exemplary embodiment; Figure 5 is a business flowchart according to an exemplary embodiment; Figure 6 is another business flowchart according to an exemplary embodiment. DETAILED DESCRIPTION

[0010] The exemplary embodiments will be described in detail herein with reference to the attached drawings. In the following description, the same numbers refer to the same or similar elements throughout the drawings. The embodiments described in the following exemplary embodiments are not meant to represent all embodiments consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present disclosure as detailed in the appended claims.

[0011] Based on this, the present application provides a medicine whole-process intelligent industrial control management system, as shown in the accompanying Figure 1 , comprising: A control server 01 is connected with a message management server 02, a device management server 06, a collection and detection server 05 and an auxiliary device management server 04 respectively, and is used for controlling the device management server 06, the collection and detection server 05 and the auxiliary device management server 04.

[0012] A dispensing management server 03 is used for digitally managing the whole process of medicine dispensing, issuing and inventory, and specifically includes medicine information management, dispensing process control, inventory monitoring and early warning, and record and traceability.

[0013] The message management server 02 is connected with the control server 01 and the dispensing management server 03, and is used for adopting a message subscription mechanism to decouple the control server 01 and the dispensing management server 03 and make them cooperate asynchronously.

[0014] The device management server 06 is used for controlling a medicine issuing device to issue medicine under the control of the control server.

[0015] The auxiliary device management server 04 is used for controlling a medicine decocting device to decoct medicine under the control of the control server 01.

[0016] The collection and detection server 05 is used for controlling a detection device to detect under the control of the control server 01, so as to realize the accuracy, safety and compliance of medicine issuing.

[0017] The technical scheme of the present application is in a distributed system composed of multiple independent servers, and each server has clear division of labor, high cooperation efficiency and stable overall system.

[0018] The roles of the above-mentioned various servers are as follows: the control server, as the "command center" of the system, is responsible for receiving upper-level instructions, such as user orders and administrator operations, and coordinating other servers to complete the process. The control server does not directly handle specific businesses, such as inventory checking and device control, but dispatches other servers through messages or instructions, avoiding itself becoming a "all-in-one but cumbersome" node. For example, after a user places an order, the control server triggers the whole process of "inventory checking → device scheduling → result feedback", and itself only makes decisions and concatenates.

[0019] The dispensing management server focuses on data management and business logic related to medicines, such as inventory, expiration date, and warehouse in / out. It isolates medicine data from other businesses, such as device control, to avoid data confusion, for example, inventory changes are only handled by it, and other servers can only query or request. It supports separate optimization, such as adding a medicine expiration warning function, without modifying the control server.

[0020] The device management server manages the status and operation of medicine dispensing devices, such as intelligent medicine cabinets and sorting devices. It uniformly handles device startup / stop, fault detection, and action execution, avoiding other servers directly operating device hardware and reducing hardware dependency. For example, after receiving a dispensing instruction, it is responsible for driving the device to accurately dispense medicine and feeding back "whether it is successful", and other servers do not need to care about the specific model or interface of the device.

[0021] The device management server monitors the abnormal state of the system or device in real time, such as device failure, insufficient medicine inventory, and network fluctuation. It actively discovers problems and triggers warnings. For example, through sensor detection of abnormal medicine cabinet temperature, it immediately pushes a message to the control server to avoid the expansion of faults. It reduces the "monitoring burden" of other servers and lets them focus on core businesses.

[0022] The message management server can also be set between the device management server 06, the detection server 05, and the auxiliary device management server 04 and the control server 01, as the "communication hub" of the entire system. It realizes efficient and reliable information transmission: decouples communication: lets each server not need to know the address or state of each other, and transmits information through "message topics", such as the detection server discovering device failure, only needs to send a message to the "device exception" topic, and the control server and subscription automatically receive. Asynchronous buffering: when a server is busy, such as the dispensing management server is processing a large number of inventory queries, the message management server temporarily stores messages to avoid the sender waiting or message loss. Peak shaving: for example, when orders surge during peak hours, the message management server queues requests in order to avoid the control server being instantly crushed. Reliability guarantee: supports message retry and persistence, and messages are not lost after unexpected power failure, ensuring that critical instructions, such as medicine dispensing, are not missed.

[0023] In summary, the above-mentioned various servers achieve business isolation through "division of labor", making the system more maintainable and extensible. Especially, the message management server achieves collaborative decoupling through the role of "communication intermediary", allowing dispersed servers to work efficiently together while avoiding the impact of a single link failure on the entire system. Combined with the above, the system ultimately achieves "high availability, high flexibility, and easy iteration".

[0024] In some embodiments, the detection device includes a barcode / QR code scanner for scanning the barcode or QR code on the drug packaging to quickly identify the drug information.

[0025] RFID reader, for reading the RFID tag information attached to the drug using radio frequency identification technology.

[0026] Image recognition detector, for capturing the drug through a camera and detecting the shape, color, and size of the drug using image algorithms to determine whether it matches the prescribed dose and specifications.

[0027] Weight detection device, for detecting the weight of solid drugs to assist in determining whether the dose is accurate.

[0028] Temperature and humidity sensor, for monitoring the temperature and humidity of the drug storage and dispensing environment to ensure that the drug is stored in suitable conditions and to avoid environmental problems affecting drug efficacy.

[0029] Face recognition / fingerprint recognition device, for identity verification when the pharmacist or patient picks up the drug to ensure that the drug is dispensed to the correct object and complies with the operating specifications.

[0030] Operation behavior monitoring camera, for video monitoring and behavior analysis to detect whether the drug dispensing process complies with the standard process and ensure operation compliance.

[0031] In some embodiments, the dispensing management server uses machine learning algorithms to optimize inventory and order processing, inventory forecasting and dynamic replenishment, and uses a time series model to predict future drug demand based on historical order data and push replenishment suggestions to the control server in advance.

[0032] In this embodiment, the dispensing management server optimizes inventory and order processing through machine learning algorithms, which can be divided into four core steps: data preparation, model building, prediction and decision-making, and system integration, as follows: I. Data preparation and preprocessing.

[0033] Core data types: historical order data (including drug ID, order quantity, order time, delivery area, etc.); inventory data (current inventory, inventory alert line, storage cost, expiration time, etc.); external influencing factors (such as seasonal changes, special events such as epidemics, holiday demand fluctuations, supplier replenishment cycles, etc.).

[0034] Preprocessing operations: cleaning data (removing outliers, such as incorrect order quantities; filling missing values, such as using mean values or adjacent period data); time series formatting (organizing data by fixed time granularity, such as aggregating order quantities by day, week, or month); feature engineering (extracting time features, such as month and day of the week; constructing derived features, such as "3-day order growth rate").

[0035] II. Time series model construction and training.

[0036] Select appropriate time series models and train prediction capabilities based on historical data: Model selection: basic models: such as ARIMA (suitable for linear trend data), exponential smoothing (suitable for data with seasonal fluctuations); Machine learning models: such as random forests, gradient boosting trees (can handle non-linear relationships, combined with external influencing factors); Deep learning models: such as LSTM (Long Short-Term Memory Network, suitable for processing long-period, complex trend time series data).

[0037] Training and optimization: divide the data set (use the first 80% of historical data as the training set and the last 20% as the validation set); model training (adjust parameters such as the number of hidden layer nodes in LSTM and the lag order in ARIMA through the validation set); evaluation indicators (use MAE (Mean Absolute Error), RMSE (Root Mean Square Error) and other indicators to judge prediction accuracy to ensure model reliability).

[0038] III. Demand forecasting and replenishment decision-making.

[0039] Use the trained model to generate prediction results and convert them into replenishment suggestions: Demand forecasting: input future time periods (such as the next 7 days or 30 days), and the model outputs the predicted demand for each drug; combine inventory data to calculate "predicted demand - current inventory", resulting in a theoretical replenishment gap.

[0040] Optimize replenishment suggestions: consider constraints: such as the minimum order quantity of suppliers, transportation costs (bulk replenishment is more cost-effective), and inventory upper limits (to avoid overstocking and expiration); use machine learning algorithms (such as linear programming and reinforcement learning) to optimize replenishment quantities, balance "stockout risk" and "inventory cost", and generate final replenishment suggestions (including drug, replenishment quantity, and recommended replenishment time).

[0041] IV. System integration and push execution.

[0042] Integrate the model with servers and control systems to achieve automated processes: Server deployment: Model is packaged as an API interface and deployed to the dispensing management server. The model is automatically called at regular intervals (e.g., daily) to generate predictions and replenishment recommendations based on the latest data.

[0043] Push and execution: The dispensing management server pushes the replenishment recommendations to the control server. After receiving the recommendations, the control server can automatically generate a purchase order (or prompt manual review) to trigger the replenishment process. Loop feedback: After replenishment, actual inventory and new order data are real-time fed back to the control server for continuous iterative optimization of the model (e.g., retraining the model every week to improve prediction accuracy). Through the above steps, the whole process from historical data to accurate replenishment recommendations is automated, reducing stockouts or overstock problems and improving drug dispensing management efficiency. In addition, the order priority intelligent sorting combines user information, drug characteristics, and device load to dynamically sort orders using a reinforcement learning model. High-priority orders are sent first to the control server, which prioritizes the allocation of high-priority orders to the device management server, improving the response speed of urgent orders.

[0044] In this embodiment, the reinforcement learning model can be a proximal policy optimization model.

[0045] The reinforcement learning model realizes dynamic ordering of orders (high-priority orders are sent first), and the core is to learn "how to sort" through the model to maximize the overall goal (such as reducing high-priority order delays and improving customer satisfaction). The specific implementation steps are as follows: I. Define the problem and core elements.

[0046] Clearly define the goal of sorting and the key characteristics of orders to provide decision-making basis for the model.

[0047] Objective function (reward function): The "learning direction" of the model, for example: when high-priority orders are processed first, give positive rewards (the higher the priority, the greater the reward weight); give negative penalties for high-priority order delays (such as not sent within the expected time limit); avoid excessive accumulation of low-priority orders (set a basic penalty to prevent extreme cases).

[0048] Order state features: Describe the key information of the order as input for the model's decision-making, such as: Priority label (e.g., 1-5 levels, with level 1 being the highest); order creation time (affects time limit); delivery address (e.g., whether it is remote, affecting processing difficulty); drug type (e.g., whether it is an emergency drug, indirectly affecting priority).

[0049] Model training and iteration. Train the model through simulation or real environment data, so that it learns to prioritize high-priority orders: Training data sources: historical order data: use past order sorting cases as initial training samples, simulate the results of different sorting strategies.

[0050] Simulation environment: build a virtual scene, randomly generate order streams of different priorities and features, let the model try and error in simulation, such as sending low-priority orders first will be punished, so as to adjust the strategy.

[0051] The training process is as follows: when the model is initialized, randomly select order sending, and get feedback according to the reward function; Update the strategy through reinforcement learning algorithm; Repeat iteration until the model stabilizes and learns the strategy of "prioritizing high-priority orders" (for example, in more than 90% of scenarios, high-priority orders are placed in the top 50% positions).

[0052] In some embodiments, the device management server is configured to use a machine learning algorithm to predict device failures.

[0053] Collect data from the device, learn the normal operation mode of the device using an anomaly detection algorithm, identify abnormal states in real time, predict failure risks in advance, and send maintenance instructions to the control server.

[0054] In this embodiment, the anomaly detection algorithm learns the normal operation mode of the device, identifies abnormal states that deviate from the normal state and predicts failure risks. The specific implementation can be divided into the following steps: I. Data collection and preprocessing.

[0055] First, obtain the key data of the device operation to provide the basis for the model to learn the "normal mode": Data types: sensor data, such as temperature, pressure, vibration frequency, current and voltage, etc. Device logs, such as running status codes, operation records, error prompts, etc. Time series data, continuous data recorded by timestamp, reflecting the change of device state over time.

[0056] Preprocessing: clean the data: remove missing values and noise (such as eliminating sensor fluctuations through smoothing); Feature extraction: extract key features (such as temperature mean, vibration peak, status code frequency, etc.) from raw data to reduce dimensionality; Divide the data set: use historical normal operation data as "normal samples" and a small amount of known fault data (if any) as "abnormal samples" to assist verification.

[0057] II. Learn the "normal mode" of the device.

[0058] Through the modeling of anomaly detection algorithms, the feature distribution or regularity of the normal operation of the equipment is defined.

[0059] The anomaly detection algorithm can be implemented using the following algorithms: Isolation Forest algorithm, which constructs "isolation trees" for normal samples. Normal data has a long path in the feature set, and abnormal data is easily isolated (short path) due to its special features, thus distinguishing between normal and abnormal.

[0060] Autoencoder algorithm, which uses neural networks to learn the feature compression and reconstruction ability of normal samples. Normal data has a small reconstruction error, and abnormal data has a large reconstruction error due to deviation from the normal mode.

[0061] Clustering algorithm, which clusters normal samples to form dense "normal clusters". Abnormal data cannot be classified into any cluster or is in a sparse area, and is identified as abnormal.

[0062] III. Anomaly identification and fault risk prediction. Based on the learned normal mode, real-time monitoring and risk assessment are performed: Anomaly identification: Real-time acquisition of equipment data, feature extraction, and input into the model. Abnormal states are identified by threshold judgment (e.g., autoencoder reconstruction error exceeds the set threshold, isolation forest path length is lower than the threshold).

[0063] Fault risk prediction: Combined with time series features, analyze the duration, frequency, and severity of anomalies (e.g., temperature anomaly rising rate), and use trend prediction models (e.g., LSTM) to assess the probability and time window of failure.

[0064] For different types of anomalies (e.g., vibration anomaly, current anomaly), correlate known fault cases to establish an "anomaly-fault" mapping relationship (e.g., vibration frequency anomaly often leads to bearing wear), and output specific fault risk types (e.g., "high bearing fault risk").

[0065] IV. Model optimization and iteration. Update the model with newly generated fault data (abnormal samples) to avoid "normal mode" deviation due to equipment aging and working condition changes.

[0066] Dynamic adjustment of threshold (e.g., through a feedback mechanism, optimize the anomaly judgment threshold according to the actual failure occurrence), to improve the identification accuracy.

[0067] For example, the drive motor of a conveyor belt dispensing medicine. In motor fault detection, first train an autoencoder with vibration and temperature time series data during normal operation to learn the normal mode. During operation, if the reconstruction error of the motor vibration data suddenly increases at a certain time, the model will identify it as an anomaly, and combined with the rule that "bearing failure occurs within 2 hours after vibration anomaly" in historical data, it will predict the bearing failure risk.

[0068] In some embodiments, the device management server is further configured to issue an action accuracy optimization, and correct action parameters in real time using a supervised learning model for position deviation of the mechanical arm taking medicine, reduce the failure of taking medicine, and improve the dispensing efficiency.

[0069] In this embodiment, taking the position deviation correction of the mechanical arm taking medicine as an example, the specific implementation steps of the supervised learning model for real-time optimization of action parameters are as follows: Data collection and labeling: build a “deviation-correction” sample library.

[0070] Collect data: let the mechanical arm record key information during the daily dispensing process: Input features: coordinates of the position of the medicine (such as X / Y / Z axis coordinates of the medicine shelf), size of the medicine packaging box (length / width / height), current joint angle of the mechanical arm, state of the grabbing tool (such as air pressure / tightness of the suction cup / claw); Real-time image features captured by the visual sensor (camera) (such as the pixel position of the medicine in the image, and the relative offset from the end of the mechanical arm).

[0071] Output label: when the mechanical arm has position deviation (such as not aligning with the center of the medicine box, or falling due to grabbing deviation), manually or automatically record the “corrected action parameters” — such as the joint angle needs to be fine-tuned by +2°, the Z-axis height is reduced by 1cm, the suction cup air pressure is increased by 0.2bar, etc. These correction parameters are the “correct output” that the model needs to learn.

[0072] Data augmentation: simulate different scenarios (such as slight deviation of the medicine box position, and visual recognition error caused by light changes), generate more samples, and ensure that the model covers common deviation cases.

[0073] Model selection and training: learn the “deviation-correction” mapping relationship.

[0074] Select a regression-based supervised learning model (as the goal is to predict continuous action correction parameters), for example: Random Forest Regression: handle multiple feature inputs (coordinates, angles, image features, etc.), and learn the non-linear relationship between features and correction parameters; Neural network (such as MLP): fit complex mappings through multiple layers of neurons, especially suitable for integrating visual image features (which need to be extracted through CNN first).

[0075] Training process: train the model with labeled “input features-correction parameters” samples, the goal is to let the model output accurate correction parameters (such as mechanical arm X-axis fine-tune +3mm) according to the current deviation features (such as visual recognition of the medicine box offset by 3mm in the X-axis).

[0076] Real-time correction: integrated into the robot control system.

[0077] Real-time acquisition and prediction: before the robot takes the medicine, the vision sensor takes a photo of the medicine position, synchronously acquires the current joint angle, medicine box size and other characteristics, and inputs the trained model; the model outputs correction parameters (such as adjusting the X / Y / Z coordinates of the robot end, joint angle) in real time.

[0078] Execution and feedback: the robot adjusts the action according to the correction parameters, and after completing the grabbing, the sensor (such as the pressure sensor to judge whether the grabbing is stable) feeds back the result; if there is still deviation, the new "deviation feature-actual correction parameter" will be added to the sample library, and the model will be retrained regularly to improve the accuracy.

[0079] For example: when the robot grabs a certain square medicine box, the vision sensor finds that the actual position of the medicine box is 2mm to the right of the system preset position, and the model outputs the correction parameters "X-axis right shift 2mm, gripper opening degree increase 5%" according to the characteristics "medicine box size + offset + current joint angle", and the robot accurately grabs after adjustment, reducing the medicine box falling or grabbing failure caused by position deviation.

[0080] In some embodiments, the control server is configured to analyze the real-time load of each medicine dispensing device using a clustering algorithm, combine order quantity prediction, dynamically allocate tasks, avoid overloading of medicine dispensing devices, and improve the overall system throughput.

[0081] In this embodiment, taking the task allocation of medicine dispensing devices (such as automatic medicine dispensing machines, conveyor belt systems, etc.) as an example, the specific steps of dynamic load balancing realized by combining clustering algorithm and order quantity prediction are as follows: 1. Real-time load data acquisition and feature definition.

[0082] Collecting device load characteristics: for each dispensing device, real-time collection of core indicators reflecting load: The number of orders currently being processed, the backlog of uncompleted orders; Device running speed (such as the number of medicines dispensed per minute by the medicine dispensing machine, the number of medicines transported per second by the conveyor belt); Resource occupancy rate (such as motor load rate, control system CPU usage); Historical processing time (average processing time per order in the last 10 minutes).

[0083] Feature standardization: unify different indicators (such as order quantity, load rate) to the same order of magnitude (such as 0-1 range) to avoid the influence of a certain feature on the clustering result being too large.

[0084] 2. Divide the device load level using a clustering algorithm.

[0085] Group devices by real-time load status through clustering algorithms (e.g., K-means), identify "light load", "normal", "heavy load" devices: Clustering process: input real-time load characteristics of devices (order backlog, running speed, load rate, etc.), set the number of clusters (e.g., 3 categories: light load, normal, heavy load); Algorithm automatically classifies similar features into a category, for example: Light load device: order backlog < 5, load rate < 30%, average processing time < 5 seconds; Heavy load device: order backlog > 20, load rate > 80%, average processing time > 15 seconds.

[0086] Dynamic update clustering results: recalculate clustering every 30 seconds (due to real-time changes in device load) to ensure accurate load level division.

[0087] 3. Dynamic task allocation combined with order volume prediction.

[0088] Order volume prediction: use time series models (e.g., ARIMA, LSTM) based on historical order data (e.g., 9:00-10:00 is the order peak) to predict future 10-30 minute order volume and drug type distribution.

[0089] Dynamic allocation rules: based on clustering results (device load level) and order prediction, develop allocation strategies: Prioritize allocating new orders to "light load" devices (e.g., machines with low backlog and fast processing); For "heavy load" devices, suspend allocation of new orders until their backlog drops to "normal" level; If it is predicted that a certain type of medicine order will surge (e.g., cold medicine orders are high at a certain time), divert related orders to devices that are efficient in processing that type of medicine (even if their current load is slightly higher, to avoid subsequent concentrated overload).

[0090] Example scenario, a pharmacy has 5 automatic dispensing machines, clustering finds: devices A, B are "light load" (backlog 3, load rate 25%); devices C, D are "normal" (backlog 10, load rate 50%); device E is "heavy load" (backlog 25, load rate 90%, has appeared jam). At this time, the system predicts that there will be 20 new orders (mainly oral medicine) in the next 15 minutes, then: new orders are preferentially allocated to A, B; device E suspends order taking and only processes existing orders; if A, B are more efficient in processing oral medicine, even if C, D are at normal load, oral medicine orders are still inclined to be allocated to A, B to avoid subsequent overload of C, D. In this way, not only can the real-time load status of devices be mastered through clustering, but also orders can be diverted in advance combined with order prediction, reducing device overload and jamming or failure from the root.

[0091] And abnormal order emergency handling, when the pharmacy management server feedbacks the order medicine stock shortage or the equipment management server feedbacks the equipment temporary failure, the decision tree model is used to automatically generate the alternative scheme, to quickly respond and reduce user waiting time.

[0092] In this embodiment, taking order abnormal emergency handling as an example, the specific implementation steps of automatically generating alternative scheme by decision tree model are as follows: 1. Define abnormal scenarios and alternative schemes: clarify the decision rule framework.

[0093] First, sort out common order abnormal types and feasible alternative schemes as the "training basis" of the decision tree: Abnormal type: stock shortage (such as order medicine A only has 2 boxes, and user needs 5 boxes); Equipment temporary failure (such as the mechanical arm for dispensing medicine B is stuck and cannot be operated); Mixed abnormality (such as stock shortage of medicine C + failure of corresponding dispensing equipment).

[0094] Alternative scheme library: when stock is insufficient: recommend alternative medicines with the same ingredients (such as using generic medicines of medicine A), split orders (first find stock, and then supplement and deliver the remaining part after restocking), guide users to change specifications (such as from 10 pieces to 20 pieces).

[0095] When the equipment fails: switch to backup equipment (such as another dispensing machine for medicine B), prioritize manual dispensing channel, and adjust the time to take medicine (inform the user that the equipment will be repaired after 1 hour).

[0096] 2. Build a decision tree model: learn abnormal handling rules.

[0097] Feature extraction: convert abnormal scenarios into features recognizable by the model, for example: Abnormal type (stock shortage / equipment failure / mixed); Medicine attribute (whether it is a prescription medicine / urgent medicine / whether there is an alternative); Order information (user priority / delivery time requirement / order amount); Resource status (whether backup equipment is available / current number of people in manual channel / alternative product inventory).

[0098] Decision tree training: use historical handling cases (such as "stock shortage + prescription medicine + no alternative → recommend splitting order") as training data to let the decision tree learn the mapping relationship between features and optimal schemes.

[0099] Nodes of the tree: use key features as judgment conditions (such as "whether there is an alternative?"); Leaf node: corresponds to a specific alternative scheme (such as "recommend alternative B").

[0100] 3. Real-time generation scheme: integrated into order processing system.

[0101] Real-time input exception features: when the dispensing server feedbacks an exception (such as "Drug D is out of stock, the user is VIP, and needs to be delivered within 2 hours"), the system automatically extracts features (exception type = out of stock, user priority = high, time limit = 2 hours, substitute D' has sufficient stock).

[0102] Model output scheme: decision tree traverses nodes based on features: 1. "Is there a substitute? → Yes"; 2. "Does the substitute have sufficient stock? → Yes"; 3. "Does the user accept the substitute? → Historical data shows that VIP users have a 90% acceptance rate"; Final output scheme: "Recommend substitute D', and inform the user through system message, confirm and immediately issue from backup device to ensure delivery within 2 hours".

[0103] Feedback optimization: record user acceptance of the scheme (such as whether to agree to the substitute) and processing results (such as whether to deliver on time), regularly prune or retrain the decision tree with new data to improve the rationality of the scheme.

[0104] For example: in the user's order, "Ibuprofen tablets (out of stock)" and "the corresponding dispensing device is malfunctioning", the decision tree combines "Ibuprofen is an over-the-counter drug + has a similar substitute (acetaminophen) + the user has no special requirements", and directly generates the scheme: "switch to the backup device to dispense acetaminophen, with a substitute note, no need to wait", quickly solve the exception and reduce user waiting time.

[0105] In some embodiments, the control server is also used for dictionary maintenance, drug configuration, diagnosis and treatment task configuration, prescription management, prescription analysis, task review, task monitoring, task query and task scheduling; In task scheduling, the following formula is used to calculate the candidate device score: Score=w1 SPT+w2 EDD+w3 SetupCost+w4 LocationCost+w5 Reliabilit。

[0106] Wherein, w1 is the shortest processing time weight; SPT is the shortest processing time; w2 is the earliest due date weight; EDD is the earliest due date; w3 represents the switching cost weight; SetupCost is the switching cost; w4 represents the location distance weight; LocationCost is the distance to the location; w5 is the reliability weight; Reliabilit stands for reliability.

[0107] In this embodiment, the specific details of the scheduling algorithm are as follows: Comprehensive scoring mechanism: Calculate a comprehensive score for candidate equipment (such as processing time, expiration time, changeover cost, location distance, and reliability) to select the optimal solution.

[0108] Candidate device scoring formula: Score=w1 SPT+w2 EDD+w3 SetupCost+w4 LocationCost+w5 Reliabilit.

[0109] Where w1 is the weight of the shortest processing time; SPT stands for minimum processing time; w2 is the weight value for the earliest expiration date; EDD is the earliest expiry date; w3 represents the switching cost weight; SetupCost is the switching cost; w4 represents the location distance weight; LocationCost is the distance to the location; w5 is the reliability weight; Reliability; The weights can be adjusted in the parameter table.

[0110] For example: Suppose a hospital needs to dispatch one "medicine decoction machine" to process the decoction of traditional Chinese medicine for emergency patients (task priority: efficiency > cost > distance, so the weighting focuses on "shortest processing time" and "reliability"). The rule is "the higher the score, the better." For example: 1. First, clarify three premises: the weights of the five factors, the factor scoring rules, and the candidate devices.

[0111] Weighting of 5 factors (total weight 100%, allocated according to emergency priority): Shortest processing time weight: 30% (0.3); Earliest expiry date weight: 15% (0.15); Switching cost weight: 15% (0.15); Location distance weight: 10% (0.1); Reliability weight: 30% (0.3); Factor score rules (uniformly normalized: the better the performance, the higher the score, full score 10 points): Shortest processing time: 1 hour (fast) → 10 points, 2 hours → 8 points, 3 hours → 6 points; Earliest due date: 7 days of remaining maintenance time (long) → 10 points, 5 days → 8 points, 3 days → 6 points; Switching cost: 50 yuan (low) → 10 points, 80 yuan → 8 points, 110 yuan → 6 points; Location distance: 100 meters (close) → 10 points, 200 meters → 8 points, 300 meters → 6 points; Reliability: failure rate 1% (low) → 10 points, 3% → 8 points, 5% → 6 points; Candidate devices: a total of 3 (herbal medicine machines A, B, and C), each with the following factor performance: 2. Calculate the comprehensive score of the 3 devices: Comprehensive score formula = (processing time score × 0.3) + (due date score × 0.15) + (switching cost score × 0.15) + (distance score × 0.1) + (reliability score × 0.3); (1) Herbal medicine machine A (best performance); Each factor score: processing time 1 hour (10 points), due date 7 days (10 points), switching cost 50 yuan (10 points), distance 100 meters (10 points), reliability 1% (10 points); Comprehensive score = (10 × 0.3) + (10 × 0.15) + (10 × 0.15) + (10 × 0.1) + (10 × 0.3) = 3 + 1.5 + 1.5 + 1 + 3 = 10 points.

[0112] (2) Herbal medicine machine B (average performance); Each factor score: processing time 2 hours (8 points), due date 5 days (8 points), switching cost 80 yuan (8 points), distance 200 meters (8 points), reliability 3% (8 points); Comprehensive score = (8 × 0.3) + (8 × 0.15) + (8 × 0.15) + (8 × 0.1) + (8 × 0.3) = 2.4 + 1.2 + 1.2 + 0.8 + 2.4 = 8 points.

[0113] (3) Herbal medicine machine C (poor performance); Scores for each factor: Processing time 3 hours (6 points), due date 3 days (6 points), switching cost 110 yuan (6 points), distance 300 meters (6 points), reliability 5% (6 points); Overall score = (6×0.3) + (6×0.15) + (6×0.15) + (6×0.1) + (6×0.3) = 1.8 + 0.9 + 0.9 + 0.6 + 1.8 = 6 points.

[0114] 3. Scheduling conclusions.

[0115] According to the rule of "the higher the score, the better", the decoction machine A is selected to handle the emergency decoction task, which meets the emergency needs of "efficiency first and reliability guaranteed".

[0116] The aforementioned control server is also used to implement the following functions.

[0117] Dictionary maintenance supports customized maintenance of internal basic information, provides unified and standardized centralized entry management, and provides basic data support for equipment classification, equipment list, diagnosis and treatment types, which facilitates the interaction and quick reference of basic data with other modules, reduces data redundancy, and improves data accuracy and usage efficiency.

[0118] In this embodiment, the dictionary maintenance function described above can be implemented in the control server using a dictionary maintenance module.

[0119] The drug configuration supports manually setting the correspondence between drugs and dispensing equipment, automatically obtaining drug information and drug inventory information from the equipment through an interface, and setting the priority for dispensing the same drug on different devices.

[0120] The diagnostic and treatment task configuration supports configuring different equipment and dispensing processes for different diagnostic and treatment tasks. It also supports setting special requirements for different tasks, such as medication collection location, medication collection time, single-person dispensing or ward-wide medication distribution, etc.

[0121] The business dashboard supports displaying the operation of dispensing and medication dispensing services in the form of floor plans and timed data refreshes. It supports real-time statistics of business data and generates charts and graphs. It also supports real-time querying of prescription details and detailed data of each prescription during the dispensing or decoction process, including the current stage, the equipment responsible for dispensing, and the start / end time of each stage.

[0122] In this embodiment, the aforementioned business display screen is connected to the aforementioned control server.

[0123] Prescription management supports receiving and viewing prescriptions and medical orders from the HIS system and Internet hospital system, and categorizing them according to treatment type. It also supports viewing information such as the status, progress, medication dispensing method, and completion time of each prescription / medical order.

[0124] In the embodiment, a prescription management module can be arranged in the control server to implement the above-mentioned prescription management function.

[0125] Prescription analysis: support comprehensive analysis according to factors such as configuration of dictionary, requirements of prescription / medical order, task queue situation of each intelligent device, etc., to decompose the prescription / medical order into multiple dispensing tasks, and to issue task instructions to each intelligent device at the optimal time.

[0126] In the embodiment, a prescription analysis module can be arranged in the control server to implement the above-mentioned prescription analysis function.

[0127] Task auditing: support auditing of dispensing tasks automatically analyzed and completed, support manual intervention to adjust task attributes, support modification of information including assigned devices, start execution time, etc., and also support system automatic auditing and task issuing.

[0128] In the embodiment, a task auditing module can be arranged in the control server to implement the above-mentioned task auditing function.

[0129] Task monitoring: support monitoring and checking of ongoing dispensing and decocting tasks, including running of existing devices, task queue, inventory situation of medicines, etc. During task monitoring, fault tolerance mechanism is given to part of the abnormal, allowing the platform to dynamically adjust and allocate tasks; when a larger abnormality occurs, manual intervention is supported for processing.

[0130] In the embodiment, a task monitoring module can be arranged in the control server to implement the above-mentioned task monitoring function.

[0131] Task query: support display and query of dispensing tasks analyzed and completed, support to view its source and detailed information, including task source, included prescription and medicine information, estimated time, pre-assigned device, task start and estimated completion time, etc.

[0132] In the embodiment, a task query module can be arranged in the control server to implement the above-mentioned task query function.

[0133] In some embodiments, the functions implemented by the control server are shown in Table 1: Table 1: Function statistics table of control server

[0134] The specific content of prescription analysis is as follows: Knowledge base modeling: Rule modeling is performed through a pharmacy knowledge base, and classification rules are defined according to drug categories (whole box, unpacked, all categories, Chinese medicine decoction granules / decoction pieces, etc.) and diagnosis and treatment types (outpatient, inpatient, ward, Internet hospital, etc.). In terms of implementation, rules are stored in a maintainable knowledge base, supporting dynamic configuration and update by pharmacists and information department personnel.

[0135] Combination strategy: Automatically combine the same patient's prescriptions for the same charge at the same time during task generation to ensure the consistency of the drug order execution. This logic is built into the task generation engine and is achieved by aggregating the charge serial number and patient ID.

[0136] Process allocation: According to the attributes of the drug (whether it needs to be decocted, whether it needs to be manually processed, whether it needs to be decocted first, etc.), the rule engine is called to automatically allocate it to different dispensing processes. This process configuration can be parameterized to support later maintenance.

[0137] Abnormal identification and manual intervention: When RFID, PDA or device state abnormalities are detected, the prescription is marked as an "abnormal drug order". The abnormal drug order enters the manual processing interface, automatically filling in some known information, which can be supplemented or modified manually. Abnormal deletion operations require confirmation by two people, the person in charge and the auditor, and are written into the audit log.

[0138] Manual processing: Provides drug order manual entry and supplementary recording functions, allowing pharmacists to manually fill in information such as prescriptions, drugs, dosages, target windows, etc. The interface supports dictionary calling to reduce the error rate of manual input.

[0139] Prescription information exchange: After HIS charges, the prescription master table and detail table are pushed to the central control system through views / intermediate tables. The central control system reads the data at regular intervals and generates a dispensing task. After dispensing is completed, the central control system automatically writes back to the HIS and clears the completed prescription records.

[0140] Prescription master table field management: Comprehensive analysis of the fields of the prescription master table and detail table provided by HIS, including patient information, diagnosis, drug attributes, usage frequency, cost, etc., to ensure seamless integration with HIS.

[0141] Prescription detail table field management: Drug number, drug name, specification, manufacturer, packaging, quantity, dosage, unit, usage, frequency, supplementary usage, remarks, etc.

[0142] Window allocation and prescription merging: The dispensing window number is returned through the WebService interface and printed on the invoice, and the inventory is locked. For multiple prescriptions for the same patient, the system automatically merges them before execution, reducing repetitive operations.

[0143] The specific details of the task plan management are as follows: Device selection: The dispatch engine obtains the real-time device running status (idle, working, failure), drug category adaptation, queue length, and estimated processing time from the device dictionary. By calling the rules in the expert decision library, the candidate device set is constrained and filtered, and then sorted using heuristic optimization algorithms (such as SPT, EDD) to generate the optimal device allocation scheme.

[0144] Time constraints: When generating the task plan, the window and ward mapping table provided by HIS is read synchronously. The dispatch engine compares the patient check-in time, prescription commitment time, and ward centralized distribution period to automatically adjust the task execution order and ensure that the task is completed within the time window.

[0145] Objective function: The scheduling module has a multi-objective optimization function: taking Makespan, waiting time, and cross-zone transportation cost as variables, and calculating with configurable weights. The optimization result is returned by the algorithm module and written into the database as a reference for task allocation.

[0146] Dynamic recalculation: When trigger events such as device failure, refund, and single insertion are detected, the system event bus notifies the dispatch engine. The engine automatically recalculates available resources and priorities and updates the task queue based on the remaining tasks, while issuing new scheduling instructions in real time.

[0147] ETA prediction: Periodically collect device processing rates and queue lengths, use linear regression and moving average algorithms to calculate the estimated completion time of each task, and push the ETA value to the call system and large screen display in real time.

[0148] Priority strategy: Maintain a priority field in the task table. Emergency and critical tasks are automatically marked with high priority and inserted at the head of the queue during scheduling algorithm execution. The system supports batch plan generation during peak hours, and calls the batch processing program to quickly output large-scale scheduling solutions.

[0149] The specific content of task review is as follows: Automatic review: After task generation, call the rule engine for verification. The rules are stored in the database parameter table and cover drug adaptability, inventory availability, and device status. When the verification result meets all conditions, the task is automatically marked as "reviewed" and immediately issued.

[0150] Manual intervention: For tasks that fail the verification, a prompt is displayed on the review interface showing the unsatisfied rule items. Reviewers can adjust the device selection, modify the priority, or reassign the execution node through the interface. After the adjustment is completed, the system calls the rule engine again for secondary verification, and the task can be issued after the verification is passed.

[0151] Double review: For key operations such as fee refund and abnormal deletion, a double-process control is set up. The process engine will force two different roles to log in and confirm separately, generating a double signature record of the agent and the auditor in the database, ensuring compliance with the operation.

[0152] Abnormal processing: For tasks that enter an abnormal state, a special manual processing interface is provided, which automatically fills in existing data (such as patient, prescription, and drug). Manual can supplement or modify missing fields. After submission, the task table will be written again, and the rule engine will be triggered to re-audit.

[0153] Log and traceability: All audits, interventions, and reviews are written into the audit log library. The log uses non-tamperable storage (WORM storage or blockchain signature). The log content includes operator, timestamp, and operation details, and supports export and later queries.

[0154] Task query and traceability details are as follows: Multi-condition filtering: The task table, prescription table, and device execution table in the database are designed with index fields (such as prescription number, patient ID, device ID, and timestamp), supporting multi-condition combined queries. The query engine uses SQL dynamic splicing and cache optimization to ensure fast return of results under large data volume.

[0155] Prescription and dispensing information details: In the front-end query interface, call the views of the prescription master table and the detail table to display patient basic information, drug number, specifications, quantity, usage, etc. Dispensing information is obtained in real time through the device feedback interface, showing inventory, storage location, and expiration date.

[0156] Task execution details: The execution process of each task is stored in the execution log table, including the full-link data from "generation - distribution - delivery - execution - completion". The front-end can query the execution track through the REST API, and the interface displays it in the form of a timeline.

[0157] Abnormalities and manual intervention records: When a task execution process encounters drug shortages, device blockages, network interruptions, etc., it will automatically mark the task status and enter the manual intervention link. During manual processing, you can modify the prescription, drug, quantity, or target window. All intervention information will be recorded, supporting post-audit and traceability. Abnormal tasks will be written into the exception table, recording the exception reason (shortage, device failure, network interruption), and binding with the manual processing log. Manual modification operations will be written into a separate audit table, saving the pre- and post-modification values, supporting later traceability.

[0158] Trajectory playback: Support visual playback of task execution trajectory, showing task allocation path, device processing progress and manual intervention nodes. For ward dispensing tasks, the delivery path (track / AGV travel route) can also be played back, which is convenient for analyzing the delay reasons. The task flow process is stored as a sequence of events, each event with a timestamp and operation node. When the front end is called, the trajectory graph can be dynamically rendered or the animation can be played, intuitively restoring the task execution process. For ward dispensing, AGV / track operation logs are also loaded to draw the delivery path.

[0159] Historical task tracing: All task data is stored for a long time (not less than one year), supporting conditional retrieval and log export. Prescriptions, dispensing and task execution details can be retrieved and traced at any time, providing a basis for pharmaceutical compliance checks and statistical analysis. Historical data is stored in partition tables, with hot and cold data separation. Data queries within the last 3 months go through online databases, and data exceeding 3 months is automatically archived to the historical database. Front-end query requests are automatically routed to the corresponding database by the central control platform gateway, improving query efficiency.

[0160] Device-drug configuration details are as follows: Manual configuration: Pharmacists can manually set the correspondence between drugs and dispensing devices, storage locations, and batches to ensure accurate dispensing of special drugs. The system provides a configuration management interface, and pharmacists can manually establish the mapping relationship between drugs and devices, storage locations, and batches. Configuration operations are checked through forms to avoid repeated binding or conflicts.

[0161] Device automatic reporting: The system supports automatic acquisition of drug information from the device side, including batch number, expiration date, and inventory quantity, and synchronizes it to the central control. The device reports inventory, batch number, and expiration date through the interface at regular intervals. The central control system receives and writes it into the device-drug relationship table, and checks it with the drug dictionary to ensure data consistency.

[0162] Priority and prohibited configuration rules: Support setting drug allocation priority, prohibited devices, and substitution strategies to ensure reasonable scheduling. The system adds "priority" and "prohibited" fields in the configuration table, and the scheduling engine reads these parameters when allocating tasks, preferring high-priority devices and skipping prohibited devices.

[0163] Configuration verification and trace: Automatically check configuration conflicts and log all configuration changes. When the configuration is submitted, triggers are triggered to detect conflicts (such as the same drug being bound to different storage locations). All changes are automatically logged, including operator, time, old value, new value, and stored in the audit table.

[0164] Task allocation rules are as follows: Treatment type dimension maintenance: Maintain the "equipment + medication dispensing process" combination templates corresponding to different treatment types to ensure accurate task allocation. Maintain the mapping table between treatment types and equipment / processes, and automatically match the corresponding rules based on the treatment type field when generating tasks.

[0165] Canary release and time-based activation: Rules support canary release and can be flexibly activated by time period, window, and ward to meet personalized needs. The rule table supports versioning, with each modification generating a new version. It is allowed for some windows or wards to use the new version first, while other nodes continue to use the old version until a full switch is made.

[0166] Emergency Switchover: Supports one-click switching of emergency strategies, such as quickly switching to manual dispensing procedures in case of equipment failure. Administrators can manually switch to the "Emergency Template" in the rules management interface. Immediately refresh the scheduling engine cache to quickly reassign tasks to backup equipment or manual procedures.

[0167] See appendix Figure 2 The flowchart of the task scheduling method is mainly used to periodically check the task status and trigger decision-making and solution issuance at the appropriate time (when the remaining time of the task is exhausted). It also involves data loading, storage and interaction with other systems.

[0168] First, "other systems" initiate operations through the "external interface," calling the initialization function to load the database into memory, preparing the data foundation for subsequent task scheduling operations. Afterward, threads will be created to carry out specific tasks such as task monitoring.

[0169] 1. Initialization and Data Preparation: "Other Systems" calls the initialization function of "External Interface". "External Interface" loads the database into memory to provide data support for subsequent task processing, and creates relevant threads at the same time.

[0170] 2. Scheduled Task Monitoring: The "Timer Thread" enters an infinite loop. After each loop, it sleeps for 1 second and then calls the task check function to check the remaining time of tasks in the "Task List" (remaining time is decremented by 1). When the remaining time of a task is less than or equal to 0 seconds, a decision is made (combining the previously mentioned comprehensive evaluation of candidate devices and other logic, the optimal solution is selected).

[0171] 3. Solution Distribution and Data Interaction: After the decision is made, the callback function is called to distribute the solution; at the same time, "other systems" call the object transfer function of "external interface" to save the logical object to the database to complete the data storage, and the "communication thread" is in the listening state to receive or process relevant communication information.

[0172] Other system calls to the interface function in the scheme, the interface will save the scheme to the memory, complete the temporary storage of scheme data, for subsequent use; after that, other system calls to the interface in the real-time state transmission function, send the real-time state to the interface.

[0173] II. Dynamic management of decision tasks.

[0174] Through multiple "selection" branches, according to different state and task list, add, delete or time update decision tasks: 1. Branch 1: Add decision task.

[0175] If "in rule reasoning mode and no corresponding decision task in task list", "add decision task and set time according to state", add new pending task for subsequent rule-based task scheduling decision.

[0176] 2. Branch 2: Delete decision task.

[0177] If "the node is in non-rule reasoning mode and there is a corresponding decision task in the task list", "delete the decision task", clean up unnecessary tasks in time to avoid interference.

[0178] 3. Branch 3: Update decision task remaining time.

[0179] In the case of "rule reasoning mode and current scheme number is not consistent with last time", "update decision task remaining time according to current period", ensure that the task time parameter matches the latest scheme.

[0180] III. Verification and effectiveness of rules and configurations.

[0181] The communication thread performs "rule syntax check", "rule semantic check", "scheme check", and checks the legality and rationality of rules and schemes to ensure that subsequent rule-based decision and scheme execution are correct. After verification, "call database operation function to save configuration to database", persistently store related configurations; after "configuration success", and "push state", pass the configuration completed state information to other modules or system to inform that the configuration has taken effect.

[0182] IV. Data transmission and memory storage.

[0183] Other system calls to the interface function in the data transmission function, the interface receives the execution call and saves the related data to the memory, completes the data storage after this series of operations, and provides data support for subsequent processes.

[0184] Overall, this part of the process is in the task scheduling process, according to the system mode, task state and scheme change, dynamic adjustment decision task, while ensuring the correctness and effectiveness of the rules and configuration, is the key link from "task monitoring" to "decision execution" to "configuration into effect" of task scheduling.

[0185] Through such a process, the automation management of the task from monitoring to decision to execution feedback (scheme issuance, data storage) is realized, which can timely arrange the task scheduling, ensure the task to be executed as expected, and the related data can be properly stored, facilitating subsequent query, analysis or other systems based on these data to carry out further operation. The monitoring of "communication thread" also prepares for the possible subsequent communication interaction.

[0186] The specific content of the device dictionary is as follows: Basic information management: the system maintains the basic information of all devices, including classification, device name, device ID, brand / supplier, purchase date, fixed asset code, etc. The system automatically writes the basic information such as device ID, model, supplier, and purchase date when the device is connected, and supports manual supplement of fixed asset code.

[0187] Running and capability parameters: the processing capacity, adaptation range, limitation conditions, and interface parameters of each device are included in the dictionary management. The throughput rate, compatible drug types, and interface protocol information of each device are reported through the interface regularly and written into the device dictionary table for the scheduling engine to call.

[0188] Life cycle management: supports device state maintenance, update, and retirement, ensuring complete device information. The system maintains the full life cycle state of "enable-run-disable-retire" for devices, supports regular maintenance reminders and state switching.

[0189] The specific content of the diagnosis and treatment dictionary is as follows: Diagnosis and treatment type maintenance: supports establishing dictionaries according to types such as outpatient, inpatient, ward, and internet hospital, and defining dispensing process templates. Administrators can establish diagnosis and treatment types such as outpatient, inpatient, ward, and internet hospital in the system, and bind dispensing process templates for them.

[0190] Window and ward mapping: mapping diagnosis and treatment types with dispensing windows and ward distribution paths to ensure accurate task allocation. The window and ward mapping information provided by HIS is automatically synchronized through the interface and written into the diagnosis and treatment dictionary table, which is directly called when generating tasks.

[0191] Flexible expansion: new diagnosis and treatment types and processes can be added or adjusted according to changes in hospital business. When a new diagnosis and treatment scenario is added, administrators can add dictionary items in the interface and import corresponding processes, which will take effect immediately.

[0192] The specific content of the permission management is as follows: Role-based access control (RBAC) model: The system adopts the RBAC model to assign permissions based on organizational roles (pharmacy, window, ward, equipment maintenance, information department, etc.). Users are bound to roles, and roles are bound to permissions. The granularity of permissions can be refined to "function modules" and "data ranges." The system supports function-level and data-level permission control, and administrators can grant permissions based on windows, wards, equipment, etc.

[0193] Audit mechanism: All permission operations are automatically recorded by the log module, and the logs are stored in the audit database, supporting retrieval and export.

[0194] Security mechanism: The system supports OAuth2 single sign-on, and password complexity rules can be configured. Secondary authentication is enabled when necessary.

[0195] The specific content of system parameter settings is as follows: Global parameters: Task timeout threshold, batch strategy, ETA calibration, window mapping, message push, etc. can be flexibly set. The system provides a parameter management interface, and administrators can adjust task timeout threshold, batch strategy, window mapping rules, etc. Parameter modifications are synchronized to the scheduling engine cache in real time.

[0196] Scheduling weight: The weight parameter in the scheduling algorithm can be adjusted online, supporting gray release and rollback. The scheduling algorithm weight (processing time, waiting time, transportation cost, etc.) is stored in the parameter table, and can be adjusted online. After modification, the system automatically triggers gray testing, and promotes globally after verification.

[0197] Rule library versioning: Support rule version management and comparison to ensure that changes are traceable. All rule and parameter changes automatically generate version numbers, supporting version comparison and rollback.

[0198] The specific content of the system data interface is as follows: Interface implementation architecture: The system manages the interaction between HIS, central control, and devices through the interface gateway module. Interfaces support WebService, HTTP(S)+XML / JSON, database views / stored procedures, middleware message queues, etc. The specific mode can be flexibly selected according to the hospital's existing network. All interfaces are parameterized managed through configuration files, realizing quick expansion and maintenance.

[0199] Basic information interface: Drug dictionary, storage location, department, dispensing window, pharmacist, etc. data are obtained through the views or intermediate tables provided by HIS; the central control system establishes a timed task and incremental synchronization mechanism, automatically detects and updates information every fixed time (e.g. 30 seconds). To ensure consistency, the system checks key fields (e.g. drug code, storage location ID) when writing, and generates error logs and pushes alarms when conflicts occur.

[0200] In some embodiments, the system further comprises a hot backup machine, which is used for manual processing in the case of server downtime, network failure, etc. The local offline processing receives but has not completed the prescription, and the fault period is completed by dispensing (boiling). After the fault is recovered, the local data is synchronized to the server to ensure the unity of business data.

[0201] The logistics order management supports the interface of the logistics system for the prescriptions that need to be delivered to the home. For the completed dispensing task, it supports automatic ordering, manual supplementing and canceling ordering to the logistics system, supports historical logistics order query, and supports viewing order details and trajectory.

[0202] In the embodiment, a logistics order management module can be arranged in the control server to realize the above-mentioned logistics order management function.

[0203] The device management and early warning support generating a daily early warning report after the daily work stops according to the pre-set device maintenance information, the actual operation condition and the operation log of the device, reminding the workers to check / repair / replace the device to ensure the continuous normal operation of the production line. It supports adding a critical failure maintenance list, monitoring the working state of each motor through a current transformer, and evaluating and warning. It supports calculating the required inventory of each intelligent dispensing device by counting the consumption of various drugs at different times, converting it into the required cell number of each drug, and reminding the device maintenance personnel to change the number of each drug cell through the form of a report.

[0204] In the embodiment, a device management and early warning module can be arranged in the control server to realize the above-mentioned device management and early warning function.

[0205] In some embodiments, a hot backup machine is further included, which is used for manual processing in the case of the control server or network abnormality, and offline processing of received but not completed prescriptions. In some embodiments, a business large screen connected with the control server is further included, which is used to display the operation of the dispensing and dispensing business in the form of a plan and a timing data refresh, supports real-time statistics and chart display of business data, and supports real-time query of prescription details and detailed data of each prescription in the dispensing or boiling process. In some embodiments, referring to the attached Figure 3 and the attached Figure 4 The control server further comprises a diagnosis and treatment management system, a central control management system, a device detection and early warning system, a dispensing management system, a case learning system, and an operation and maintenance management system.

[0206] The diagnosis and treatment management system is used for information management and scheduling of the whole diagnosis and treatment process.

[0207] The central control management system is configured to coordinate and link the diagnosis and treatment management system, the equipment detection and early warning system, the dispensing management system, the case learning system, and the operation and maintenance management system.

[0208] The dispensing management system is configured to manage the whole process of drug dispensing.

[0209] The case learning system is configured to accumulate historical case data.

[0210] The equipment detection and early warning system is configured to receive data collected by the collection and detection server from the detection device, and determine whether the detection device needs to be replaced according to the collected data. The operation and maintenance management system is configured to update the equipment data after the detection device is replaced in real time.

[0211] In the control server, the above-mentioned systems are software modules, each of which undertakes different functions and cooperatively supports the efficient operation of the medical process. The specific explanations are as follows: The diagnosis and treatment management system (module) is configured to focus on the information management and scheduling of the whole process of patient diagnosis and treatment. It integrates the basic information of patients (such as medical history, symptoms, and examination results) to assist doctors in quickly understanding the patient's condition, interfaces with the links of inquiry, examination, diagnosis, records the diagnosis and treatment decisions (such as prescription and treatment plan), and transmits key information to other modules (such as synchronizing the prescription information to the dispensing management system to trigger the dispensing process).

[0212] The central control management system (module) is configured to serve as a “central dispatcher” to coordinate the linkage of each system module and hardware device.

[0213] It monitors the running state of each module (such as the dispensing management system) and device (such as the drug dispensing mechanical arm) in real time, allocates resources and schedules tasks (such as instructing the dispensing device to execute which order) according to the preset rules or real-time data (such as device load and order priority), handles cross-module collaboration requirements (such as when the diagnosis and treatment system submits a new prescription, it notifies the dispensing system to prepare, and also informs the queue generation module to sort).

[0214] The dispensing management system (module) is configured to manage the whole process of drug dispensing to ensure accurate and efficient dispensing. It receives the prescription information from the diagnosis and treatment system, checks the drug inventory and dose rationality, sends the dispensing demand to the central control system, drives the device to perform the operations of taking medicine, dispensing, and checking, records the dispensing progress (such as “medicine taken” and “to be checked”), and feeds back the abnormalities (such as insufficient inventory).

[0215] Case learning system (module), core function: based on historical case data, auxiliary model optimization and knowledge precipitation. Collect, desensitize and structure historical diagnosis and treatment, dispensing data (such as successful cases, abnormal handling records); Provide training samples for various AI models in the control server to improve model accuracy; Extract typical case rules (such as the optimal processing flow of a certain order), optimize system rules.

[0216] The device detection and early warning system receives data collected by the collection and detection server on the detection device, and determines whether the detection device needs to be replaced according to the collected data.

[0217] In this embodiment, the collection and detection server sends the collected data to the control server, and the device detection and early warning system in the control server determines whether the detection device needs to be replaced according to the maximum value and the minimum value of the detection device, for example, if the collected data is greater than the predetermined maximum value or less than the predetermined minimum value, it is determined that the detection device is faulty and needs to be replaced.

[0218] The operation and management system is used to update the equipment data of the detection device after replacement in real time.

[0219] The Internet hospital system and the hospital integrated management system connect the control server. The Internet hospital system and the hospital integrated management system as external systems connected to the control server, respectively undertake different functions, and cooperate with the modules in the control server to form a complete medical service system: the Internet hospital system provides online medical services and connects online and offline medical processes. The hospital integrated management system, as the "data hub" of the hospital's internal information systems, realizes cross-system data interconnection and process integration.

[0220] In some embodiments, an intelligent management platform is constructed: the platform seamlessly connects HIS (hospital information system), EMR (electronic medical record), PIVAS (intravenous configuration center), traditional Chinese medicine intelligent decoction system and other hospital systems, and realizes millisecond-level synchronization of medical order data. In the device cooperation layer, a unified Internet of Things protocol gateway is established to support the access of at least 10 types and 50 sets of devices (including injection dispensing machines, decoction piece dispensing cabinets, automatic packaging machines, etc.). A dynamic task allocation engine based on deep reinforcement learning is developed, which can generate the optimal task scheduling scheme according to the prescription drug composition, device load state, logistics path and other factors. In terms of safety and backup, an offline processing mechanism of hot standby machine is established, and when network and data interface failure occurs, the system can run independently until all received prescriptions / medical orders are dispensed and dispensed.

[0221] In some embodiments, the medicine whole-process intelligent industrial control management system is a management system based on Internet of Things and intelligent task scheduling algorithm, which realizes the digitization and standardization management of the whole-process of hospital medicine dispensing, decocting and dispensing through the cooperation of intelligent devices and management software. The core of the system is composed of multiple automatic devices and management platforms: different types of devices are used to dispense (decoct) and dispense different types of medicines such as tablets, injections, decocted pieces, and the dispensed medicines are collected by conveyors to the window or self-service medicine dispensing machine; the management platform obtains the prescriptions / medical orders of the whole hospital and Internet hospital through data interface, and analyzes and splits them into sub-tasks, which are efficiently and reasonably distributed to each intelligent device for dispensing (decocting), and the completed medicines are delivered to patients / nurses in different ways to meet the needs of various diagnosis and treatment services for medicine dispensing and use.

[0222] Referring to the accompanying drawings Figure 5 , the business process is as follows: start; obtain prescription and medicine arrangement information; analyze medicine according to diagnosis and treatment; generate each sub-task; pre-allocate task; task management and scheduling algorithm, comprehensive analysis of the time spent by the medicine dispensing device, the estimated completion time, the medicine taking / delivery to home, whether the medicine taking time is clear, single patient / ward medicine arrangement, and other factors affecting the task; form and issue the task; send a medicine dispensing completion notification after the medicine dispensing device completes the medicine dispensing; obtain the medicine cabinet number; and calculate the remaining resources of the electronic medicine cabinet. The knowledge base includes intelligent devices and medicine knowledge base. Various algorithms are stored in the algorithm rule base for generating each sub-task. Various machine learning models described above can also be stored. The above business process can be implemented by a control server, or by a control server and other servers together.

[0223] To realize the task sequencing and issuing of the medicine dispensing device (comprehensively considering the dispensing time, estimated completion time, delivery time limit, ward medicine arrangement, etc.), the whole process of "data integration → multi-dimensional modeling → dynamic sequencing → task issuing" needs to be implemented, and the specific steps are as follows: I. Data integration: collect real-time data of all influencing factors. Collect key information from various systems / devices as the basis for sequencing: medicine dispensing device data: single task processing time (e.g. a device takes an average of 30 seconds to dispense 1 box of medicine, and 2 minutes to arrange medicine to the ward tray); current device status (idle / busy / fault), number of queued tasks and estimated completion time (e.g. device A has 5 tasks and will be idle in 10 minutes).

[0224] Order / patient information: patient information (belonging to the ward, whether inpatient / outpatient, such as ward medicine arrangement needs to be processed according to the department); delivery requirement (whether to deliver to home, clear medicine taking time window, such as "15:00-16:00 delivery"); task priority (such as emergency patients > ordinary inpatients > outpatient delivery to home users).

[0225] Other influencing factors: drug properties (e.g., cold-chain drugs need to be handled first to avoid expiration); external constraints (e.g., ward drug distribution needs to be completed before nurses' ward rounds, and delivery to home is limited by traffic periods).

[0226] II. Multi-dimensional modeling: Convert factors into computable ranking indicators.

[0227] Quantify the collected information to generate core indicators required for ranking: Time indicators: absolute deadline of tasks (e.g., "delivery to home must be completed by 16:00" and "ward drug distribution must be completed by 8:00").

[0228] Device expected processing time (current task number x single task time consumption + new task time consumption, e.g., device A has existing tasks that take 10 minutes, and new tasks take 2 minutes, then it is expected to be completed in 12 minutes).

[0229] Buffer time (reserve time for unexpected situations, e.g., add 20 minutes of traffic buffer for delivery to home).

[0230] Priority indicators: calculate the comprehensive priority score for each task, the formula can be set as: priority score = basic priority (emergency 3 points / inpatient 2 points / outpatient 1 point) + time urgency (1 / remaining available time) + drug importance (cold-chain drugs add 1 point). The higher the score, the higher the ranking.

[0231] Ward / delivery aggregation indicators: for drug distribution tasks in the same ward, calculate "time saved by centralized processing" (e.g., 5 tasks in the same ward take 10 minutes to process separately, and 7 minutes to process centrally, so the aggregated priority is increased); For delivery to home tasks in the same area, cluster by geographical location (e.g., orders in the same neighborhood are arranged centrally to reduce delivery round-trip time).

[0232] III. Dynamic ranking algorithm: generate the optimal task sequence based on comprehensive indicators.

[0233] Based on the above indicators, use "multi-objective optimization algorithm" to rank, balance efficiency and constraints: Algorithm selection: simple scenario: use "weighted ranking method", rank by "priority score descending + deadline ascending + ward / area aggregation"; complex scenario: use "genetic algorithm" or "simulated annealing algorithm", minimize total processing time and device idle rate under the premise of meeting the deadline.

[0234] Ranking logic example: 1. First, filter out tasks with the earliest absolute deadline (e.g., ward drug distribution tasks that need to be completed by 8:00), and assign them to idle devices first. 2. For tasks in the same ward, merge them into batch tasks (e.g., issue 3 medication dispensing tasks in the internal medicine department to equipment B at the same time to reduce equipment switchover time). 3. Home delivery tasks are sorted by "priority score + regional clustering" to ensure that high-priority orders in the same region are processed continuously; 4. Generate a dedicated task queue for each device, and label it with "estimated start time" and "estimated completion time" (e.g., queue for device C: Task 1 (8:00-8:02) → Task 2 (8:02-8:05)...).

[0235] See appendix Figure 6 Another business process diagram shown illustrates that the equipment objects included in the medicine dispensing cabinet include an automatic dispensing machine, a critical dispensing machine, a decoction unit, and a robot. A control server subscribes to messages from the message management server, preprocesses these messages, performs AI-based decision-making using a decision base, generates a medication order queue, and sends this queue to a hot standby machine for backup. The queue is queried and refreshed; based on anomaly feedback data from the dispensing equipment, the queue is scanned and adjusted to generate completed medication orders, which are then stored in the log.

[0236] The sources of the aforementioned prescriptions include the following: 1. Outpatient services - sporadic; 2. Inpatient services - bulk; 3. Emergency services; 4. Inpatient services - temporary; 5. Intravenous preparation.

[0237] II. Drug categories include the following: 1. Western medicine; 2. Medicinal slices; 3. Instant granules; 4. Meal packets; 5. Injections; 6. Decoctions.

[0238] III. Prescription types include: 1. Single appointment; 2. Multiple appointments; 3. Appointment (at home or hospital).

[0239] IV. Medication collection methods include the following: 1. Window; 2. Automatic medicine cabinet; 3. Express delivery.

[0240] V. Dispensing types include: 1. Whole box; 2. Combined whole boxes; 3. Loose.

[0241] VI. Abnormal categories include: 1. Damage to individual dispensing machines; 2. Missing medications; 3. Large-scale machine shutdown.

[0242] In an embodiment, the data of the hospital is as follows: maximum concurrency: 30,000 / day. Peak hospitalization (9:30-10:00) 20,000. Outpatient: 15,000. 300 single / second. 2, dispensing one-time dispensing accuracy: > 99.99%. 3, the longest time to receive a drug order: Western medicine 5-6 minutes, traditional Chinese medicine: 10-15 minutes. 4, the longest time to produce a dispensing order: box 1 minute, decoction pieces: more than 10 minutes, manual 15-20 minutes (exempt from decoction granules). 5, the longest time for system expansion in a year: <10 minutes / year. 6, manual to automatic conversion: <30 minutes. 7, the maximum number of equipment: >50 sets of main equipment. 8, false alarm rate: <5%. 9, real-time hot backup: data hot backup (hard disk RAID).

[0243] Under the framework of deepening the reform of the medical and health system in the country, the system is closely related to the top policy design, and in the hospital pharmacy, through the automation equipment, the closed-loop supervision of the medicine from the prescription receiving, dispensing to delivery can be realized more efficiently and accurately.

[0244] The mature application of Internet of Things technology in the medical field provides a solid support for the system. The material transportation network composed of modular conveyor belts and AGV cars has been successfully operated in many third-grade class-A hospitals. The popularization of technology makes real-time data exchange between devices possible, removing technical obstacles for the construction of the central dispatching system.

[0245] Improve patient service. Change the traditional dispensing experience. Through the intelligent sorting system and parallel processing architecture, the prescription dispensing time is compressed, and the real-time dispensing progress can be viewed through WeChat. In the safety dimension, the "RFID tag + machine vision" double-checking mechanism is adopted to ensure that the medicine and the prescription are 100% matched (error rate controlled at one hundred thousandth). For chronic disease patients, the system can seamlessly connect to the Internet hospital platform to realize "online prescription- automatic dispensing- home delivery" one-stop service, effectively responding to the convenient medical requirements of the National Health Commission to "reduce the number of patient trips".

[0246] Improve hospital operations. The central pharmacy model will bring efficiency improvements. After integrating all the pharmacies in the hospital and realizing full automation of dispensing, the dispensing capacity is improved, and the human resources are reduced (mainly responsible for equipment maintenance and emergency handling), which greatly saves the cost of human resources. In terms of space utilization, the reduced traditional manual dispensing window can be transformed into a value-added service space such as a rational drug consultation area. In terms of quality control, the system automatically records temperature and humidity sensor data, equipment operation logs, and dispensing time at each link, meeting the requirements of traceability throughout the entire process of medicine.

[0247] Industry innovation demonstration. As the first intelligent pharmacy covering all types of drug dispensing and dispensing, the system will fill the gap in the industry: its "dynamic task scheduling management" can solve the problem of coordination of different dosage forms. More importantly, the big data of drug consumption accumulated by the automated process can provide accurate basis for hospital DRG cost accounting and help medical insurance payment reform.

[0248] Establish a quantitative index system: in terms of automation coverage, achieve 100% automatic packaging of western medicine tablets / capsules, and automatic packaging of traditional Chinese medicine decoction pieces with a breakthrough of 85% (the remaining 15% is manually reviewed for special medicinal materials). The service time limit for outpatient and inpatient western medicine is strictly implemented within 6 minutes, and the service time limit for traditional Chinese medicine is within 10-15 minutes. The one-time dispensing accuracy rate is >99.99%, and the longest time for manual processing to automatic processing of equipment failure is not more than 30 minutes. The longest time for automatic production or dispensing: box 1 minute, decoction pieces 10 minutes, and decoction-free granules 15-20 minutes. The system supports a maximum of 30,000 prescriptions (medical orders) per day, including 20,000 during the inpatient peak period (9:30-10:00) and 15,000 during the outpatient peak period. The maximum support is 300 prescriptions per second. The longest downtime of the system is not more than 10 minutes per year. The false alarm rate is <5%.

[0249] Develop a "Standardized Operation Manual for Unmanned Pharmacies" covering a number of SOP processes such as daily inspection of equipment, emergency power failure protection, etc. Simultaneously, establish a three-level emergency mechanism: activate the manual assistance mode in case of automation failure, and use the hot standby machine local independent operation mechanism in case of network interruption to ensure the continuity of central pharmacy services.

[0250] In some embodiments, the above industrial control management system includes a monitoring and management module for real-time monitoring of drug orders and equipment status, pushing strategy information and generating statistical reports; An exception handling module for interfacing with pharmacists to implement manual entry, confirmation and processing of abnormal drug orders; A hot standby module for implementing dual hot standby and state switching of drug orders and equipment to ensure business continuity; A warning module for completing statistical analysis, trend prediction and warning push based on real-time operation data of the equipment; A dispensing decision module for calling a knowledge base and decision tree to perform drug order scheduling and abnormality judgment; An interface and conversion module for interfacing with the diagnostic system and third-party systems, unifying data formats and pushing to the MQ channel.

[0251] Based on the same inventive concept, the present application proposes a drug full-process intelligent industrial control management method, which is implemented based on the above-mentioned drug full-process intelligent industrial control management system. The above-mentioned drug full-process intelligent industrial control management system includes: A control server, a message management server, a device management server, a collection and detection server and an auxiliary device management server connected with the control server respectively, and a dispensing management server; The method comprises: The dispensing management server performs digital management on the whole process of drug dispensing, distribution and inventory, specifically including: drug information management, dispensing process control, inventory monitoring and early warning, and record and trace.

[0252] The message management server adopts a message subscription mechanism to decouple the control server and the dispensing management server and make them cooperate asynchronously.

[0253] The control server controls the device management server, the collection and detection server and the auxiliary device management server.

[0254] The device management server controls the drug distribution device to distribute drugs under the control of the control server.

[0255] The auxiliary device management server controls the drug decocting device to decoct drugs under the control of the control server.

[0256] The collection and detection server controls the detection device to detect under the control of the control server.

[0257] Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure. This application is intended to cover any variations, uses or adaptive changes of this disclosure that follow the general principles of the disclosure and include common knowledge or conventional technical means in the art not disclosed in the disclosure. The specification and examples are only regarded as exemplary, and the true scope and spirit of the disclosure are indicated by the following claims.

Claims

1. A medicine whole-process intelligent industrial control management system, characterized in that, Comprise: A control server connected to a message management server, a device management server, a collection and detection server, and an auxiliary device management server, respectively, for controlling the device management server, the collection and detection server, and the auxiliary device management server; A dispensing management server for digitally managing the whole process of drug dispensing, distribution, and inventory, specifically including: drug information management, dispensing process control, inventory monitoring and early warning, and record and traceability; The message management server is connected to the control server and the dispensing management server; for using the message subscription mechanism, so that the control server and the dispensing management server are decoupled and asynchronously collaborate; The device management server is used to control the drug dispensing device under the control of the control server to dispense drugs; The auxiliary device management server is used to control the drug decoction device to decoct drugs under the control of the control server; The detection device comprises: 2.The medicine whole-process intelligent industrial control management system according to claim 1, characterized in that, A bar code / two-dimensional code scanner for scanning bar codes or two-dimensional codes on drug packaging; An RFID reader / writer for reading RFID tag information attached to the drug using radio frequency identification technology; An image recognition detector for capturing drugs through a camera and detecting the shape, color, and size of the drugs through image algorithms; A weight detection device for detecting the weight of solid drugs; A temperature and humidity sensor for monitoring the temperature and humidity of the drug storage and dispensing environment; A face recognition / fingerprint recognition device for identity verification when a pharmacist or patient picks up drugs; An operation behavior monitoring camera for video monitoring, behavior analysis, and detection of whether the drug dispensing process meets the standard process.

3. The intelligent industrial control management system for the whole process of drugs according to claim 1, wherein the dispensing management server uses machine learning algorithms to optimize inventory and order processing, inventory forecasting and dynamic replenishment, uses a time series model to predict future drug demand based on historical order data, and pushes replenishment suggestions to the control server in advance; And, Order priority intelligent sorting combines user information, drug characteristics, and device load to dynamically sort orders using a reinforcement learning model, and sends orders with high priority to the control server first, so that the control server allocates orders with high priority to the device management server first, improving the response speed of urgent orders.

4. The intelligent industrial control management system for the whole process of drugs according to claim 1, wherein the device management server uses machine learning algorithms to predict device failures, collects device data, uses anomaly detection algorithms to learn the normal operation mode of the device, identifies abnormal states in real time, predicts failure risks in advance, and sends maintenance instructions to the control server; And for the position deviation of the mechanical arm picking up drugs, use a supervised learning model to correct the action parameters in real time.

5. The intelligent industrial control management system for the whole process of drugs according to claim 1, wherein ​ ​ ​ The control server is configured to analyze real-time loads of each medicine dispensing device by using a clustering algorithm, dynamically allocate tasks in combination with order quantity prediction, and the like. An abnormal order emergency processing is performed by using a decision tree model to automatically generate a replacement scheme when the dispensing management server feeds back that the order medicine is out of stock or the device management server feeds back that the device is temporarily malfunctioning. 6.The medicine whole-process intelligent industrial control management system according to claim 1, wherein the control server is further configured to perform dictionary maintenance, medicine configuration, diagnosis and treatment task configuration, prescription management, prescription analysis, task review, task monitoring, task query, and task scheduling. In the task scheduling, a candidate device score is calculated by using the following formula: wherein w1 is a shortest processing time weight value; Score = w1 SPT + w2 EDD + w3 SetupCost + w4 LocationCost + w5 Reliability SPT is the shortest processing time; w2 is an earliest due date weight value; EDD is the earliest due date; w3 is a switching cost weight value; SetupCost is the switching cost; w4 is a location distance weight value; LocationCost is the location distance; w5 is a reliability weight value; Reliabilit is the reliability. A hot standby server is further included to perform offline processing on a prescription that has been received but not yet completed when the control server or the network is abnormal.

7. The intelligent industrial control management system for whole process of medicine according to claim 1, characterized in that, A business large screen connected to the control server is further included, and the business large screen is configured to display operation of the dispensing and dispensing business in the form of a plan view and a timing data refresh, support real-time statistics and chart display of business data, and support real-time query of details of a prescription and detailed data of each prescription in the dispensing or decoction process. 8.The intelligent industrial control management system for whole process of medicine according to claim 1, characterized in that, The control server further includes a diagnosis and treatment management system, a central control management system, a device detection and early warning system, a dispensing management system, a case learning system, and an operation and maintenance management system. 9.The intelligent industrial management system for whole-process of medicine according to claim 1, wherein, The diagnosis and treatment management system is configured to perform information management and scheduling of a whole diagnosis and treatment process. The central control management system is configured to coordinate and link the diagnosis and treatment management system, the device detection and early warning system, the dispensing management system, the case learning system, and the operation and maintenance management system. The dispensing management system is configured to perform whole-process management of medicine dispensing. The case learning system is configured to accumulate historical case data. The device detection and early warning system is configured to receive data collected by the collection and detection server from the detection device, and determine whether the detection device needs to be replaced according to the collected data. The operation and maintenance management system is configured to update device data after the detection device is replaced in real time. A medicine whole-process intelligent industrial control management system is implemented, and the medicine whole-process intelligent industrial control management system includes:

10. A medicine whole-process intelligent industrial control management method, characterized in that, A control server, a message management server, a device management server, a collection and detection server, an auxiliary device management server, and a dispensing management server connected to the control server; The method includes: The dispensing management server performs digital management of whole processes of medicine dispensing, dispensing, and inventory, specifically including medicine information management, dispensing process control, inventory monitoring and early warning, and record and traceability. The message management server uses a message subscription mechanism to decouple the control server and the dispensing management server and perform asynchronous collaboration. ​ The control server controls the device management server, the collection and detection server, and the auxiliary device management server; The device management server controls the medicine dispensing device to dispense medicine under the control of the control server; The auxiliary device management server controls the medicine decocting device to decoct medicine under the control of the control server; The collection and detection server controls the detection device to detect under the control of the control server.

Images