Drug inventory dynamic monitoring method and system based on edge calculation

Abstract

The invention provides a drug inventory dynamic monitoring method and system based on edge calculation. The drug inventory dynamic monitoring method comprises the steps that drug parameters and environment data of all intelligent drug cabinets and warehouse areas and biological characteristics of operators are collected; determining a behavior log of the operator according to the operation action and the medicine change data, and generating a digital signature of the operator through the biological characteristics; constructing lightweight block chain nodes of the intelligent medicine cabinets and the warehouse areas, and packaging and chaining behavior logs and digital signatures through inter-node consensus of all the block chain nodes to generate an operation voucher; according to the average compliance rate and the operation voucher, carrying out trust evaluation on the compliance condition during operation to obtain a trust score; and comparing the trust score with a trust threshold, and if the trust score is lower than the trust threshold, locking the high-risk drug operation authority of the operator. By adopting the scheme of the invention, real-time credible evidence storage and dynamic evaluation can be carried out through behaviors of an operator, so that timely interception and early warning of high-risk medicine operation are realized.

Description

Technical Field

[0001] This application relates to the field of dynamic monitoring technology, and more specifically, to a method and system for dynamic monitoring of drug inventory based on edge computing. Background Technology

[0002] Dynamic monitoring of drug inventory is a critical link in medical management and supply chain security, involving the real-time collection and reliable processing of multi-dimensional data such as drug storage and retrieval, environmental control, and operational traceability. Traditional monitoring systems mostly rely on centralized cloud platforms for data processing and storage. However, when faced with large-scale distributed drug cabinets, high-frequency drug operations, and the real-time requirements of sensitive data, they often encounter problems such as high latency, high bandwidth pressure, easy data tampering, and privacy risks, making it difficult to meet the stringent requirements of drug management for reliable operations, traceable processes, and controllable risks.

[0003] Current dynamic monitoring systems mostly employ a centralized cloud-based architecture, transmitting video streams or sensor data back to a central server for analysis and recording. However, this approach suffers from poor real-time performance, strong network dependence, and vulnerability to data tampering or leakage during transmission and storage. Furthermore, it struggles with reliable evidence storage and dynamic evaluation of operator behavior. In addition, traditional access control is largely statically configured, unable to adapt to real-time operator actions, making it difficult to promptly intercept and issue warnings for high-risk operations. Therefore, how to achieve timely interception and warnings for high-risk drug-related operations through real-time reliable evidence storage and dynamic evaluation of operator behavior has become a significant challenge for the industry. Summary of the Invention

[0004] This application provides a method and system for dynamic monitoring of drug inventory based on edge computing, which can realize timely interception and early warning of high-risk drug operations by performing real-time reliable evidence storage and dynamic evaluation based on operator behavior.

[0005] In a first aspect, this application provides a method for dynamic monitoring of drug inventory based on edge computing, comprising the following steps: The edge sensing module collects drug parameters, environmental data, and operator biometrics from each smart medicine cabinet and storage area, and obtains the operator's actions and drug change data when handling the drugs. Based on the timestamps of the operation actions and the drug change data, the operator's behavior log during drug operation is determined, and the operator's digital signature is generated using the biometrics. Lightweight blockchain nodes are built for each smart medicine cabinet and storage area on the regional edge server. The behavior logs and digital signatures are packaged and uploaded to the chain through the consensus between all blockchain nodes, thereby generating an unalterable operation certificate that is linked in chronological order when the operator operates on the medicine. Obtain the average compliance rate of all operators, and make a trust assessment of the operator's compliance status during operation based on the average compliance rate and the historical behavior set in the operation credentials, so as to obtain the trust score of the operator. The trust score is compared with a preset trust threshold. If the trust score is lower than the trust threshold, the operator's high-risk drug operation privileges are locked, and an alarm notification is generated and sent to the edge monitoring terminal.

[0006] In some embodiments, determining the operator's behavior log during drug handling based on the timestamp of the operation and the drug change data specifically includes: The timing sequence of the drug operator's actions to manipulate the drug is determined based on the timestamps of the aforementioned actions. The operation content of the drug operator on the drug is determined based on the drug change data; The operator's behavior log during drug handling is determined by the action sequence and the operation content.

[0007] In some embodiments, generating the operator's digital signature using the biometrics specifically includes: The biometric features are matched with a pre-built personnel feature database on the edge server to obtain a unique identity identifier for the operator. The digital signature of the operator is generated by calling the digital certificate private key pre-installed in the security module and bound to the identity identifier.

[0008] In some embodiments, building lightweight blockchain nodes for each smart medicine cabinet and storage area on a regional edge server specifically includes: Configure all smart medicine cabinets and edge servers in the drug warehouse as peer nodes of the blockchain network; Each smart medicine cabinet and storage area edge server is assigned a unique, fixed network identifier through the internal local area network; Configure all network identifiers to the listening ports of the corresponding blockchain protocol stack; All peer nodes are pre-loaded into the configuration file of each edge server, ensuring that each node can learn about other legitimate peer nodes through the listening port when it starts up, thereby obtaining multiple blockchain nodes.

[0009] In some embodiments, the behavior log and the digital signature are packaged and uploaded to the blockchain through consensus among all blockchain nodes, thereby generating an unalterable operation certificate that is linked in chronological order when the operator operates on the medicine. Specifically, this includes: Determine the initiating node of the operator during this drug operation from all blockchain nodes; The initiating node stores the record of a single drug operation into a digitally signed data packet in the blockchain to obtain a transaction data packet; The transaction data packet is broadcast to a blockchain network consisting of peer nodes from all medicine cabinets and storage areas; When any peer node receives the transaction data packet, it performs consensus verification on the transaction data packet, and then puts the verified transaction data packet into the transaction pool to be packaged for caching. When the number of transaction data packets in the transaction pool reaches a threshold, the current accounting node is selected based on the trust consensus among the various blockchain nodes. The ledger node selects multiple transaction data packets from the transaction pool, packages them into a new block, and sets the time for evidence storage. The new block is verified across the entire network. Each blockchain node appends the verified new block to the end of its own blockchain, resulting in an operation credential that is linked in chronological order and cannot be tampered with.

[0010] In some embodiments, the trust score of the operator is obtained by assessing the operator's compliance during operation based on the average compliance rate and the historical behavior set in the operation credentials, specifically including: Determine the set of historical behaviors in the operation voucher; Based on the behavior logs and operation times in the historical behavior set, a time-sensitive correlation is performed on the operator's historical compliance status to obtain the direct trust level of the operator's compliance status during operation. The operator's trust score is determined based on the direct trust level and the average compliance rate.

[0011] In some embodiments, locking the operator's access to high-risk medications specifically includes: The control logic module immediately generates a control command to lock permissions. The locking command is sent to all smart medicine cabinets and storage area nodes currently used by the operator; Upon receiving the control command, the edge computing unit of the medicine cabinet verifies the signature and immediately disables the operator's access permissions for high-risk medicines in the local permission list.

[0012] Secondly, this application provides a drug inventory dynamic monitoring system based on edge computing, comprising: The data acquisition module is used to collect drug parameters, environmental data, and operator biometrics from each smart medicine cabinet and storage area through the edge sensing module, and to obtain the operator's actions and drug change data when handling the drugs. The processing module is used to determine the operator's behavior log during drug operation based on the timestamp of the operation and the drug change data, and to generate the operator's digital signature through the biometrics; The processing module is also used to build lightweight blockchain nodes for each smart medicine cabinet and warehouse area on the regional edge server, and package the behavior log and the digital signature onto the chain through the consensus between all blockchain nodes, thereby generating an operation certificate that is connected in chronological order and cannot be tampered with when the operator operates on the medicine. The processing module is also used to obtain the average compliance rate of all operators, and to make a trust assessment of the operator's compliance status during operation based on the average compliance rate and the historical behavior set in the operation certificate, so as to obtain the operator's trust score. The execution module is used to compare the trust score with a preset trust threshold. If the trust score is lower than the trust threshold, the operator's high-risk drug operation privileges are locked, and an alarm notification is generated and sent to the edge monitoring terminal.

[0013] Thirdly, this application provides a computer device, the computer device including a memory and a processor, the memory storing code, and the processor being configured to acquire the code and execute the above-described edge computing-based dynamic monitoring method for drug inventory.

[0014] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned edge computing-based dynamic monitoring method for drug inventory.

[0015] The technical solutions provided by the embodiments disclosed in this application have the following beneficial effects: The drug inventory dynamic monitoring method based on edge computing provided in this application firstly... The edge sensing module collects drug parameters, environmental data, and operator biometrics from each smart medicine cabinet and storage area, and obtains the operator's actions and drug change data when handling drugs. Based on the timestamps of the actions and the drug change data, the operator's behavior log during drug handling is determined, and a digital signature of the operator is generated using the biometrics. Lightweight blockchain nodes are constructed for each smart medicine cabinet and storage area on the regional edge server. Through consensus among all blockchain nodes, the behavior log and digital signature are packaged and uploaded to the blockchain, thereby generating an undisturbed operation certificate linked chronologically when the operator handles the drugs. The average compliance rate of all operators is obtained. Based on the average compliance rate and the historical behavior set in the operation certificate, a trust assessment is performed on the operator's compliance during operation, resulting in a trust score for the operator. The trust score is compared with a preset trust threshold. If the trust score is lower than the threshold, the operator's high-risk drug handling permissions are locked, and an alarm notification is generated and sent to the edge-side monitoring terminal.

[0016] Therefore, in the edge computing-based dynamic monitoring method for drug inventory, this application first collects drug parameters, environmental data, and operator biometrics at each smart medicine cabinet and storage area through an edge sensing module, and obtains the operator's actions and drug change data when handling the drugs. Based on the timestamps of the actions and the drug change data, the operator's behavior log during drug handling is determined, and a digital signature of the operator is generated using the biometrics. Lightweight blockchain nodes are constructed at the regional edge server for each smart medicine cabinet and storage area. Through consensus among all blockchain nodes, the behavior log and the digital signature are packaged and uploaded to the blockchain, thereby generating an undisturbed operation token that is sequentially linked in time when the operator handles the drugs. The above scheme involves several steps. First, the operation credential refers to a digital evidence entity generated and maintained by a blockchain network based on edge computing, used to record a single drug operation. In this blockchain-based system, the entire blockchain network maintains a unique, globally consistent chain of operation credentials, which includes the blockchains maintained by each blockchain node. Second, the average compliance rate of all operators is obtained. Based on this average compliance rate and the historical behavior set in the operation credential, a trust assessment is performed on the operator's compliance during operations, resulting in a trust score for the operator. This trust score is then compared with a preset trust threshold. If the trust score is lower than the threshold, the operator's high-risk drug operation privileges are locked, and an alarm notification is generated and sent to the edge-side monitoring terminal. This scheme enables timely interception and early warning of high-risk drug operations through real-time reliable evidence storage and dynamic evaluation of operator behavior. Attached Figure Description

[0017] Figure 1 This is an exemplary flowchart of a drug inventory dynamic monitoring method based on edge computing, as shown in some embodiments of this application. Figure 2 This is an exemplary flowchart illustrating the determination of behavior logs according to some embodiments of this application; Figure 3 This is an exemplary flowchart illustrating the determination of a trust score according to some embodiments of this application; Figure 4 This is a schematic diagram of the structure of a drug inventory dynamic monitoring system based on edge computing, as shown in some embodiments of this application; Figure 5 This is a schematic diagram of the structure of a computer device that implements a dynamic monitoring method for drug inventory based on edge computing, according to some embodiments of this application. Detailed Implementation

[0018] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0019] refer to Figure 1 The figure is an exemplary flowchart of a drug inventory dynamic monitoring method based on edge computing, according to some embodiments of this application. The drug inventory dynamic monitoring method based on edge computing mainly includes the following steps: In step 101, the edge sensing module collects drug parameters, environmental data and operator biometrics at each smart medicine cabinet and storage area, and obtains the operator's operation actions and drug change data when operating the medicine.

[0020] In specific implementation, the collection of drug parameters, environmental data, and operator biometrics at each smart medicine cabinet and storage area via the edge sensing module can be achieved in the following way: An edge sensing module is deployed at each smart medicine cabinet and storage area node. This edge sensing module integrates multi-source heterogeneous sensors, forming the terminal layer of the cloud-edge-device framework. Specifically, it includes: a weight sensor for real-time monitoring of weight changes during drug removal and placement; an industrial camera for capturing operator actions and visual information from drug packaging; a biometric collector, such as a face recognition module; and environmental sensors such as temperature and humidity sensors. All sensors are driven by the edge computing unit built into the medicine cabinet, performing millisecond-level synchronous acquisition and local preprocessing. Preprocessing includes data alignment and noise reduction, thereby obtaining the drug parameters, environmental data, and operator biometrics at each smart medicine cabinet and storage area. Drug parameters include at least the product barcode, unique drug traceability code, and quantity change data; environmental data includes at least the temperature and humidity values ​​inside the drug storage cabinet and the storage device status; and operator biometrics include facial feature point vectors generated by face recognition and liveness detection signals. Other methods can be used in other embodiments, which are not limited here.

[0021] In step 102, the operator's behavior log during drug handling is determined based on the timestamp of the operation and the drug change data, and the operator's digital signature is generated through the biometrics.

[0022] In some embodiments, reference Figure 2 As shown, this diagram is an exemplary flowchart for determining behavior logs in some embodiments of this application. In this embodiment, determining the operator's behavior log during drug handling based on the timestamp of the operation and the drug change data can be achieved through the following steps: First, in step 1021, the timing of the drug operator's manipulation of the drug is determined based on the timestamp of the operation. Secondly, in step 1022, the operation content of the drug operator on the drug is determined based on the drug change data; Finally, in step 1023, the operator's behavior log during drug handling is determined by the action sequence and the operation content.

[0023] In specific implementation, determining the timing of the operator's manipulation of the drug based on the timestamps of the operation can be achieved in the following way: the edge computing module analyzes the operator's actions and visual information of the drug packaging captured by the industrial camera, and extracts key event points and their timestamps from the operation actions; for example, events such as a hand approaching the medicine cabinet, the cabinet door changing to open, a hand taking out an item, and the cabinet door changing to close can be identified from the visual data. By analyzing the sequence and interval of these discrete event timestamps and matching them with the standard operation process preset at the edge, a complete action timing logic chain for this operation can be constructed, that is, the timing of the operator's manipulation of the drug; other embodiments may also use other methods, which are not limited here.

[0024] In specific implementation, determining the operator's actions on the medication based on the medication change data can be achieved in the following way: while recognizing the timing of the manipulation actions, the edge computing module parses the medication change data, such as the difference in weight sensor values ​​and changes in medication labels identified by the camera; these data directly reflect the actual result of the operation, such as taking away 3 boxes of medication A or putting back 2 vials of medication B; thereby associating the timing of the operation with the operation content, a complete business profile of the operator that includes both the process and the result can be constructed; other embodiments may also use other methods, which are not limited here.

[0025] In specific implementation, the behavior log of the operator during drug handling, determined by the action sequence and operation content, can be implemented in the following way: the edge computing module encapsulates the above action sequence and operation content in a structured manner to generate an unchangeable structured behavior log; wherein, the behavior log includes at least a unique log ID, operator ID, operation timestamp sequence, operation type, drug identifier, quantity change value, and environmental parameters; the behavior log is the atomic data unit for all subsequent trust assessments and blockchain notarization; other embodiments may also use other methods to implement this, which are not limited here.

[0026] It should be noted that the behavior log in this application refers to the core data entity that records the entire process of a single drug operation by an operator. It is generated synchronously by the edge side when the operation occurs. By structurally integrating discrete sensor signals, i.e., action timing, with business results, i.e. operation content, a complete and machine-readable operation archive is formed. As a trusted data atom of the entire system, the behavior log's immutability ensures the authenticity of upstream perception and provides a unique and authoritative data source for downstream blockchain evidence storage and dynamic trust assessment.

[0027] In some embodiments, generating the operator's digital signature using the biometrics can be achieved through the following steps: The biometric features are matched with a pre-built personnel feature database on the edge server to obtain a unique identity identifier for the operator. The digital signature of the operator is generated by calling the digital certificate private key pre-installed in the security module and bound to the identity identifier.

[0028] In specific implementation, matching the biometric features with a pre-installed personnel feature database on the edge server to obtain the operator's unique identity can be achieved in the following way: using the collected biometric features, a rapid matching and identity authentication is performed in the local or regional personnel feature database on the edge server to obtain the operator's unique identity; the digital signature of the operator is generated by calling the digital certificate private key pre-installed in the security module and bound to the identity, which can be achieved in the following way: after identity authentication is passed, the operator's identity is associated with the operator's pre-installed digital certificate, so that the system calls the corresponding private key of the operator stored in the security hardware module, and performs elliptic curve digital signature algorithm calculation on the hash value in the structured behavior log to finally generate the operator's digital signature; other embodiments may also use other methods, which are not limited here.

[0029] It should be noted that the digital signature in this application is a cryptographic credential that is legally valid, non-repudiable, and strongly bound to the operator's identity and specific operational behavior. It is generated by calculating the hash value of the operation log using the operator's private key, and utilizes the security of the elliptic curve digital signature algorithm to ensure that any tampering with the operation log will result in signature verification failure. This technically meets the requirements of the Electronic Signature Law for reliable electronic signatures and provides a legally binding technical foundation for subsequent blockchain evidence storage and accountability.

[0030] In step 103, lightweight blockchain nodes for each smart medicine cabinet and storage area are constructed on the regional edge server. The behavior logs and digital signatures are packaged and uploaded to the blockchain through consensus among all blockchain nodes, thereby generating an unalterable operation certificate that is linked in chronological order when the operator operates on the medicine.

[0031] In some embodiments, building lightweight blockchain nodes for each smart medicine cabinet and storage area on a regional edge server can be achieved using the following steps: Configure all smart medicine cabinets and edge servers in the drug warehouse as peer nodes of the blockchain network; Each smart medicine cabinet and storage area edge server is assigned a unique, fixed network identifier through the internal local area network; Configure all network identifiers to the listening ports of the corresponding blockchain protocol stack; All peer nodes are pre-loaded into the configuration file of each edge server, ensuring that each node can learn about other legitimate peer nodes through the listening port when it starts up, thereby obtaining multiple blockchain nodes.

[0032] In some embodiments, building lightweight blockchain nodes for each smart medicine cabinet and storage area also includes running the same lightweight blockchain protocol on all peer nodes, thereby forming a blockchain consortium for drug operations.

[0033] It should be noted that in the blockchain consortium blockchain scenario, a list of admitted nodes is predefined, which contains the network addresses and public keys of all authorized and known edge servers. This list of admitted nodes will be preloaded into the configuration file of each edge server to ensure that each node knows about other legitimate peer nodes in the network when it starts up, thereby building a private and controllable peer network. Other embodiments may also use other methods to achieve this, which are not limited here.

[0034] In specific implementation, the same lightweight blockchain protocol runs on all peer nodes, forming a blockchain consortium for drug operations. This can be achieved in the following way: Deploy and run a lightweight blockchain protocol optimized for edge computing environments on all peer nodes. The core of this lightweight blockchain protocol is a variant of the efficient Byzantine fault-tolerant consensus mechanism, characterized by low communication overhead and no need for high-energy-consuming computing, thus adapting to the limited computing and storage resources of edge servers. Then, based on this protocol, establish a permissioned blockchain network, which is the blockchain consortium for drug operations. This allows only authorized peer nodes of smart medicine cabinets and warehouses to join and participate in consensus, jointly maintaining a distributed ledger dedicated to drug operation evidence storage. Other embodiments may also use other methods, which are not limited here.

[0035] It should be noted that the blockchain consortium for drug operations in this application is a permissioned private blockchain network based on a lightweight Byzantine fault-tolerant consensus mechanism. This blockchain network is composed of all authorized smart medicine cabinets and edge servers of the storage area as peer nodes, which are used to provide an efficient, reliable and low-cost distributed evidence storage environment for the frequently generated drug operation data. This ensures that only compliant operation records can be consensused and stored, thereby building an immutable trust foundation for the entire dynamic monitoring system under a decentralized architecture.

[0036] In some embodiments, the behavior log and the digital signature are packaged and uploaded to the blockchain through consensus among all blockchain nodes to generate an unalterable operation certificate that is linked in chronological order when the operator operates on the medicine. This can be achieved through the following steps: Determine the initiating node of the operator during this drug operation from all blockchain nodes; The initiating node stores the record of a single drug operation into a digitally signed data packet in the blockchain to obtain a transaction data packet; The transaction data packet is broadcast to a blockchain network consisting of peer nodes from all medicine cabinets and storage areas; When any peer node receives the transaction data packet, it performs consensus verification on the transaction data packet, and then puts the verified transaction data packet into the transaction pool to be packaged for caching. When the number of transaction data packets in the transaction pool reaches a threshold, the current accounting node is selected based on the trust consensus among the various blockchain nodes. The ledger node selects multiple transaction data packets from the transaction pool, packages them into a new block, and sets the time for evidence storage. The new block is verified across the entire network. Each blockchain node appends the verified new block to the end of its own blockchain, resulting in an operation credential that is linked in chronological order and cannot be tampered with.

[0037] In specific implementation, determining the initiating node of the operator's current drug operation among all blockchain nodes can be achieved in the following way: After generating a structured behavior log and digital signature, the system automatically maps and locks the edge server corresponding to the physical location where the operation occurred, i.e., the smart medicine cabinet number or warehouse code, by identifying the physical location where the operation occurred. This server is then identified as the initiating node of the current blockchain transaction. The transaction data packet obtained by storing the record of the single drug operation into a digitally signed data packet in the blockchain according to the initiating node can be achieved in the following way: The initiating node calls its corresponding blockchain protocol interface, using the structured behavior log of the current operation and the corresponding digital signature as the core payload, and attaching network protocol header information, thereby encapsulating them into a transaction data structure conforming to the blockchain network format standard, i.e., a digitally signed data packet. The network protocol header information includes at least: transaction version number, initiating node address (or its public key hash), timestamp of the current operation, and hash value of the core payload. Other implementation methods can also be used in other embodiments, which are not limited here.

[0038] In specific implementation, consensus verification of the transaction data packets, and caching of verified transaction data packets in the transaction pool to be packaged, can be achieved in the following way: when any blockchain node receives a broadcast transaction data packet, it immediately initiates an independent verification process. The verification content is divided into three layers: first, cryptographic verification, using the operator's public key to verify the authenticity of the digital signature; second, format and compliance verification, checking whether the transaction structure conforms to predefined rules; and third, business logic pre-verification, where the node can quickly assess the rationality of the operation based on the operator's historical trust status in its local cache, such as frequent operations on high-risk drugs in a short period of time. If all transaction data packets pass verification, the transaction data packets are stored in the transaction pool to be packaged of the blockchain node for caching, awaiting participation in subsequent block consensus. Other embodiments may also use other methods, which are not limited here.

[0039] In specific implementation, when the number of transaction data packets in the transaction pool reaches a threshold, the current accounting node is selected based on the trust consensus among the various blockchain nodes. This can be achieved in the following way: when the transaction pool depth of any blockchain node in the blockchain network reaches a preset threshold (this threshold can be dynamically adjusted according to system performance, for example, set to 100 transactions to balance block production efficiency and consensus latency) or reaches a fixed block production time period (such as every 10 seconds), a new round of accounting node election is triggered. The election process adopts a verifiable voting mechanism based on real-time node status: each blockchain node sorts all candidate blockchain nodes in its locally maintained, blockchain network-synchronized dynamic trust score list and votes for the blockchain node with the highest current trust score. The blockchain network collects the votes from all blockchains and uses the majority rule principle to confirm the blockchain with the most votes as the unique accounting node in this round. If a tie occurs, a round of fast random number drawing based on timestamps is initiated to ensure that the election result is unique and can be independently verified by all blockchain nodes in the blockchain network. Other embodiments may also use other methods, which are not limited here.

[0040] It should be noted that the dynamic trust score list synchronized in this application is a global data list that records and updates in real time the current comprehensive trust status of each peer blockchain node in the blockchain network. The trust score of each blockchain node is a parameter value that characterizes the comprehensive reliability of the blockchain node as a network participant in the historical and current period, and its range is usually defined in the range of [0, 1.0] or [0, 100]. The trust score in this dynamic trust score list is periodically calculated and updated by an independent blockchain node behavior evaluation module. Its calculation basis mainly includes the historical behavior data of the blockchain node as a blockchain network participant, such as: online stability, available time ratio, historical accounting accuracy, the verification pass rate of available packaged blocks, network communication quality, latency and packet loss rate of available broadcast and received data, and computing resource contribution. All the above behavioral data are weighted and averaged to obtain the trust score of the blockchain node.

[0041] In specific implementation, the accounting node selects multiple transaction data packets from the transaction pool, packages them into a new block, and sets the notarization time. This can be achieved in the following way: The accounting node selects a batch of verified transaction data packets from its corresponding local transaction pool according to a priority strategy, such as transaction time and type. The accounting node then constructs a Merkle tree from these transaction data packets, calculates the hash value of the root of the Merkle tree, and generates a new block header containing the hash value, the hash value of the previous block, the version number, and other information. Subsequently, the accounting node signs the block header using the corresponding private key and writes the current authoritative time of the system as the timestamp of the new block, thereby completing the construction of the new block. The timestamp represents the immutable moment when the batch of operations is officially notarized by the system. Other embodiments may also use other methods, which are not limited here.

[0042] It should be noted that the hash value of the previous block is the hash value of the latest and final block on the main blockchain chain corresponding to the ledger node, which has been confirmed by the entire blockchain network. When constructing a new block header, the ledger node must fill in this hash value as a core field, thus enabling the blockchain to achieve the core mechanism of immutability and time-series connection: cryptographically binding the new block with the existing chain. Any tampering with transaction data in historical blocks will cause its hash value to change, thereby breaking the hash reference relationship of all subsequent blocks, which can be detected and rejected by the network instantly. Therefore, this hash value comes directly from the blockchain ledger itself and is the key data for maintaining its integrity and continuity.

[0043] In specific implementation, the new block is verified across the entire network. Each blockchain node appends the verified new block to the end of its own maintained blockchain to obtain an immutable operation certificate linked in chronological order. This can be achieved as follows: the ledger node broadcasts the digitally signed new block to the entire network; when any blockchain node receives the new block, it independently verifies the validity of the digital signature, the legality of all transactions within the new block, and the correctness of the hash link in the new block header pointing to the previous block; the new block is finally confirmed in this round of consensus only after more than 80% of the blockchain nodes in the blockchain network have verified it; subsequently, each blockchain node performs an append operation, attaching the verified new block to the end of the blockchain main chain maintained locally by each blockchain node; through the continuous execution of this process by all blockchain nodes, a globally consistent, chronologically linked, and immutable chain of operation certificates for the medicine is finally constructed and maintained; other embodiments may also use other methods, which are not limited here.

[0044] It should be noted that the operation credential in this application refers to a digital evidence entity generated and maintained by an edge computing-based blockchain network to record a single drug operation. In a blockchain-based system, the entire blockchain network jointly maintains a unique, globally consistent operation credential chain, which includes the blockchains maintained by each blockchain node. The core principle of this effect lies in the distributed consensus mechanism: when a new block is generated, all nodes independently verify its validity according to a predefined protocol; only when a sufficient number of nodes (e.g., more than 80%) have verified it and reached a consensus is the block finally confirmed by the system. Subsequently, all nodes will synchronously append the verified block to the end of their respective local chains. Through this collaborative rule, the content of all nodes' local copies remains highly consistent at any time, and any tampering of its own copy by a single node will be automatically identified and rejected by the system due to incompatibility with other copies. Therefore, this design achieves decentralized trust: data is not stored in a single center, but its immutability, integrity, and global uniqueness are jointly guaranteed through multi-point backup and consensus protocols, thereby forming a trustworthy, time-sequentially connected operation credential chain.

[0045] In step 104, the average compliance rate of all operators is obtained, and the operator's compliance status during operation is assessed based on the average compliance rate and the historical behavior set in the operation credentials to obtain the operator's trust score.

[0046] In specific implementation, the average compliance rate of all operators can be obtained in the following way: From the operation certificate chain of drug operations, query and obtain each behavior log of all operators within a preset historical period. Each log contains the operation compliance judgment result, such as compliant or non-compliant, and the operation timestamp. Then, firstly, the operators are grouped according to their role attributes (e.g., pharmacist, nurse, warehouse keeper). Then, calculate the individual historical compliance rate of all members in each role group. The formula for calculating the individual historical compliance rate is: Individual historical compliance rate = Number of compliant operations by the individual / Total number of operations. Next, calculate the arithmetic mean of the compliance rates of all members in the group. The resulting value is the benchmark compliance rate for the corresponding role. The benchmark compliance rate is the indirect trust value, representing the general behavioral level of the role group, providing an objective and stable reference system for evaluating individuals. Other implementation methods can also be used in other embodiments, which are not limited here.

[0047] In some embodiments, reference Figure 3 As shown, this diagram is an exemplary flowchart for determining a trust score in some embodiments of this application. In this embodiment, the trust score of the operator is obtained by judging the compliance of the operator's operation based on the average compliance rate and the historical behavior set in the operation credentials. This can be achieved through the following steps: First, in step 1041, the set of historical behaviors in the operation certificate is determined; Secondly, in step 1042, the operator's historical compliance status is time-sensitively correlated based on the behavior logs and operation time in the historical behavior set to obtain the direct trust level of the operator's compliance status during operation; Finally, in step 1043, the operator's trust score is determined based on the direct trust level and the average compliance rate.

[0048] In specific implementation, the historical behavior set in the operation certificate can be determined in the following way: using the operator's unique identifier as the query key, a query request is initiated to the operation certificate chain. The request sets a time range parameter, such as the evaluation period. All blockchain nodes in the operation certificate chain query and return all structured behavior logs generated by the operator within the evaluation period that have been uploaded to the chain. The collection of these logs constitutes the historical behavior set. Since each log is verified by blockchain consensus and permanently stored, the integrity, authenticity, and non-repudiation of the historical behavior set data are ensured, laying a credible data foundation for objective evaluation and demonstrating the practice of using blockchain to build a credible evaluation environment. Other embodiments may also use other methods to implement this, which are not limited here.

[0049] In specific implementation, the operator's historical compliance status is time-sensitively correlated with the behavior logs and operation times in the historical behavior set to obtain the operator's direct trust level for compliance during operation. This can be achieved in the following way: each log in the historical behavior set is parsed by the evaluation engine, and the operation compliance judgment result and historical operation timestamp are extracted. Then, a decay weight that decays exponentially over time is assigned to each historical operation through a time decay function, so that the impact of recent operations on the operator's current trust is much greater than that of earlier operations. Then, the decay weights of all compliant operations are summed, and then divided by the sum of the decay weights of all compliant and non-compliant operations to obtain the operator's direct trust level at the current moment. Other embodiments may also use other methods to achieve this, which are not limited here.

[0050] It should be noted that the direct trust level in this application is a parameter value that quantifies the operator's immediate compliance capability and direct reliability based on their personal historical operation records. The time decay function (such as exponential decay) systematically and quantitatively reduces the weight of long-standing historical events through factors like the exponent, while amplifying the influence of recent behavior. This makes direct trust level a future-oriented, predictive indicator that better reflects the operator's current true reliability status, rather than the sum of their entire history. Simply calculating the historical compliance rate is a form of equal voting, ensuring that the impact of errors across different time periods is the same, which can easily cause the assessment results to lag behind actual changes in personnel. Therefore, by assigning different weights to each operation according to its occurrence time, we can focus on recent trends, more sensitively capture positive improvements or negative declines in the operator's status, and provide data-driven early warnings for timely intervention.

[0051] In specific implementation, the trust score of the operator can be determined based on the direct trust level and the average compliance rate in the following manner: First, the statistical volatility of the operator's direct trust level sequence is calculated, and the ratio of its standard deviation to the mean is defined as the stability coefficient. The larger the stability coefficient, the more unstable the operator's performance. The fusion weight is then dynamically adjusted based on the stability coefficient: if the stability coefficient is high, the weight of the direct trust level is reduced, and the weight of the average compliance rate, which represents the group level, is increased accordingly; conversely, the weight of the direct trust level is increased. Finally, the operator's trust score is calculated using the formula: Comprehensive Trust Score = ω(S) * Direct Trust Level + [1 - ω(S)] * Average Compliance Rate. Here, ω(S) is the weighting function, which is negatively correlated with the stability coefficient S. Other implementation methods can also be used in other embodiments, which are not limited here.

[0052] It should be noted that the operator trust score in this application is a dynamic quantitative indicator describing the overall trustworthiness of the current operator. It deeply integrates dual information representing the operator's recent performance and the benchmark level of the group in the position, and intelligently responds to fluctuations in operator performance through a stability coefficient mechanism. The trust score is used to provide real-time and adaptive core decision-making basis for the edge computing-based drug safety monitoring system, which facilitates the automatic triggering of differentiated control strategies.

[0053] In step 105, the trust score is compared with a preset trust threshold. If the trust score is lower than the trust threshold, the operator's high-risk drug operation privileges are locked, and an alarm notification is generated and sent to the edge monitoring terminal.

[0054] In some embodiments, locking the operator's access to high-risk medications can be achieved through the following steps: The control logic module immediately generates a control command to lock permissions. The locking command is sent to all smart medicine cabinets and storage area nodes currently used by the operator; Upon receiving the control command, the edge computing unit of the medicine cabinet verifies the signature and immediately disables the operator's access permissions for high-risk medicines in the local permission list.

[0055] In specific implementation, the edge computing unit of the medicine cabinet receives the control command, verifies the signature, and immediately disables the operator's access permission for high-risk medicines in the local permission list. This can be achieved in the following way: after receiving the command, the local edge computing unit of each medicine cabinet first verifies the digital signature of the command to ensure that it comes from a legitimate control center. After successful verification, it immediately marks the corresponding permission of the target operator as disabled in the permission list of its local embedded database. Other embodiments may also use other methods to achieve this, which are not limited here.

[0056] It should be noted that, to ensure persistence and auditability, after the permission lock is executed, the medicine cabinet node will generate a confirmation receipt that the permission lock has been executed. This receipt, together with the original lock command, will be submitted to the blockchain network as a new special transaction for evidence storage. This permanently records the occurrence, source, and execution result of this control event on the operation certificate chain, realizing the non-repudiation of the control action itself and the synchronization of the global state.

[0057] In some embodiments, generating an alarm notification and sending it to the edge-side monitoring terminal can be achieved through the following steps: The hierarchical alarm notification is automatically assembled through the control logic module; The alarm notifications are sent in parallel to the preset edge-side monitoring terminals; The monitoring terminal will lock and issue an alarm on the human-machine interface of the specific medicine cabinet where the access is locked.

[0058] In specific implementation, the control logic module can automatically assemble graded alarm notifications in the following manner: the control logic module automatically assembles structured graded alarm notifications based on the severity of the trust score being below a threshold: for example, below the warning threshold or far below the high-risk threshold. The notification content includes at least: alarm level, operator information, current trust score, violation threshold, triggered control actions (such as locking access to the high-risk medicine cabinet area), and transaction hashes of related recent suspicious operations on the blockchain. Other embodiments may also use other methods, which are not limited here.

[0059] Furthermore, in another aspect of this application, in some embodiments, this application provides a dynamic monitoring system for drug inventory based on edge computing, referencing... Figure 4 The figure is a schematic diagram of the structure of a drug inventory dynamic monitoring system based on edge computing according to some embodiments of this application. The drug inventory dynamic monitoring system based on edge computing includes: a data acquisition module 401, a processing module 402, and an execution module 403, which are described below: The acquisition module 401 in this application is mainly used to acquire drug parameters, environmental data and operator biometrics at each smart medicine cabinet and storage area through the edge perception module, and to obtain the operator's operation actions and drug change data when operating the medicine. Processing module 402, in this application, is used to determine the operator's behavior log during drug operation based on the timestamp of the operation action and the drug change data, and to generate the operator's digital signature through the biometrics; It should be noted that the processing module 402 in this application is also used to build lightweight blockchain nodes for each smart medicine cabinet and warehouse area on the regional edge server, and package the behavior log and the digital signature onto the chain through the consensus between all blockchain nodes, thereby generating an operation certificate that is connected in chronological order and cannot be tampered with when the operator operates on the medicine. Additionally, it should be noted that the processing module 402 in this application is also used to obtain the average compliance rate of all operators, and to make a trust assessment of the operator's compliance status during operation based on the average compliance rate and the historical behavior set in the operation certificate, so as to obtain the operator's trust score. The execution module 403 in this application is mainly used to compare the trust score with a preset trust threshold. If the trust score is lower than the trust threshold, the high-risk drug operation permission of the operator is locked, and an alarm notification is generated and sent to the edge monitoring terminal.

[0060] In addition, this application also provides a computer device, the computer device including a memory and a processor, the memory storing code, and the processor being configured to acquire the code and execute the above-described edge computing-based dynamic monitoring method for drug inventory.

[0061] In some embodiments, reference Figure 5 The figure is a schematic diagram of the structure of a computer device implementing a dynamic drug inventory monitoring method based on edge computing, according to some embodiments of this application. The dynamic drug inventory monitoring method based on edge computing in the above embodiments can... Figure 5 The computer device shown is used to implement this, and the computer device includes at least one processor 501, a communication bus 502, a memory 503, and at least one communication interface 504.

[0062] Processor 501 can be a general-purpose central processing unit (CPU) or an application-specific integrated circuit (ASIC).

[0063] The communication bus 502 can be used to transmit information between the aforementioned components.

[0064] Memory 503 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CDROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile optical discs, Blu-ray discs, etc.), magnetic disks or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. Memory 503 may exist independently and be connected to processor 501 via communication bus 502. Memory 503 may also be integrated with processor 501.

[0065] The memory 503 stores program code for executing the scheme of this application, and its execution is controlled by the processor 501. The processor 501 executes the program code stored in the memory 503. The program code may include one or more software modules. The method used in the above embodiments can be implemented by the processor 501 and one or more software modules in the program code in the memory 503.

[0066] Communication interface 504 uses any transceiver-like device to communicate with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area networks (WLAN), etc.

[0067] In a specific implementation, as one example, a computer device may include multiple processors, each of which may be a single-core (single CPU) processor or a multi-core (multi CPU) processor. Here, a processor may refer to one or more devices, circuits, and / or processing cores used to process data (e.g., computer program instructions).

[0068] The aforementioned computer device can be a general-purpose computer device or a special-purpose computer device. In specific implementations, the computer device can be a desktop computer, a portable computer, a network server, a handheld digital assistant (PDA), a mobile phone, a tablet computer, a wireless terminal device, a communication device, or an embedded device. This application does not limit the type of computer device.

[0069] In addition, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described edge computing-based dynamic monitoring method for drug inventory.

[0070] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0071] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for dynamic monitoring of drug inventory based on edge computing, characterized in that, Includes the following steps: The edge sensing module collects drug parameters, environmental data, and operator biometrics from each smart medicine cabinet and storage area, and obtains the operator's actions and drug change data when handling the drugs. Based on the timestamps of the operation actions and the drug change data, the operator's behavior log during drug operation is determined, and the operator's digital signature is generated using the biometrics. Lightweight blockchain nodes are built for each smart medicine cabinet and storage area on the regional edge server. The behavior logs and digital signatures are packaged and uploaded to the chain through the consensus between all blockchain nodes, thereby generating an unalterable operation certificate that is linked in chronological order when the operator operates on the medicine. Obtain the average compliance rate of all operators, and make a trust assessment of the operator's compliance status during operation based on the average compliance rate and the historical behavior set in the operation credentials, so as to obtain the trust score of the operator. The trust score is compared with a preset trust threshold. If the trust score is lower than the trust threshold, the operator's high-risk drug operation privileges are locked, and an alarm notification is generated and sent to the edge monitoring terminal.

2. The method as described in claim 1, characterized in that, The operator's behavior log during drug handling is determined based on the timestamp of the operation and the drug change data, specifically including: The timing sequence of the drug operator's actions to manipulate the drug is determined based on the timestamps of the aforementioned actions. The operation content of the drug operator on the drug is determined based on the drug change data; The operator's behavior log during drug handling is determined by the action sequence and the operation content.

3. The method as described in claim 1, characterized in that, Generating the operator's digital signature using the biometrics specifically includes: The biometric features are matched with a pre-built personnel feature database on the edge server to obtain a unique identity identifier for the operator. The digital signature of the operator is generated by calling the digital certificate private key pre-installed in the security module and bound to the identity identifier.

4. The method as described in claim 1, characterized in that, Building lightweight blockchain nodes for each smart medicine cabinet and storage area on the regional edge server specifically includes: Configure all smart medicine cabinets and edge servers in the drug warehouse as peer nodes of the blockchain network; Each smart medicine cabinet and storage area edge server is assigned a unique, fixed network identifier through the internal local area network; Configure all network identifiers to the listening ports of the corresponding blockchain protocol stack; All peer nodes are pre-loaded into the configuration file of each edge server, ensuring that each node can learn about other legitimate peer nodes through the listening port when it starts up, thereby obtaining multiple blockchain nodes.

5. The method as described in claim 1, characterized in that, The behavior log and digital signature are packaged and uploaded to the blockchain through consensus among all blockchain nodes, thereby generating an immutable operation certificate that is linked in chronological order when the operator operates on the medicine. Specifically, this includes: Determine the initiating node of the operator during this drug operation from all blockchain nodes; The initiating node stores the record of a single drug operation into a digitally signed data packet in the blockchain to obtain a transaction data packet; The transaction data packet is broadcast to a blockchain network consisting of peer nodes from all medicine cabinets and storage areas; When any peer node receives the transaction data packet, it performs consensus verification on the transaction data packet, and then puts the verified transaction data packet into the transaction pool to be packaged for caching. When the number of transaction data packets in the transaction pool reaches a threshold, the current accounting node is selected based on the trust consensus among the various blockchain nodes. The ledger node selects multiple transaction data packets from the transaction pool, packages them into a new block, and sets the time for evidence storage. The new block is verified across the entire network. Each blockchain node appends the verified new block to the end of its own blockchain, resulting in an operation credential that is linked in chronological order and cannot be tampered with.

6. The method as described in claim 1, characterized in that, Trust assessment of the operator's compliance during operation is performed based on the average compliance rate and the historical behavior set in the operation credentials, resulting in the operator's trust score, which specifically includes: Determine the set of historical behaviors in the operation voucher; Based on the behavior logs and operation times in the historical behavior set, a time-sensitive correlation is performed on the operator's historical compliance status to obtain the direct trust level of the operator's compliance status during operation; The operator's trust score is determined based on the direct trust level and the average compliance rate.

7. The method as described in claim 1, characterized in that, Locking the operator's access to high-risk medications specifically includes: The control logic module immediately generates a control command to lock permissions. The locking command is sent to all smart medicine cabinets and storage area nodes currently used by the operator; Upon receiving the control command, the edge computing unit of the medicine cabinet verifies the signature and immediately disables the operator's access permissions for high-risk medicines in the local permission list.

8. A dynamic monitoring system for drug inventory based on edge computing, characterized in that, include: The data acquisition module is used to collect drug parameters, environmental data, and operator biometrics from each smart medicine cabinet and storage area through the edge sensing module, and to obtain the operator's actions and drug change data when handling the drugs. The processing module is used to determine the operator's behavior log during drug operation based on the timestamp of the operation and the drug change data, and to generate the operator's digital signature through the biometrics; The processing module is also used to build lightweight blockchain nodes for each smart medicine cabinet and warehouse area on the regional edge server, and package the behavior log and the digital signature onto the chain through the consensus between all blockchain nodes, thereby generating an operation certificate that is connected in chronological order and cannot be tampered with when the operator operates on the medicine. The processing module is also used to obtain the average compliance rate of all operators, and to make a trust assessment of the operator's compliance status during operation based on the average compliance rate and the historical behavior set in the operation certificate, so as to obtain the operator's trust score. The execution module is used to compare the trust score with a preset trust threshold. If the trust score is lower than the trust threshold, the operator's high-risk drug operation privileges are locked, and an alarm notification is generated and sent to the edge monitoring terminal.

9. A computer device, characterized in that, The computer device includes a memory and a processor, the memory storing code, and the processor being configured to retrieve the code and execute the edge computing-based dynamic monitoring method for drug inventory as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the drug inventory dynamic monitoring method based on edge computing as described in any one of claims 1 to 7.

Images