A medicine whole-process intelligent industrial control management method and system

Abstract

The present disclosure relates to a medicine whole-process intelligent industrial control management method and system, the system comprising: a control server connected with a message management server, a device management server, a collection and detection server and an auxiliary equipment management server respectively; the message management server connected with the control server and a dispensing management server; a message subscription mechanism is adopted to decouple the control server and the dispensing management server and make them cooperate asynchronously; the auxiliary equipment management server is used to control a medicine decocting device to decoct medicine under the control of the control server; and the collection and detection server is used to control a detection device to detect under the control of the control server. The technical scheme 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 medicine whole process in a hospital.

Description

Technical Field

[0001] This disclosure relates to the field of medical technology, and in particular to a method and system for intelligent industrial control management of the entire drug production process. Background Technology

[0002] As people's living standards improve, going to the hospital for medical treatment and getting medication is a frequent occurrence. Due to the large flow of people in hospitals, waiting at the pharmacy window is often necessary. Currently, the main problem facing hospital pharmacy operations is inefficiency. During peak hours, the average waiting time for patients in some hospitals exceeds 30 minutes, easily causing congestion at the pharmacy windows. Summary of the Invention

[0003] To overcome the problems existing in related technologies, this disclosure provides a method and system for intelligent industrial control management of the entire drug process, in order to solve the problem of low efficiency in drug purchase for users in related technologies.

[0004] According to a first aspect of the present disclosure, a fully intelligent industrial control management system for the entire pharmaceutical process is provided, comprising:

[0005] The control server is connected to the message management server, the device management server, the data acquisition and detection server, and the auxiliary device management server, respectively, and is used to control the aforementioned device management server, the aforementioned data acquisition and detection server, and the aforementioned auxiliary device management server.

[0006] The medication management server is used for the digital management of the entire process of medication dispensing, distribution, and inventory. Specifically, it includes: medication information management, medication process control, inventory monitoring and early warning, and recording and traceability.

[0007] The aforementioned message management server connects to the aforementioned control server and medication management server; used for

[0008] A message subscription mechanism is adopted to decouple the control server and the medication management server and enable asynchronous cooperation.

[0009] The aforementioned equipment management server is used to control the dispensing of medicines by the medicine dispensing equipment under the control of the aforementioned control server;

[0010] The aforementioned auxiliary equipment management server is used to control the medicine decoction equipment to decoct medicines under the control of the aforementioned control server.

[0011] The aforementioned data acquisition and detection server is used to control the detection device to perform detection under the control of the aforementioned control server.

[0012] Secondly, this application proposes a method for intelligent industrial control management of the entire drug production process. The intelligent industrial control management system for the entire drug production process includes:

[0013] A control server, and message management servers, device management servers, data acquisition and detection servers, and auxiliary equipment management servers connected to the aforementioned control server; a medication management server;

[0014] The control server controls the aforementioned equipment management server, the aforementioned data acquisition and detection server, and the aforementioned auxiliary equipment management server;

[0015] The above methods include: the medication management server digitally manages the entire process of medication dispensing, distribution, and inventory, specifically including: medication information management, medication dispensing process control, inventory monitoring and early warning, and recording and traceability;

[0016] The aforementioned message management server employs a message subscription mechanism to decouple the aforementioned control server and the aforementioned medication management server, enabling asynchronous collaboration.

[0017] The aforementioned equipment management server, under the control of the aforementioned control server, controls the dispensing of medicines by the medicine dispensing equipment;

[0018] Under the control of the control server, the auxiliary equipment management server controls the medicine decoction equipment to decoct the medicine.

[0019] Under the control of the aforementioned control server, the aforementioned data acquisition and detection server controls the detection device to perform detection.

[0020] The technical solutions provided by the embodiments of this disclosure may include the following beneficial effects:

[0021] Compared with existing technologies, the technical solution of this application sets up a control server, and connects it to a message management server, an equipment management server, a data acquisition and detection server, and an auxiliary equipment management server. The message management server adopts a message subscription mechanism to decouple the control server and the dispensing management server, enabling asynchronous collaboration. The auxiliary equipment management server, under the control of the control server, controls the drug decoction equipment to decoupling the drugs. The data acquisition and detection server, under the control of the control server, controls the detection device to perform detection. The technical solution of this application features a clear division of labor among each server, efficient collaboration, and decoupling of the message management server, making it suitable for scenarios requiring efficient drug distribution throughout the entire process in hospitals.

[0022] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0024] Figure 1 This is a schematic diagram of an intelligent industrial control management system for the entire pharmaceutical process, according to an exemplary embodiment.

[0025] Figure 2 This is a flowchart illustrating a task scheduling method according to an exemplary embodiment;

[0026] Figure 3 This is a block diagram illustrating various systems in a control server according to an exemplary embodiment;

[0027] Figure 4 This is a schematic diagram illustrating a device detection and early warning system according to an exemplary embodiment;

[0028] Figure 5 This is a business process diagram illustrated according to an exemplary embodiment;

[0029] Figure 6 This is another business process diagram illustrated according to an exemplary embodiment. Detailed Implementation

[0030] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0031] Based on this, this application proposes an intelligent industrial control management system for the entire drug production process, see appendix. Figure 1 ,include:

[0032] Control server 01 is connected to message management server 02, device management server 06, data acquisition and detection server 05 and auxiliary device management server 04 respectively, and is used to control device management server 06, data acquisition and detection server 05 and auxiliary device management server 04.

[0033] The medication management server 03 is used for digital management of the entire process of medication dispensing, distribution, and inventory. Specifically, it includes: medication information management, medication process control, inventory monitoring and early warning, and recording and traceability.

[0034] The message management server 02 is connected to the control server 01 and the medication management server 03; it is used to employ a message subscription mechanism to decouple the control server 01 and the medication management server 03 and enable asynchronous cooperation.

[0035] The device management server 06 is used to control the drug dispensing equipment to dispense drugs under the control of the control server.

[0036] The auxiliary equipment management server 04 is used to control the medicine decoction equipment to decoct medicines under the control of the control server 01.

[0037] The data acquisition and detection server 05, under the control of the control server 01, controls the detection device to perform detection, thereby ensuring the accuracy, safety, and compliance of drug dispensing.

[0038] The technical solution of this application, in a distributed system composed of multiple independent servers, features clear division of labor among each server, efficient collaboration, and overall system stability.

[0039] The functions of the various types of servers described above are as follows: The control server, acting as the system's "command center," is responsible for receiving instructions from higher levels, such as user orders and administrator operations, and coordinating with other servers to complete the process. The control server does not directly handle specific business operations, such as checking inventory or controlling equipment. Instead, it schedules other servers through messages or commands, avoiding becoming an "all-powerful but cumbersome" node. For example, after a user places an order, the control server triggers the entire process of "inventory check → equipment scheduling → result feedback," while only making decisions and coordinating the process.

[0040] The medication management server focuses on medication-related data management and business logic, such as inventory, expiration dates, and inbound / outbound processes. It isolates medication data from other business processes, such as equipment control, to avoid data clutter. For example, inventory changes are handled exclusively by this server, while other servers can only query or request data. Individual optimizations are supported, such as adding medication expiration alerts, without requiring modifications to the control server.

[0041] The equipment management server manages the status and operation of medicine dispensing equipment, such as smart medicine cabinets and sorting devices. It centrally handles equipment startup / shutdown, fault detection, and action execution, preventing other servers from directly operating the equipment hardware and reducing hardware dependency. For example, upon receiving a dispensing instruction, it is responsible for driving the equipment to dispense medicine accurately and providing feedback on success or failure; other servers do not need to know the specific model or interface of the equipment.

[0042] The equipment management server monitors the abnormal status of systems or equipment in real time, such as equipment failure, insufficient medicine inventory, and network fluctuations. It proactively detects problems and triggers alerts. For example, if a sensor detects an abnormal temperature in a medicine cabinet, it immediately pushes a message to the control server to prevent the problem from escalating. This reduces the monitoring burden on other servers, allowing them to focus on core business operations.

[0043] The message management server can also be positioned between the device management server 06, the data acquisition and detection server 05, the auxiliary equipment management server 04, and the control server 01, serving as the "communication hub" of the entire system. It achieves efficient and reliable information transmission through: decoupled communication: allowing servers to transmit information via "message topics" without needing to know each other's addresses or status. For example, if a detection server detects a device malfunction, it only needs to send a message to the "device malfunction" topic, which the control server will automatically receive upon subscription. Asynchronous buffering: when a server is busy, such as when the medication management server is processing a large number of inventory queries, the message management server temporarily stores messages to prevent the sender from waiting or message loss. Peak shaving and valley filling: for example, during peak periods when orders surge, the message management server queues requests in order to prevent the control server from being overwhelmed instantly. Reliability assurance: supporting message retry and persistence, ensuring messages are not lost after unexpected power outages, and guaranteeing that critical instructions, such as medication dispensing, are not missed.

[0044] In summary, the various servers described above achieve business isolation through "division of labor," making the system easier to maintain and expand. In particular, the message management server, acting as a "communication intermediary," achieves collaborative decoupling, enabling distributed servers to collaborate efficiently while preventing a failure in one part from affecting the entire system. The combination of these two aspects ultimately achieves a system that is "highly available, highly elastic, and easily iterative."

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

[0046] RFID readers are used to read information from RFID tags attached to medicines using radio frequency identification technology.

[0047] Image recognition detectors are used to photograph medicines using a camera and combine image algorithms to detect the shape, color, and size of the medicines to determine whether they match the dosage and specifications required by the prescription.

[0048] A weight detection device is used to detect the weight of solid medicines to help determine whether the dosage is accurate.

[0049] Temperature and humidity sensors are used to monitor the temperature and humidity of the environment in which medicines are stored and distributed, ensuring that medicines are stored under suitable conditions and avoiding the impact of environmental problems on their efficacy.

[0050] Facial recognition / fingerprint recognition devices are used to verify the identity of pharmacists or patients when they pick up medications, ensuring that medications are dispensed to the correct recipients and in accordance with operating procedures.

[0051] Operational behavior monitoring cameras are used for video surveillance, behavior analysis, and to detect whether the drug dispensing process complies with standard procedures, ensuring operational compliance.

[0052] In some embodiments, the medication management server uses machine learning algorithms to optimize inventory and order processing, inventory forecasting and dynamic replenishment, and uses time series models to predict the demand for medicines in future time periods based on historical order data, and pushes replenishment suggestions to the control server in advance.

[0053] In this embodiment, the medication 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 detailed below:

[0054] I. Data preparation and preprocessing.

[0055] Core data types: historical order data (including drug ID, order quantity, order time, delivery area, etc.); inventory data (current inventory level, inventory warning line, storage cost, expiration time, etc.); external influencing factors (such as seasonal changes, special events such as the epidemic, demand fluctuations during holidays, supplier replenishment cycle, etc.).

[0056] Preprocessing operations: data cleaning (removing outliers, such as erroneous order volumes; filling in missing values, such as using the mean or data from adjacent time periods); time series formatting (organizing data according to fixed time granularity, such as summarizing order volumes by day, week, and month); feature engineering (extracting time features, such as month and day of the week; constructing derived features, such as "order growth rate over 3 consecutive days").

[0057] II. Time Series Model Construction and Training.

[0058] Choose an appropriate time series model and train its predictive capabilities based on historical data:

[0059] Model selection: Basic models: such as ARIMA (suitable for linear trend data), exponential smoothing (suitable for data with seasonal fluctuations);

[0060] Machine learning models, such as random forests and gradient boosting trees (which can handle non-linear relationships and incorporate external influencing factors);

[0061] Deep learning models, such as LSTM (Long Short-Term Memory Network, suitable for processing long-term, complex trend time series data).

[0062] Training and optimization: Divide the dataset (use the first 80% of historical data as the training set and the last 20% as the validation set); Model training (adjust parameters using the validation set, such as the number of hidden layer nodes in LSTM and the lag order in ARIMA); Evaluation metrics (use MAE (mean absolute error), RMSE (root mean square error), etc. to judge prediction accuracy and ensure model reliability).

[0063] III. Demand Forecasting and Replenishment Decisions.

[0064] The trained model generates predictions and translates them into replenishment recommendations:

[0065] Demand Forecasting: Input a future time period (e.g., the next 7 days or 30 days), and the model outputs the predicted demand for each drug; combined with inventory data, calculate "predicted demand - current inventory" to obtain the theoretical replenishment gap.

[0066] Optimize replenishment recommendations: Consider constraints such as supplier minimum order quantity, transportation costs (bulk replenishment is more cost-effective), and inventory limits (to avoid stockpiling and expiration); use machine learning algorithms (such as linear programming and reinforcement learning) to optimize replenishment quantities, balance "stockout risk" and "inventory costs", and generate final replenishment recommendations (including medicine, replenishment quantity, and recommended replenishment time).

[0067] IV. System Integration and Push Execution.

[0068] Linking the model with servers and control systems enables automated processes:

[0069] Server deployment: The model is encapsulated as an API interface and deployed to the medication management server. The model is automatically invoked periodically (e.g., daily) to generate predictions and replenishment suggestions based on the latest data.

[0070] Push and Execution: The medication management server pushes replenishment suggestions to the control server; after receiving the suggestions, the control server can automatically generate a purchase order (or prompt for manual review), triggering the replenishment process.

[0071] Circular Feedback: After replenishment, actual inventory and new order data are transmitted back to the control server in real time for continuous model iteration and optimization (e.g., retraining the model weekly to improve prediction accuracy). Through these steps, the entire process from historical data to accurate replenishment recommendations can be automated, reducing stockouts or backlogs and improving the efficiency of drug dispensing management. Intelligent order priority ranking, combining user information, drug characteristics, and equipment load, uses a reinforcement learning model to dynamically prioritize orders, sending high-priority orders first to the control server. This allows the control server to then prioritize the allocation of high-priority orders to the equipment management server, improving the response speed for urgent orders.

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

[0073] The reinforcement learning model enables dynamic order sorting (sending high-priority orders first). The core principle is that the model learns "how to sort" orders to maximize overall goals (such as reducing delays in high-priority orders and improving customer satisfaction). The specific implementation steps are as follows:

[0074] I. Defining the problem and core elements.

[0075] Clearly define the objectives of the sorting and the key characteristics of the orders to provide a basis for the model's decision-making.

[0076] Objective function (reward function): the "learning direction" of the model. For example: when high-priority orders are processed first, a positive reward is given (the higher the priority, the greater the reward weight); when high-priority orders are delayed (such as not being sent after the expected time limit), a negative penalty is given; avoid excessive backlog of low-priority orders (a basic penalty can be set to prevent extreme cases).

[0077] Order status features: These describe key information about the order and serve as input for model decision-making. For example:

[0078] Priority tags (e.g., levels 1-5, with level 1 being the highest); order creation time (affecting delivery time); delivery address (e.g., whether it's remote, affecting processing difficulty); medication type (e.g., whether it's emergency medication, indirectly affecting priority). Action space: the operations the model can perform, i.e., "choosing which of the currently pending orders to send first".

[0079] Model training and iteration. The model is trained using simulated or real-world data to learn to prioritize high-priority orders. Training data sources include historical order data, which are used as initial training samples to simulate the results of different sorting strategies.

[0080] Simulation environment: Build a virtual scenario and randomly generate order flows with different priorities and characteristics to allow the model to test and fail in the simulation. For example, sending low-priority orders will be penalized, so the strategy can be adjusted.

[0081] The training process is as follows: During model initialization, orders are randomly selected for delivery, and feedback is obtained based on the reward function;

[0082] The strategy is updated using reinforcement learning algorithms;

[0083] Repeat the iteration until the model stably learns the strategy of "prioritizing high-priority orders" (e.g., in more than 90% of scenarios, high-priority orders are ranked in the top 50%).

[0084] In some embodiments, the device management server is used to perform fault prediction on the device using machine learning algorithms.

[0085] Collect equipment data, use anomaly detection algorithms to learn the normal operating mode of the equipment, identify abnormal states in real time, predict failure risks in advance, and send maintenance instructions to the control server.

[0086] In this embodiment, the anomaly detection algorithm learns the normal operating pattern of the device, identifies abnormal states that deviate from the normal state, and predicts the risk of failure. The specific implementation can be divided into the following steps:

[0087] I. Data Acquisition and Preprocessing.

[0088] First, key data on device operation is acquired to provide the model with a basis for learning "normal mode":

[0089] Data types: Sensor data, such as physical quantities like temperature, pressure, vibration frequency, current, and voltage;

[0090] Device logs, such as operating status codes, operation records, error messages, etc.;

[0091] Time-series data, continuous data recorded by timestamps, reflects changes in equipment status over time.

[0092] Preprocessing: Data cleaning: removing missing values ​​and noise (e.g., eliminating sensor fluctuations through smoothing).

[0093] Feature extraction: Extract key features (such as average temperature, vibration peak value, frequency of status code occurrence, etc.) from the raw data to reduce dimensionality;

[0094] Data set division: use historical normal operation data as "normal samples" and a small amount of known fault data (if any) as "abnormal samples" to assist in verification.

[0095] II. The "Normal Mode" of the learning device.

[0096] By modeling anomaly detection algorithms, we define the characteristic distribution or patterns of equipment during normal operation.

[0097] Anomaly detection algorithms can be implemented using the following algorithms:

[0098] The Isolation Forest algorithm constructs "isolation trees" for normal samples. Normal data has long isolation paths due to its concentrated features, while abnormal data has special features and is easily isolated quickly (short paths), thus distinguishing between normal and abnormal data.

[0099] The autoencoder algorithm uses a neural network to learn the feature compression and reconstruction capabilities of normal samples. Normal data has a small reconstruction error, while abnormal data has a large reconstruction error because it deviates from the normal pattern.

[0100] Clustering algorithms cluster normal samples to form dense "normal clusters," while abnormal data is identified as abnormal because it cannot be assigned to any cluster or is located in a sparse region.

[0101] III. Anomaly Identification and Fault Risk Prediction. Based on the learned normal patterns, risks are monitored and assessed in real time:

[0102] Anomaly detection: Collect device data in real time, extract features and input them into the model, and identify abnormal states by judging thresholds (such as autoencoder reconstruction error exceeding a set threshold, or isolated forest path length being lower than a threshold).

[0103] Fault risk prediction: Combining time series characteristics, analyze the duration, frequency, and severity of anomalies (such as the rate of temperature rise), and use trend prediction models (such as LSTM) to assess the probability and time window of fault occurrence.

[0104] Associate different types of anomalies (such as vibration anomalies and current anomalies) with known fault cases, establish an "anomaly-fault" mapping relationship (such as vibration frequency anomalies often lead to bearing wear), and output specific fault risk types (such as "high bearing fault risk").

[0105] IV. Model Optimization and Iteration. Update the model with newly generated fault data (abnormal samples) to avoid deviations from the "normal mode" caused by equipment aging and changes in operating conditions.

[0106] Dynamically adjust thresholds (e.g., optimize anomaly judgment thresholds based on actual fault occurrences through feedback mechanisms) to improve recognition accuracy.

[0107] For example, in the motor fault detection of the drive motor of the conveyor belt for dispensing medicine, the autoencoder is first trained 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 moment, the model will identify it as an anomaly, and combine it with the pattern of "bearing failure occurring within 2 hours after vibration anomaly" in historical data to predict the risk of bearing failure.

[0108] In some embodiments, the device management server is also used to optimize the accuracy of dispensing actions. For positional deviations that occur when the robotic arm picks up medicine, a supervised learning model is used to correct the action parameters in real time, thereby reducing medicine picking errors and improving dispensing efficiency.

[0109] In this embodiment, taking the correction of the positional deviation of the robotic arm in picking up medicine as an example, the specific implementation steps of using a supervised learning model to optimize the motion parameters in real time are as follows:

[0110] Data collection and annotation: Constructing a "bias-correction" sample library.

[0111] Data collection: Enabling the robotic arm to record key information during routine medication dispensing:

[0112] Input features: the coordinates of the location of the medicine (such as the X / Y / Z axis coordinates of the medicine shelf), the dimensions of the medicine packaging box (length / width / height), the current joint angle of the robotic arm, and the status of the gripping tool (such as suction cup / gripper) (air pressure / tightness).

[0113] Real-time image features captured by a vision sensor (camera) (such as the pixel position of the drug in the image and its relative offset from the end of the robotic arm).

[0114] Output labels: When the robotic arm deviates from its position (such as not aligning with the center of the medicine box, or causing it to fall due to gripping deviation), the "corrected motion parameters" are recorded manually or automatically. For example, the joint angle needs to be finely adjusted by +2°, the Z-axis height is reduced by 1cm, and the suction cup air pressure is increased by 0.2bar. These correction parameters are the "correct output" that the model needs to learn.

[0115] Data expansion: Simulate different scenarios (such as slight displacement of the medicine box or visual recognition errors caused by changes in lighting) to generate more samples and ensure that the model covers common deviation situations.

[0116] Model selection and training: learning the "bias-correction" mapping relationship.

[0117] Choose a regression-based supervised learning model (because the goal is to predict continuous action correction parameters), for example:

[0118] Random Forest Regression: Handles multi-feature inputs (coordinates, angles, image features, etc.) and learns the non-linear relationship between features and correction parameters;

[0119] Neural networks (such as MLPs) fit complex mappings through multiple layers of neurons, and are especially suitable for fusing visual image features (image features need to be extracted first through CNNs).

[0120] Training process: The model is trained using labeled "input features - correction parameters" samples. The goal is to enable the model to output accurate correction parameters (e.g., the robot arm's X-axis fine adjustment +3mm) based on the current deviation features (e.g., visual recognition of the medicine box being offset by 3mm on the X-axis).

[0121] Real-time correction: integrated into the robotic arm control system.

[0122] Real-time data acquisition and prediction: Before the robotic arm picks up the medicine, the vision sensor captures the position of the medicine and simultaneously acquires features such as the current joint angle and the size of the medicine box, which are then input into the trained model; the model outputs correction parameters in real time (such as adjusting the X / Y / Z coordinates and joint angles of the robotic arm end).

[0123] Execution and feedback: The robotic arm adjusts its movements according to the calibration parameters. After completing the grasping, it provides feedback through sensors (such as pressure sensors to determine whether the grasp is stable). If there is still a deviation, the new "deviation feature - actual calibration parameters" are added to the sample library, and the model is retrained periodically to improve accuracy.

[0124] For example, when a robotic arm grasps a square medicine box, the vision sensor detects that the actual position of the medicine box is 2mm to the right compared to the system's preset position. Based on features such as "medicine box size + offset + current joint angle", the model outputs correction parameters such as "X-axis shifted 2mm to the right, gripper opening angle increased by 5%". After the robotic arm adjusts, it grasps the medicine box accurately, reducing the chance of the medicine box falling or grasping errors caused by positional deviation.

[0125] In some embodiments, the control server is used to analyze the real-time load of each drug dispensing device using a clustering algorithm, and dynamically allocate tasks in conjunction with order volume prediction to avoid overload and lag of the drug dispensing devices, thereby improving the overall system throughput.

[0126] In this embodiment, taking the task allocation of drug dispensing equipment (such as automatic dispensing machines, conveyor belt systems, etc.) as an example, the specific steps for achieving dynamic load balancing by combining clustering algorithms and order volume prediction are as follows:

[0127] 1. Real-time load data acquisition and feature definition.

[0128] Data collection of device load characteristics: For each distribution device, core indicators reflecting the load are collected in real time.

[0129] The number of orders currently being processed and the backlog of unfulfilled orders;

[0130] Equipment operating speed (e.g., the amount of medicine dispensed per minute by the dispensing machine, the number of medicines transported per second by the conveyor belt);

[0131] Resource utilization rate (such as motor load rate, control system CPU utilization rate);

[0132] Historical processing time (average processing time per order in the last 10 minutes).

[0133] Feature standardization: Scaling different metrics (such as order volume and load rate) to the same magnitude (such as the range of 0-1) to avoid a single feature having too much impact on the clustering results.

[0134] 2. Use clustering algorithms to classify equipment load levels.

[0135] The devices are grouped according to their real-time load status using clustering algorithms (such as K-means) to identify "lightly loaded," "normal," and "heavily loaded" devices:

[0136] Clustering process: Using the real-time load characteristics of the equipment (order backlog, running speed, load rate, etc.) as input, set the number of clusters (e.g., 3 categories: light load, normal, heavy load).

[0137] The algorithm automatically groups devices with similar features into one category, for example:

[0138] Light-load equipment: order backlog < 5 orders, load rate < 30%, average processing time < 5 seconds;

[0139] Heavy-duty equipment: order backlog > 20 orders, load rate > 80%, average processing time > 15 seconds.

[0140] Dynamically update clustering results: recalculate clusters every 30 seconds (due to real-time changes in device load) to ensure accurate load level classification.

[0141] 3. Dynamically allocate tasks based on order volume forecasts.

[0142] Order volume prediction: Using time series models (such as ARIMA, LSTM) based on historical order data (such as the daily peak order period of 9:00-10:00), predict the order volume and drug type distribution for the next 10-30 minutes.

[0143] Dynamic allocation rules: Based on clustering results (equipment load levels) and order forecasts, an allocation strategy is formulated.

[0144] New orders should be prioritized for allocation to "lightly loaded" equipment (such as dispensing machines with low backlog and fast processing speed).

[0145] For "heavy load" equipment, suspend the allocation of new orders until its backlog drops to the "normal" level;

[0146] If a surge in orders for a certain type of medicine is predicted (e.g., a high volume of cold medicine orders at a certain time), the relevant orders should be diverted in advance to equipment that is highly efficient in processing that type of medicine (even if the current load is slightly high, to avoid concentrated overload later).

[0147] In an example scenario, a pharmacy has 5 automated dispensing machines. After clustering, it is found that machines A and B are "lightly loaded" (3 backlogged orders, 25% load); machines C and D are "normal" (10 backlogged orders, 50% load); and machine E is "heavily loaded" (25 backlogged orders, 90% load, already experiencing lag). If the system predicts 20 new orders (mainly oral medications) in the next 15 minutes, then: new orders will be prioritized for A and B; machine E will pause accepting orders and only process existing ones; if A and B are more efficient at processing oral medications, even if C and D are at normal load, oral medication orders will still be preferentially assigned to A and B to avoid overloading C and D later. This approach allows for real-time monitoring of machine load through clustering and proactive order allocation based on order prediction, reducing lag or malfunctions caused by overload at the source.

[0148] In addition, it handles emergency orders. When the medication management server reports insufficient drug inventory or the equipment management server reports temporary equipment failure, it uses a decision tree model to automatically generate alternative solutions, providing a rapid response and reducing user waiting time.

[0149] In this embodiment, taking emergency handling of order anomalies as an example, the specific implementation steps of automatically generating alternative solutions using a decision tree model are as follows:

[0150] 1. Define abnormal scenarios and alternative solutions: clarify the decision-making rule framework.

[0151] First, we outlined common order anomaly types and feasible alternatives to serve as the "training basis" for the decision tree:

[0152] Anomaly type: Insufficient stock (e.g., only 2 boxes of medicine A remain in the order, but the user needs 5 boxes);

[0153] Temporary equipment malfunction (e.g., the robotic arm dispensing medicine B is stuck and cannot be operated);

[0154] Mixed anomalies (e.g., insufficient stock of drug C + malfunction of corresponding dispensing equipment).

[0155] Alternative Solution Library: When inventory is insufficient: recommend alternative drugs with the same ingredients (such as generic drugs of the same type as drug A), split orders (first find that there is inventory, and then restock the remaining part), and guide users to change the specifications (such as changing from 10 tablets to 20 tablets).

[0156] In case of equipment failure: switch to backup equipment (such as another dispensing machine for drug B), prioritize manual dispensing, and adjust the dispensing time (inform the user that the equipment will be repaired in 1 hour).

[0157] 2. Construct a decision tree model: learn exception handling rules.

[0158] Feature extraction: Transforming abnormal scenes into features that the model can recognize, for example:

[0159] Anomaly type (insufficient stock / equipment malfunction / mixed);

[0160] Drug attributes (whether it is a prescription drug / urgently needed drug / whether there are alternatives);

[0161] Order information (user priority, delivery time requirement, order amount);

[0162] Resource status (availability of backup equipment, current number of people queuing at manual counters, inventory of alternatives).

[0163] Decision tree training: Using historical processing cases (such as "insufficient inventory + prescription drugs + no substitutes → recommended to split orders") as training data, the decision tree learns the mapping relationship between features and the optimal solution.

[0164] Tree nodes: Decisions are based on key features (e.g., "Are there any alternatives?").

[0165] Leaf nodes: correspond to specific alternatives (such as "recommended alternative B").

[0166] 3. Real-time solution generation: integrated into the order processing system.

[0167] Real-time input of abnormal features: When the dispensing server reports an abnormality (such as "Drug D is out of stock, user is a VIP, delivery must be made within 2 hours"), the system automatically extracts features (abnormality type = out of stock, user priority = high, delivery time requirement = 2 hours, substitute D' is in stock).

[0168] Model output scheme: Decision tree traverses nodes based on features:

[0169] 1. "Are there any alternatives? → Yes";

[0170] 2. "Is the inventory of substitutes sufficient? → Yes";

[0171] 3. "Do users accept alternatives? → Historical data shows that VIP users have an acceptance rate of 90%";

[0172] The final output solution is: "Recommend alternative D' and notify the user via system message. After confirmation, it will be immediately issued from the backup device to ensure delivery within 2 hours."

[0173] Feedback optimization: Record user acceptance of the solution (e.g., whether they agree to the alternative) and processing results (e.g., whether it is delivered on time), and regularly prune or retrain the decision tree with new data to improve the rationality of the solution.

[0174] For example, if a user's order contains "ibuprofen tablets (insufficient stock)" and "corresponding dispensing equipment malfunctions," the decision tree, combined with the information that "ibuprofen is an over-the-counter drug + there are similar alternatives (acetaminophen) + the user has no special requirements," directly generates a solution: "Switch to the backup equipment to dispense acetaminophen, with an alternative explanation, no waiting required," quickly resolving the anomaly and reducing user waiting time.

[0175] In some embodiments, the control server is also used for dictionary maintenance, drug configuration, treatment task configuration, prescription management, prescription analysis, task review, task monitoring, task query, and task scheduling.

[0176] In task scheduling, the candidate device score is calculated using the following formula:

[0177] Score=w1 SPT+w2 EDD+w3 SetupCost+w4 LocationCost+w5 Reliabilit.

[0178] Where w1 is the weight of the shortest processing time;

[0179] SPT stands for minimum processing time;

[0180] w2 represents the weight for the earliest expiration date;

[0181] EDD is the earliest expiry date;

[0182] w3 represents the switching cost weight;

[0183] SetupCost is the switching cost;

[0184] w4 represents the location distance weight;

[0185] LocationCost is the distance to the location;

[0186] w5 is the reliability weight;

[0187] Reliabilit stands for reliability.

[0188] In this embodiment, the specific details of the scheduling algorithm are as follows:

[0189] 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.

[0190] Candidate device scoring formula:

[0191] Score=w1 SPT+w2 EDD+w3 SetupCost+w4 LocationCost+w5 Reliabilit.

[0192] Where w1 is the weight of the shortest processing time;

[0193] SPT stands for minimum processing time;

[0194] w2 represents the weight for the earliest expiration date;

[0195] EDD is the earliest expiry date;

[0196] w3 represents the switching cost weight;

[0197] SetupCost is the switching cost;

[0198] w4 represents the location distance weight;

[0199] LocationCost is the distance to the location;

[0200] w5 is the reliability weight;

[0201] Reliability;

[0202] The weights can be adjusted in the parameter table.

[0203] 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:

[0204] 1. First, clarify three premises: the weights of the five factors, the factor scoring rules, and the candidate devices.

[0205] Weighting of 5 factors (total weight 100%, allocated according to emergency priority):

[0206] Shortest processing time weight: 30% (0.3);

[0207] Earliest expiry date weight: 15% (0.15);

[0208] Switching cost weight: 15% (0.15);

[0209] Location distance weight: 10% (0.1);

[0210] Reliability weight: 30% (0.3);

[0211] Factor scoring rules (unified positive: the better the performance, the higher the score, with a maximum score of 10):

[0212] Minimum processing time: 1 hour (fast) → 10 minutes, 2 hours → 8 minutes, 3 hours → 6 minutes;

[0213] Earliest expiration date: Remaining maintenance time 7 days (long) → 10 minutes, 5 days → 8 minutes, 3 days → 6 minutes;

[0214] Switching costs: 50 yuan (low) → 10 points, 80 yuan → 8 points, 110 yuan → 6 points;

[0215] Location distance: 100 meters (near) → 10 minutes, 200 meters → 8 minutes, 300 meters → 6 minutes;

[0216] Reliability: Failure rate 1% (low) → 10 points, 3% → 8 points, 5% → 6 points;

[0217] Candidate equipment: 3 units in total (decocting machine A, B, and C), and their respective performance factors are as follows:

[0218] 2. Calculate the overall score for the three devices:

[0219] The comprehensive scoring formula is: (processing time score × 0.3) + (due date score × 0.15) + (switching cost score × 0.15) + (distance score × 0.1) + (reliability score × 0.3).

[0220] (1) Decoction machine A (best performance);

[0221] Scores for each factor: 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);

[0222] Overall 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.

[0223] (2) Decoction machine B (medium performance);

[0224] Scores for each factor: 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);

[0225] Overall 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.

[0226] (3) Decoction machine C (performed poorly);

[0227] 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);

[0228] 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.

[0229] 3. Scheduling conclusions.

[0230] 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".

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

[0232] 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.

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

[0234] 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.

[0235] 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.

[0236] 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.

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

[0238] 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.

[0239] In this embodiment, the control server may be equipped with a prescription management module to implement the above-mentioned prescription management function.

[0240] Prescription analysis supports comprehensive analysis based on factors such as dictionary configuration, prescription / medical order requirements, and task queue status of each smart device. It breaks down prescriptions / medical orders into multiple dispensing tasks and delivers task instructions to each smart device at the optimal time.

[0241] In this embodiment, the control server may be equipped with a prescription analysis module to implement the above-mentioned prescription analysis function.

[0242] Task review supports reviewing automatically analyzed and split reassignment tasks, allows manual intervention to adjust task attributes, and supports modifying information such as assigned equipment and start time. It also supports automatic system approval and task distribution.

[0243] In this embodiment, the control server may be equipped with a task review module to implement the above-mentioned task review function.

[0244] Task monitoring supports the monitoring and inspection of ongoing dispensing and decoction tasks, including the operation of existing equipment, task queues, and drug inventory status. During task monitoring, a fault tolerance mechanism is provided for certain anomalies, allowing the platform to dynamically adjust and allocate tasks; in the event of major anomalies, manual intervention is supported.

[0245] In this embodiment, the control server may be equipped with a task monitoring module to implement the above-mentioned task monitoring function.

[0246] Task query allows you to view and search for dispensing tasks that have been analyzed and broken down. You can also view their source and details, including the task source, the prescriptions and drugs included, the estimated time to take, the pre-assigned equipment, the task start time, and the estimated completion time.

[0247] In this embodiment, the control server may be equipped with a task query module to implement the above-mentioned task query function.

[0248] In some embodiments, the functions implemented by the control server are shown in Table 1:

[0249] Table 1. Functional Statistics of the Control Server

[0250]

[0251] The specific details of the prescription analysis are as follows:

[0252] Knowledge base modeling: Rule modeling is performed using a pharmaceutical knowledge base, defining classification rules according to drug category (whole box, individual, all categories, ready-to-use granules / processed slices of traditional Chinese medicine, etc.) and treatment type (outpatient, inpatient, ward, internet hospital). In implementation, the rules are stored in a maintainable knowledge base, supporting dynamic configuration and updates by pharmacists and IT staff.

[0253] Order merging strategy: Prescriptions for the same patient and charged at the same time are automatically merged during the task generation stage to ensure consistency in prescription execution. This logic is built into the task generation engine and is implemented by aggregating and judging the billing serial number and patient ID.

[0254] Process allocation: Based on drug attributes (whether decoction needs to be prepared by a third party, whether manual processing is required, whether decoction should be prepared before adding, etc.), the rule engine automatically assigns the drug to different dispensing processes. This process configuration is parameterizable and supports later maintenance.

[0255] Anomaly Detection and Manual Intervention: When an anomaly is detected in RFID, PDA, or device status, the prescription is marked as an "abnormal prescription." Abnormal prescriptions are then processed manually, where some known information is automatically filled in, and manual additions or modifications can be made. Deletion of abnormal prescriptions requires confirmation from both the person handling the issue and the reviewer, and the deletion is recorded in the audit log.

[0256] Manual processing: Provides manual entry and supplementation functions for prescriptions, allowing pharmacists to manually fill in information such as prescriptions, medications, dosages, and target windows. The interface supports dictionary access, reducing the error rate of manual input.

[0257] Prescription information interaction: After HIS payment, the master prescription table and detailed prescription table are pushed to the central control system via a view / intermediate table. The central control system reads the data via a scheduled task 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.

[0258] Prescription Master Table Field Management: Comprehensive analysis of prescription master table and detail table fields provided by HIS, including patient information, diagnosis, drug attributes, usage frequency, cost, etc., to ensure seamless integration with HIS.

[0259] Prescription details table field management: drug number, drug name, specifications, manufacturer, packaging, quantity, dosage, unit, usage, frequency, supplementary usage, remarks, etc.

[0260] Window allocation and prescription merging: The system returns the pharmacy window number via a WebService interface, prints it on the invoice, and simultaneously locks the inventory. For multiple prescriptions for the same patient, the system automatically merges them before execution, reducing redundant operations.

[0261] The specific details of task planning management are as follows:

[0262] Equipment selection: The scheduling engine obtains parameters such as equipment operating status (idle, working, faulty), compatible drug categories, queue length, and estimated processing time from the equipment dictionary in real time. By calling rules from the expert decision base, the candidate equipment set is constrained and filtered, and then heuristic optimization algorithms (such as SPT and EDD) are used to sort them, finally generating the optimal equipment allocation scheme.

[0263] Time constraints: When generating task plans, the window and ward mapping tables provided by HIS are read synchronously. The scheduling engine compares parameters such as patient check-in time, prescription commitment time, and ward centralized delivery period, and automatically adjusts the task execution order to ensure that tasks are completed according to the time window requirements.

[0264] Objective function: The scheduling module has a built-in multi-objective optimization function that uses Makespan, waiting time, and cross-regional transportation cost as variables, combined with configurable weights for calculation. The optimization result is returned by the algorithm module and written to the database as a reference result for task allocation.

[0265] Dynamic recalculation: When events such as equipment failure, refund, or order insertion are detected, the system event bus notifies the scheduling engine. The engine automatically recalculates available resources and priorities, updates the task queue based on the remaining tasks, and issues new scheduling instructions in real time.

[0266] ETA Prediction: Periodically collect device processing rate and queue length, 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.

[0267] Priority strategy: A priority field is maintained in the task table. Emergency and critical care tasks are automatically assigned high priority and will be inserted at the head of the queue first during scheduling algorithm execution. During peak periods, the system supports batch plan generation, calling batch processing programs to quickly output large-scale scheduling schemes.

[0268] The specific content of the task review is as follows:

[0269] Automatic review: After a task is generated, a rules engine is invoked for verification. The rules are stored in a database parameter table and cover conditions such as drug compatibility, inventory availability, and equipment status. When the verification results meet all conditions, the task is automatically marked as "reviewed" and immediately issued.

[0270] Manual intervention: For tasks that fail verification, a pop-up message appears on the review interface, displaying the unmet rule items. Reviewers can adjust device selection, modify priority, or re-specify the execution node through the interface. After the adjustment is completed, the system calls the rule engine again to perform a second verification. Only after the verification passes can the task be issued.

[0271] Dual-person review: For critical operations such as refunds and abnormal deletions, dual-person workflow control is implemented. The workflow engine mandates that two individuals with different roles log in and confirm, generating dual signature records for both the handler and the reviewer in the database to ensure operational compliance.

[0272] Anomaly Handling: For tasks entering an abnormal state, a dedicated manual processing interface is provided. The interface automatically populates existing data (such as patients, prescriptions, and medications), and users can manually enter or modify missing fields. After submission, the task will be rewritten to the task table, triggering a re-review by the rules engine.

[0273] Logs and Traceability: All audit, intervention, and review operations are written to the audit log repository. The logs are stored immutably (WORM storage or blockchain-based signatures). The log content includes the operator, timestamp, and operation details, and supports export and later querying.

[0274] The specific details of task query and tracing are as follows:

[0275] Multi-condition filtering: The database includes task tables, prescription tables, and device execution tables, all with indexed fields (such as prescription number, patient ID, device ID, and timestamp), supporting multi-condition combined queries. The query engine employs dynamic SQL concatenation and caching optimization to ensure fast result return even with large amounts of data.

[0276] Prescription and Dispensing Information Details: The front-end query interface calls views from the main prescription table and detailed prescription table to display fields such as patient basic information, drug number, specifications, quantity, and usage. Dispensing information is obtained in real time through the device feedback interface, displaying inventory, location, and expiration date.

[0277] Task execution details: The execution process of each task is stored in the execution log table, containing end-to-end data from "generation—assignment—distribution—execution—completion". The front-end can call the REST API to query the execution trajectory, which is displayed in a timeline format.

[0278] Anomaly and Manual Intervention Logs: When situations such as drug shortages, equipment congestion, or network interruptions occur during task execution, the task status will be automatically marked and manual intervention will be initiated. During manual processing, prescriptions, drugs, quantities, or target windows can be modified. All intervention information will be recorded, supporting post-event auditing and traceability. Anomalies will be written to an anomaly table, recording the cause of the anomaly (drug shortage, equipment failure, network interruption), and linked to the manual processing log. Manual modification operations will be written to a separate audit table, saving the values ​​before and after the modification, supporting later traceability.

[0279] Track Replay: Supports visual replay of task execution trajectories, displaying task allocation paths, equipment processing progress, and manual intervention nodes. For ward medication dispensing tasks, the delivery path (track / AGV travel route) can also be replayed to facilitate analysis of delay causes. The task flow process is stored as an event sequence, with each event having a timestamp and operation node. When called by the front end, the trajectory map can be dynamically rendered or animations can be played to intuitively recreate the task execution process. For ward medication dispensing, AGV / track operation logs are also loaded to draw the delivery path.

[0280] Historical Task Tracking: All task data is stored long-term (at least 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 partitioned tables, using a hot and cold data separation approach. Queries on data from the past three months are routed through the online database, while data older than three 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.

[0281] The specific details of the equipment and drug configuration are as follows:

[0282] Manual Configuration: Pharmacists can manually set the mapping between medications and dispensing equipment, storage locations, and batches to ensure accurate dispensing of special medications. The system provides a configuration management interface, allowing pharmacists to manually establish mapping relationships between medications and equipment, storage locations, and batches. Configuration operations are validated via form to avoid duplicate bindings or conflicts.

[0283] Automatic device reporting: The system supports automatically retrieving drug information from devices, including batch number, expiration date, and inventory quantity, and synchronizing it to the central control system. Devices periodically report inventory, batch number, and expiration date via an interface. After receiving the data, the central control system writes it into the device-drug relationship table and verifies it against the drug dictionary to ensure data consistency.

[0284] Priority and Disallowance Rules: The system supports setting drug allocation priorities, disallowed devices, and alternative strategies to ensure reasonable scheduling. The system adds "Priority" and "Disallowance" fields to the configuration table. The scheduling engine reads these parameters when allocating tasks, prioritizing high-priority devices and skipping disallowed devices.

[0285] Configuration Validation and Logging: Automatically checks for configuration conflicts and logs all configuration changes. When a configuration is committed, a trigger detects conflicts (e.g., the same medicine being bound to different storage locations). All changes are automatically logged, including the operator, time, old value, and new value, and stored in an audit table.

[0286] The specific details of the task allocation rules are as follows:

[0287] 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.

[0288] 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.

[0289] 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.

[0290] 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.

[0291] 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.

[0292] 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.

[0293] 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).

[0294] 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.

[0295] Other systems call the scheme transmission function in the external interface, which saves the scheme into memory to temporarily store the scheme data for later use. After that, other systems call the real-time status transmission function in the external interface to send the real-time status to the external interface.

[0296] II. Dynamic Management of Decision-Making Tasks.

[0297] Through multiple "selection" branches, based on different states and task lists, decision tasks can be added, deleted, or updated over time:

[0298] 1. Branch 1: Add a decision task.

[0299] If the system is in rule-based reasoning mode and there is no corresponding decision task in the task list, a decision task will be added and a time will be set according to the status, thus adding a task to be processed for subsequent rule-based task scheduling decisions.

[0300] 2. Branch 2: Delete the decision task.

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

[0302] 3. Branch 3: Update the remaining time for the decision task.

[0303] In the case of "rule-based reasoning mode and the current scheme number is inconsistent with the previous one", "update the remaining time of the decision task according to the current cycle" to ensure that the task time parameters match the latest scheme.

[0304] III. Verification and activation of rules and configurations.

[0305] The communication thread performs "rule syntax checks," "rule semantic checks," and "scheme checks" to verify the legality and rationality of the rules and schemes, ensuring that subsequent rule-based decisions and scheme executions are correct. After successful verification, it "calls database operation functions to save the configuration to the database," persistently storing the relevant configurations; then, it "successfully configures" and "pushes the status," transmitting the configuration completion status information to inform other modules or the system that the configuration has taken effect.

[0306] IV. Data transmission and memory storage completion.

[0307] Other systems call the data transfer function in the external interface. After the external interface receives and executes the call, it saves the relevant data into memory. This data temporary storage after completing this series of operations provides data support for subsequent processes.

[0308] Overall, this part of the process involves dynamically adjusting decision-making tasks based on changes in system mode, task status, and solutions during task scheduling, while ensuring the correctness and effectiveness of rules and configurations. It is a key link in the task scheduling process from "task monitoring" to "decision execution" and then to "configuration activation".

[0309] This process enables automated management of tasks from monitoring to decision-making to execution feedback (plan distribution and data storage). It allows for timely scheduling and arrangement of tasks, ensuring that tasks are executed as expected, and that relevant data is properly stored for subsequent querying, analysis, or further operations by other systems based on this data. The monitoring of the "communication thread" also prepares for possible subsequent communication interactions.

[0310] The specific contents of the device dictionary are as follows:

[0311] Basic Information Management: The system maintains basic information for all devices, including category, device name, device ID, brand / supplier, purchase date, and fixed asset code. When a device is connected, the system automatically writes in basic information such as device ID, model, supplier, and purchase date, and supports manual addition of the fixed asset code.

[0312] Operational and Capability Parameters: The processing capacity, compatibility range, limitations, and interface parameters of each device are all included in the dictionary management. Information such as the throughput, compatible drug types, and interface protocols of each device are reported periodically through the interface and written into the device dictionary table for use by the scheduling engine.

[0313] Lifecycle Management: Supports equipment status maintenance, updates, and decommissioning, ensuring complete equipment information. The system maintains the entire lifecycle status of equipment from "activation—operation—deactivation—decommissioning," and supports regular maintenance reminders and status switching.

[0314] The specific contents of the diagnostic and treatment dictionary are as follows:

[0315] Treatment type maintenance: Supports creating dictionaries by type such as outpatient, inpatient, ward, and internet hospital, and defining medication dispensing process templates. Administrators can create treatment types such as outpatient, inpatient, ward, and internet hospital within the system and bind medication dispensing process templates to them.

[0316] Window-to-ward mapping: This maps treatment types to medication dispensing windows and ward delivery routes, ensuring accurate task allocation. The window-to-ward mapping information provided by the HIS is automatically synchronized via an interface and written into the treatment dictionary table, which is then directly invoked when a task is generated.

[0317] Flexible expansion: Treatment types and processes can be added or adjusted according to changes in hospital operations. When adding a new treatment scenario, administrators can add dictionary items on the interface and import the corresponding processes, which will take effect immediately in the system.

[0318] The specific details of access control are as follows:

[0319] Role-Based Access Control (RBAC) Model: Permissions are assigned based on organizational roles (pharmacy, service window, ward, equipment maintenance, IT department, etc.). Users are bound to roles, and roles are bound to permissions. Permission granularity can be refined to "functional modules" and "data scopes." Functional and data-level access control is supported; administrators can authorize permissions by scope, such as service window, ward, or equipment.

[0320] Auditing mechanism: All authorized operations are automatically recorded through the logging module, and the logs are stored in the audit database, which supports retrieval and export.

[0321] Security mechanism: The system supports OAuth2 single sign-on, password complexity rules are configurable, and two-factor authentication can be enabled when necessary.

[0322] The specific details of the system parameter settings are as follows:

[0323] Global parameters: Task timeout thresholds, batch strategies, ETA calibration, window mapping, message push, etc., can be flexibly configured. The system provides a parameter management interface, allowing administrators to adjust task timeout thresholds, batch strategies, window mapping rules, etc. Parameter modifications are instantly synchronized to the scheduling engine cache.

[0324] Scheduling Weights: The weight parameters in the scheduling algorithm can be adjusted online, supporting canary deployments and rollbacks. The scheduling algorithm weights (processing time, waiting time, transit costs, etc.) are stored in a parameter table and can be adjusted online. After modification, the system automatically triggers a canary deployment test; once verified, it is rolled out globally.

[0325] Rule base versioning: Supports rule version management and comparison, ensuring changes are traceable. All rule and parameter changes are automatically generated with version numbers, supporting version comparison and rollback.

[0326] The specific details of the system data interface are as follows:

[0327] Interface Implementation Architecture: The system manages the interactions between the HIS, central control system, and devices uniformly through the interface gateway module. Interfaces support multiple methods, including WebService, HTTP(S)+XML / JSON, database views / stored procedures, and intermediate library message queues. The specific mode can be flexibly selected according to the hospital's existing network conditions. All interfaces are managed through configuration file parameters, enabling rapid expansion and maintenance.

[0328] Basic information interface: Data such as drug dictionary, storage location, department, dispensing window, and pharmacist information are obtained through views or intermediate tables provided by HIS; the central control system establishes a scheduled task and incremental synchronization mechanism, automatically detecting and updating information at fixed intervals (e.g., 30 seconds). To ensure consistency, the system verifies key fields (such as drug code and storage location ID) during writing, generating error logs and pushing alarms when conflicts occur.

[0329] In some embodiments, the system also includes a hot standby machine, which is used to switch to manual processing in case of server downtime, network failure, or other abnormal situations. It allows for local offline processing of received but not yet completed prescriptions, as well as prescriptions that have been dispensed (prepared) during a failure period. It supports synchronizing local data to the server after the failure is resolved, ensuring the consistency of business data.

[0330] For logistics order management, the system supports integration with the logistics system for prescriptions that need to be delivered to the home. For completed dispensing tasks, it supports automatic order placement to the logistics system, manual order replenishment, and order cancellation. It also supports querying historical logistics orders and viewing order details and tracking information.

[0331] In this embodiment, the control server may be equipped with a logistics order management module to implement the above-mentioned logistics order management function.

[0332] Equipment management and early warning systems support the generation of daily early warning reports after each work stoppage, based on pre-set equipment maintenance information, actual equipment operating conditions, and operation logs. These reports remind staff to inspect, repair, or replace equipment to ensure the continuous and normal operation of the production line. The system also supports adding critical fault maintenance lists and monitoring the operating status of each motor via current transformers for assessment and early warning. Furthermore, it supports calculating the required inventory levels for each intelligent dispensing device by statistically analyzing the consumption of various medicines at different times, converting this data into the required number of cells, and sending reports to remind equipment maintenance personnel to adjust the quantities of each medicine cell.

[0333] In this embodiment, the control server may be equipped with a device management and early warning module to implement the aforementioned device management and early warning functions.

[0334] In some embodiments, a hot standby machine is also included for switching to manual processing in the event of a control server or network failure, to process received but not yet completed prescriptions offline.

[0335] In some embodiments, the system also includes a large business screen connected to the control server. The large business screen is used to display the operation of the dispensing and medication dispensing business in the form of a floor plan and timed data refresh. It supports real-time statistics of business data and the generation of charts and graphs, and supports real-time querying of prescription details and detailed data of each prescription during the dispensing or decoction process.

[0336] In some embodiments, see Appendix Figure 3 and attached Figure 4 The control server is also equipped with a diagnosis and treatment management system, a central control management system, an equipment detection and early warning system, a medication management system, a case learning system, and an operation and maintenance management system.

[0337] The diagnosis and treatment management system is used for information management and scheduling throughout the entire diagnosis and treatment process.

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

[0339] The medication management system is used for the entire process management of medication dispensing.

[0340] The case learning system is used to accumulate historical case data.

[0341] The device detection and early warning system is used to receive data collected by the data acquisition and detection server from the detection device, and to determine whether the detection device needs to be replaced based on the collected data.

[0342] The operation and maintenance management system is used to update equipment data in real time after the testing device is replaced.

[0343] Within the control server, each of the aforementioned systems functions as a software module, working together to support the efficient operation of the medical process. Details are as follows:

[0344] The diagnosis and treatment management system (module) is used to focus on information management and scheduling throughout the entire patient diagnosis and treatment process. It integrates basic patient information (such as medical history, symptoms, and test results) to help doctors quickly understand the condition; it connects with consultation, examination, and diagnosis processes to record diagnosis and treatment decisions (such as prescription issuance and treatment plans); and it transmits key information to other modules (such as synchronizing prescription information to the medication management system to trigger the medication dispensing process).

[0345] The central control management system (module) is used as a "central scheduler" to coordinate the linkage between various system modules and hardware devices.

[0346] Real-time monitoring of the operational status of each module (such as the medication management system) and equipment (such as the robotic arm for dispensing medicines); allocation of resources and scheduling of tasks (such as directing the medication dispensing equipment to execute which order) based on preset rules or real-time data (such as equipment load and order priority);

[0347] Handle cross-module collaboration requirements (such as notifying the dispensing system to prepare when the diagnosis and treatment system submits a new prescription, and informing the queue generation module to sort the prescription).

[0348] The medication dispensing management system (module) is used for the entire process management of medication dispensing, ensuring accurate and efficient dispensing. It receives prescription information from the treatment system, verifies drug inventory and dosage rationality; sends dispensing requests to the central control system, driving equipment to perform operations such as medication retrieval, dispensing, and verification; records dispensing progress (e.g., "medication retrieved" "pending verification"), and reports any anomalies (e.g., insufficient inventory).

[0349] The case learning system (module) has the following core functions: assisting in model optimization and knowledge accumulation based on historical case data. It collects, de-identifies, and structures historical diagnosis, treatment, and medication data (such as successful cases and anomaly handling records); and provides training samples for various AI models on the control server, improving model accuracy.

[0350] Extract patterns from typical cases (such as the optimal processing flow for a certain type of order) and optimize system rules.

[0351] The device detection and early warning system is used to receive data collected by the data acquisition and detection server from the detection device, and to determine whether the detection device needs to be replaced based on the collected data.

[0352] In this embodiment, the data acquisition and detection server sends the collected data to the control server. The device detection and early warning system in the control server judges the data collected by the detection device based on the maximum and minimum values ​​of the detection device. For example, if the collected data is greater than a predetermined maximum value or less than a predetermined minimum value, the detection device is determined to be faulty and needs to be replaced.

[0353] The operation and maintenance management system is used to update equipment data in real time after the testing device is replaced.

[0354] The internet hospital system and the hospital integrated management system are connected to the control server. As external systems connecting to the control server, the internet hospital system and the hospital integrated management system each undertake different functions, working in conjunction with the modules within the control server to form a complete medical service system: the internet hospital system provides online medical services, bridging online and offline medical processes; the hospital integrated management system, as the "data hub" of various information systems within the hospital, enables cross-system data exchange and process integration.

[0355] In some embodiments, an intelligent management platform is constructed: the platform seamlessly integrates with hospital systems such as HIS (Hospital Information System), EMR (Electronic Medical Record), PIVAS (Pulse-Injection Configuration System), and intelligent traditional Chinese medicine decoction system, achieving millisecond-level synchronization of medical order data. At the device collaboration layer, a unified IoT protocol gateway is established, supporting the access of at least 10 types and 50 sets of devices (including injection dispensing machines, herbal medicine dispensing cabinets, automatic packaging machines, etc.). A dynamic task allocation engine based on deep reinforcement learning is developed, capable of generating optimal task scheduling schemes based on factors such as prescription drug composition, equipment load status, and logistics routes. Regarding security and backup, a hot standby offline processing mechanism is established; in the event of network and data interface failures, the system can operate independently until all received prescriptions / medical orders have been dispensed.

[0356] In some embodiments, the intelligent industrial control management system for the entire drug supply chain is a management system based on the Internet of Things and intelligent task scheduling algorithms. Through the collaborative operation of intelligent equipment and management software, it achieves digital and standardized management of the entire process of drug dispensing, decoction preparation, and administration throughout the hospital. The core of the system consists of various fully automated devices and a management platform: different types of drugs, such as tablets, injections, herbal decoctions, and decoction preparations, are dispensed (or prepared) by different types of equipment and then collected at windows or self-service dispensing machines via conveyor belts; the management platform obtains prescriptions / medical orders from the entire hospital and the internet hospital through data interfaces, parses and breaks them down into sub-tasks, efficiently and rationally allocates them to various intelligent devices for dispensing (or decoction), and distributes the completed drugs to patients / ward nurses through different methods to meet the drug dispensing and usage needs of various diagnostic and treatment services throughout the hospital.

[0357] See appendix Figure 5 The business process is as follows: Start; Obtain prescription and dispensing information; Analyze drug breakdown by treatment; Generate sub-tasks; Pre-allocate tasks; Task management and scheduling algorithms comprehensively analyze the time spent dispensing drugs from the dispensing equipment, estimated completion time, drug pickup / delivery to home, whether pickup time is specified, dispensing for a single patient / ward, and other factors affecting the task; Schedule and distribute tasks; After the dispensing equipment completes dispensing, send a dispensing completion notification; Obtain the medicine cabinet number; Calculate remaining resources for the electronic medicine cabinet. The knowledge base includes knowledge bases for intelligent devices and drugs. The algorithm rule base stores various algorithms used to generate sub-tasks. It can also store the various machine learning models mentioned above. The above business process can be implemented using a control server or jointly implemented by the control server and other servers.

[0358] To achieve task sorting and distribution for medication dispensing equipment (taking into account factors such as dispensing time, estimated completion time, delivery timeliness, and medication placement in wards), a full-process workflow of "data integration → multi-dimensional modeling → dynamic sorting → task distribution" is required. The specific steps are as follows:

[0359] I. Data Integration: Collect real-time data on all influencing factors. Collect key information from various systems / devices as the basis for sorting: Drug dispensing equipment data: processing time per task (e.g., it takes an average of 30 seconds to dispense one box of medicine on a certain device, and 2 minutes to place the medicine onto the ward tray); current equipment status (idle / busy / malfunctioning), number of queued tasks and estimated completion time (e.g., device A currently has 5 tasks, and is expected to be idle in 10 minutes).

[0360] Order / Patient Information: Patient information (ward, whether inpatient / outpatient, if medications are dispensed in the ward, they need to be processed centrally by department); delivery requirements (whether to deliver to home, specific pickup time window, such as "delivery between 15:00-16:00"); task priority (such as emergency patients > general inpatients > outpatients with home delivery).

[0361] Other influencing factors: drug characteristics (e.g., refrigerated drugs need to be handled with priority to avoid spoilage); external constraints (e.g., medication distribution in the ward needs to be completed before nurses' rounds, and home delivery is subject to traffic restrictions).

[0362] II. Multi-dimensional modeling: Transforming elements into computable ranking indicators.

[0363] The collected information is quantified to generate the core metrics needed for ranking.

[0364] Time indicators: Absolute deadlines for tasks (e.g., "Home delivery must be completed before 16:00" or "Medication distribution in the ward must be completed before 8:00").

[0365] Estimated processing time for the device (current number of tasks × time per task + time for new task; for example, if device A's current tasks take 10 minutes and the new task takes 2 minutes, then it is estimated to be completed in 12 minutes).

[0366] Buffer time (allow time for emergencies, such as an additional 20-minute traffic buffer for home delivery).

[0367] Priority score: Calculate a 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) + Importance of Medications (Refrigerated medications add 1 point). The higher the score, the higher the ranking.

[0368] Ward / Delivery Aggregation Indicator: For medication dispensing tasks in the same ward, calculate "time saved by centralized processing" (if 5 tasks in the same ward take 10 minutes to process separately, and 7 minutes to process centrally, then the aggregation priority is increased).

[0369] For home delivery tasks within the same area, cluster them by geographical location (such as grouping orders from the same community together to reduce delivery round-trip time).

[0370] III. Dynamic Sorting Algorithm: Generate the optimal task sequence based on comprehensive indicators.

[0371] Based on the above indicators, a "multi-objective optimization algorithm" is used to rank them, balancing efficiency and constraints:

[0372] Algorithm selection: Simple scenarios: Use "weighted sorting method", sorting by "priority score descending + deadline time ascending + ward / region aggregation"; Complex scenarios: Use "genetic algorithm" or "simulated annealing algorithm", minimizing total processing time and equipment idle rate while meeting the deadline.

[0373] Sorting logic example:

[0374] 1. First, filter out tasks with the earliest absolute deadline (such as ward medication dispensing that needs to be completed before 8:00 AM) and prioritize allocating them to available equipment;

[0375] 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).

[0376] 3. Home delivery tasks are sorted by "priority score + regional clustering" to ensure that high-priority orders in the same region are processed continuously;

[0377] 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)...).

[0378] 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.

[0379] 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.

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

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

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

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

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

[0385] In one embodiment, the hospital's data is as follows: Maximum concurrent users: 30,000 / day. Peak inpatient volume (9:30-10:00): 20,000. Outpatient volume: 15,000. 300 orders / second. 2. First-time medication dispensing accuracy: >99.99%. 3. Longest time to receive prescriptions: Western medicine 5-6 minutes, Traditional Chinese medicine: 10-15 minutes. 4. Longest time to produce prescriptions: Box: 1 minute, Herbal slices: 10+ minutes, Manual: 15-20 minutes (for granules). 5. Longest time for system expansion per year: <10 minutes / year. 6. Longest time to switch from manual to automatic: <30 minutes. 7. Maximum number of devices: >50 sets of main equipment. 8. False alarm rate: <5%. 9. Real-time hot backup: Data hot backup (hard drive RAID).

[0386] Within the framework of the national deepening of the medical and health system reform, this system is closely related to the top-level policy design. In hospital pharmacies, automated equipment can achieve more efficient and accurate closed-loop supervision of drugs from prescription receipt, dispensing to delivery.

[0387] The mature application of IoT technology in the medical field provides solid support for this system. A material transport network composed of modular conveyor belts and AGVs has been successfully operating in several top-tier hospitals. The widespread adoption of this technology enables real-time data exchange between devices, removing technical obstacles to the construction of a central dispatch system.

[0388] Improving patient services. The system transforms the traditional medication dispensing experience by comprehensively reducing prescription dispensing time through an intelligent sorting system and parallel processing architecture, and supports real-time monitoring of dispensing progress via WeChat. In terms of security, a dual verification mechanism of "RFID tags + machine vision" ensures 100% matching between medications and prescriptions (error rate controlled to one in 100,000). For patients with chronic diseases, the system seamlessly connects to internet hospital platforms, providing a one-stop service of "online prescription - automatic dispensing - home delivery," effectively responding to the National Health Commission's requirement to "reduce the number of times patients need to visit medical facilities."

[0389] Improving hospital operations. The central pharmacy model will bring efficiency improvements. By integrating various pharmacies within the hospital and achieving fully automated dispensing, dispensing capacity will be enhanced, and manpower will be reduced (mainly for equipment maintenance and emergency response), significantly saving the hospital's labor costs. In terms of space utilization, the reduced number of traditional manual dispensing windows can be transformed into value-added service spaces such as rational drug use consultation areas. Regarding quality control, the system automatically records temperature and humidity sensor data, equipment operation logs, and the time of each dispensing stage, meeting the requirements for full traceability of pharmaceuticals.

[0390] An industry-leading innovation. As the first smart pharmacy to cover the dispensing of all types of medicines, this system will fill a gap in the industry: its "dynamic task scheduling management" can solve the problem of coordination between different dosage forms and equipment. More importantly, the big data on drug consumption accumulated through automated processes can provide accurate data for hospital DRG cost accounting, contributing to medical insurance payment reform.

[0391] Establish a quantitative indicator system: In terms of automation coverage, achieve 100% automated packaging of Western medicine tablets / capsules, and over 85% automation of traditional Chinese medicine decoction piece dispensing (the remaining 15% requires manual verification for special medicinal materials). Service timeliness strictly adheres to automatic order acceptance within 6 minutes for outpatient and inpatient Western medicine and within 10-15 minutes for traditional Chinese medicine. The accuracy rate of dispensing medication on the first attempt is >99.99%, and the maximum time for automatic processing after manual handling of equipment malfunctions does not exceed 30 minutes. The maximum time for automated production or dispensing is: 1 minute for boxed medications, 10 minutes for decoction pieces, and 15-20 minutes for granules without decoction. The system supports a maximum daily concurrent volume of 30,000 prescriptions (medical orders), including 20,000 during peak inpatient hours (9:30-10:00) and 15,000 during peak outpatient hours, with a maximum support of 300 prescriptions per second. The maximum system downtime is no more than 10 minutes per year. The false alarm rate is <5%.

[0392] A "Standardized Operation Manual for Unmanned Pharmacies" was developed, covering multiple SOP processes such as daily equipment inspections and drug protection during power outages. A three-tiered emergency response mechanism was also established: a manual assistance mode is activated in case of automation failure, and a local independent operation mechanism with a hot standby machine is activated in case of network interruption, ensuring the continuity of services at the central pharmacy.

[0393] In some embodiments, the above-mentioned industrial control management system includes: a monitoring management module, used to monitor the status of prescriptions and equipment in real time, push policy information and generate statistical reports;

[0394] The exception handling module is used to connect with pharmacists to enable manual entry, confirmation and processing of abnormal prescriptions;

[0395] The hot standby module is used to enable dual-machine hot standby and status switching of prescriptions and equipment, ensuring business continuity;

[0396] The early warning module is used to perform statistical analysis, trend prediction, and early warning push based on real-time equipment operation data;

[0397] The medication dispensing decision module is used to call upon the knowledge base and decision tree to perform medication order scheduling and anomaly detection;

[0398] The interface and conversion module is used to connect with diagnostic systems and third-party systems, unify data formats, and push data to the MQ channel.

[0399] Based on the same inventive concept, this application proposes a method for intelligent industrial control management of the entire pharmaceutical process, implemented based on the aforementioned intelligent industrial control management system for the entire pharmaceutical process, which includes:

[0400] A control server, and message management servers, device management servers, data acquisition and detection servers, and auxiliary equipment management servers connected to the aforementioned control server; a medication management server;

[0401] The above methods include:

[0402] The medication management server digitizes the entire process of medication dispensing, distribution, and inventory management, including: medication information management, medication process control, inventory monitoring and early warning, and recording and traceability.

[0403] The aforementioned message management server employs a message subscription mechanism to decouple the aforementioned control server and the aforementioned medication management server, enabling asynchronous collaboration.

[0404] The control server controls the aforementioned equipment management server, the aforementioned data acquisition and detection server, and the aforementioned auxiliary equipment management server.

[0405] The aforementioned equipment management server, under the control of the aforementioned control server, controls the dispensing equipment to dispense medicines.

[0406] Under the control of the aforementioned control server, the auxiliary equipment management server controls the medicine decoction equipment to decoct the medicine.

[0407] Under the control of the aforementioned control server, the aforementioned data acquisition and detection server controls the detection device to perform detection.

[0408] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of this disclosure. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

Claims

1. A fully intelligent industrial control management system for the entire pharmaceutical process, characterized in that, include: A control server is connected to a message management server, a device management server, a data acquisition and detection server, and an auxiliary device management server, respectively, and is used to control the device management server, the data acquisition and detection server, and the auxiliary device management server; The medication management server is used for the digital management of the entire process of medication dispensing, distribution, and inventory. Specifically, it includes: medication information management, medication process control, inventory monitoring and early warning, and recording and traceability. The message management server connects the control server and the medication management server; it is used to employ a message subscription mechanism to decouple the control server and the medication management server and enable asynchronous cooperation. The device management server is used to control the drug dispensing equipment to dispense drugs under the control of the control server; The auxiliary equipment management server is used to control the medicine decoction equipment to decoct medicines under the control of the control server. The acquisition and detection server is used to control the detection device to perform detection under the control of the control server; The control server is used to analyze the real-time load of each drug dispensing device using a clustering algorithm, and dynamically allocate tasks based on order volume prediction. The control server is used for task scheduling, and in task scheduling, the candidate device score is calculated using the following formula: Score=w1 SPT+w2 EDD+w3 SetupCost+w4 LocationCost+w5 Reliabilit; 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 medication management server employs machine learning algorithms to optimize inventory and order processing, inventory forecasting, and dynamic replenishment. It uses time series models to predict future drug demand based on historical order data and proactively pushes replenishment suggestions to the control server. The order priority intelligent sorting combines user information, drug characteristics and equipment load, and uses a reinforcement learning model to dynamically sort orders, sending high-priority orders to the control server first, so that the control server can prioritize the allocation of high-priority orders to the equipment management server, thereby improving the response speed of urgent orders. The device management server is used to predict device faults using machine learning algorithms, collect device data, learn the normal operating mode of the device using anomaly detection algorithms, identify abnormal states in real time, predict fault risks in advance, and send maintenance instructions to the control server; and to correct motion parameters in real time using a supervised learning model for positional deviations when the robotic arm picks up medicine.

2. The intelligent industrial control management system for the entire pharmaceutical process according to claim 1, characterized in that, The detection device includes: Barcode / QR code scanner, used to scan barcodes or QR codes on medicine packaging; RFID readers are used to read information from RFID tags attached to medicines using radio frequency identification technology. Image recognition detectors are used to photograph medicines using a camera and combine image algorithms to detect the shape, color, and size of the medicines. Weight detection device for detecting the weight of solid medicines; Temperature and humidity sensors are used to monitor the temperature and humidity of the environment where medicines are stored and distributed. Facial recognition / fingerprint recognition devices are used to verify the identity of pharmacists or patients when they collect medications; Operational behavior monitoring cameras are used for video surveillance, behavior analysis, and to detect whether the drug dispensing process complies with standard procedures.

3. The intelligent industrial control management system for the entire pharmaceutical process according to claim 1, characterized in that, The control server is also used for For emergency handling of abnormal orders, when the medication management server reports insufficient drug inventory or the equipment management server reports temporary equipment failure, an alternative solution is automatically generated using a decision tree model.

4. The intelligent industrial control management system for the entire pharmaceutical process according to claim 1, characterized in that, The control server is also used for dictionary maintenance, drug configuration, treatment task configuration, prescription management, prescription analysis, task review, task monitoring, and task query.

5. The intelligent industrial control management system for the entire pharmaceutical process according to claim 1, characterized in that, It also includes a hot standby unit for offline processing of received but not yet completed prescriptions in the event of a control server failure or network anomaly.

6. The intelligent industrial control management system for the entire pharmaceutical process according to claim 1, characterized in that, It also includes a business dashboard connected to the control server. The business dashboard is used to display the operation of the dispensing and medication dispensing business in the form of a floor plan and timed data refresh. It supports real-time statistics of business data and the generation of charts and graphs. It also supports real-time query of prescription details and detailed data of each prescription during the dispensing or decoction process.

7. The intelligent industrial control management system for the entire pharmaceutical process according to claim 1, characterized in that, The control server is also equipped with a diagnosis and treatment management system, a central control management system, an equipment detection and early warning system, a medication management system, a case learning system, and an operation and maintenance management system. The diagnosis and treatment management system is used for information management and scheduling throughout the entire diagnosis and treatment process; The central control management system is used to coordinate and link the diagnosis and treatment management system, the equipment detection and early warning system, the medication management system, the case learning system, and the operation and maintenance management system. The medication management system is used for the entire process management of medication dispensing; The case learning system is used to accumulate historical case data; The device detection and early warning system is used to receive data collected by the data acquisition and detection server from the detection device, and to determine whether the detection device needs to be replaced based on the collected data. The operation and maintenance management system is used to update equipment data in real time after the testing device is replaced.

8. A method for intelligent industrial control management of the entire pharmaceutical process, characterized in that, This is implemented based on a fully intelligent industrial control management system for the entire pharmaceutical process, which includes: A control server, and message management server, device management server, data acquisition and detection server, and auxiliary equipment management server connected to the control server; a dispensing management server; The method includes: The medication management server digitally manages the entire process of drug dispensing, distribution, and inventory, including: drug information management, medication process control, inventory monitoring and early warning, and recording and traceability. The message management server adopts a message subscription mechanism to decouple the control server and the medication management server and enable asynchronous cooperation. The control server controls the device management server, the data acquisition and detection server, and the auxiliary equipment management server. The device management server, under the control of the control server, controls the drug dispensing equipment to dispense drugs; The auxiliary equipment management server, under the control of the control server, controls the medicine decoction equipment to decoct the medicine; The data acquisition and detection server, under the control of the control server, controls the detection device to perform detection; The control server uses a clustering algorithm to analyze the real-time load of each drug dispensing device and dynamically allocates tasks based on order volume prediction. The control server calculates candidate device scores using the following formula during task scheduling: Score=w1 SPT+w2 EDD+w3 SetupCost+w4 LocationCost+w5 Reliabilit; Where w1 is the weight of the shortest processing time; SPT stands for minimum processing time; w2 represents the weight 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 medication management server employs machine learning algorithms to optimize inventory and order processing, inventory forecasting, and dynamic replenishment. It uses time series models to predict future drug demand based on historical order data and proactively pushes replenishment suggestions to the control server. The order priority intelligent sorting combines user information, drug characteristics and equipment load, and uses a reinforcement learning model to dynamically sort orders, sending high-priority orders to the control server first, so that the control server can prioritize the allocation of high-priority orders to the equipment management server, thereby improving the response speed of urgent orders. The device management server uses machine learning algorithms to predict device faults, collects device data, uses anomaly detection algorithms to learn the normal operating mode of the device, identifies abnormal states in real time, predicts fault risks in advance, and sends maintenance instructions to the control server; and uses a supervised learning model to correct motion parameters in real time for positional deviations when the robotic arm picks up medicine.

Images