Transfusion information management system

Abstract

The invention discloses an infusion information management system, which relates to the technical field of medical informatization equipment and comprises a task information access module, a label data generation module, a dual-channel acquisition module, a context association processing module, a synchronous locking control module, a transaction state judgment module and an execution record collection module. According to the method, a cross time locking domain and a transaction serialization mechanism are introduced into the system, so that unified constraint of multi-terminal data in a time domain and a logic domain is realized; meanwhile, scanning, position and equipment identity information are subjected to multi-dimensional binding through a context association structure, atomic-scale correspondence of an infusion label and a patient identifier at the infusion execution moment is achieved, and false matching caused by time sequence drift or concurrent operation is avoided; according to the invention, the safety of infusion behaviors and the consistency of system-level information can be obviously improved.

Description

Technical Field

[0001] This invention relates to the field of medical information equipment technology, and more specifically to an infusion information management system. Background Technology

[0002] Intravenous infusion therapy, as one of the most common routes of drug administration in clinical treatment, directly impacts the accuracy of patient medication and the level of hospital nursing management. With the development of medical information technology and intelligent nursing techniques, infusion information management systems are gradually replacing traditional manual verification and rounds, achieving digital and traceable management of the entire infusion process. These systems typically achieve closed-loop control from prescription generation, medication dispensing, infusion execution to abnormal alarms through data interconnection between electronic medical records (EHR), prescription order systems (CPOE), and pharmacy management systems (PIS).

[0003] Existing infusion information management systems generally employ a dual-verification mechanism based on the Internet of Things (IoT) and barcode recognition, confirming the infusion recipient by scanning and matching the patient's wristband and infusion bag label. Some systems introduce AI recognition, weight sensing, or visual recognition methods to monitor infusion drip rate and remaining fluid volume. For example, CN119400351A proposes linking the doctor's appointment list with the nurse station's infusion order, combining skin testing, medication dispensing, and fluid preparation processes to achieve full-process management of infusion; CN119792717A utilizes weight sensing technology to monitor the drip rate and remaining time of the infusion bottle; CN120132124A combines blockchain and wearable devices to achieve intelligent adjustment of infusion plans and risk warnings; patents such as CN120088739A and CN119560098A further utilize visual recognition or artificial intelligence models to achieve infusion status monitoring. These technologies have made significant progress in improving the accuracy and efficiency of infusion monitoring.

[0004] However, in the infusion label verification and execution process, existing systems generally rely on an "event chain" information flow model: the electronic medical record system generates a prescription, the pharmacy prints the infusion bag label (second identifier), and the nursing station verifies it against the patient's wristband (first identifier) ​​before performing the infusion preparation and infusion. This chain involves multiple independent terminals (doctor's end, pharmacy end, nursing station end, bedside barcode scanner, etc.), and the label generation time, affixing time, barcode confirmation time, and pump start time at each stage are recorded by different devices. The system cannot ensure a unique correspondence between the patient identifier and the infusion bag identifier at the same moment. Especially in scenarios with multiple patients, different labels may be incorrectly replaced or reused within a short period of time, resulting in the system recording a successful match when a physical mismatch has occurred. In addition, with busy clinical work and frequent alarm prompts, medical staff are prone to omitting verification or making mistakes in the process, causing potential medication risks and infusion safety hazards. Although existing systems attempt to verify through repeated scanning and alarm prompts, they are prone to "alarm fatigue" in high-load environments, and limited process optimization or rule adjustments cannot eliminate potential errors within this time window. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention discloses an infusion information management system, aiming to solve the problems mentioned in the background technology.

[0006] To achieve the above-mentioned technical effects, the present invention adopts the following technical solution: An infusion information management system, comprising: The task information access module is used to extract prescription task packages from the medical information system, parse medical order parameters, patient identifiers and drug attributes, and form the initial task structure. The tag data generation module is used to generate an infusion tag information set, including local time domain parameters, tag identification codes, and cross-node random salt values, based on the task initial structure. The dual-channel acquisition module is used to acquire the wristband identifier, bedside node identifier, and local device clock at the patient end, as well as the infusion bag identifier, pump device identification number, and execution node clock at the infusion end, and generate a dual-channel acquisition vector. The context association processing module is used to receive the dual-channel acquisition vector, extract the spatial location signal, operation sequence number and device identity set, and generate a context association structure. The synchronous locking control module is used to establish a cross-locking domain based on the infusion label information set and the context association structure, and to perform dual-end data consistency verification through the time window constraint of the cross-locking domain. The transaction status determination module is used to output binding authorization instructions based on the verification results, and to isolate tasks when tag conflicts or concurrent interference are detected. The execution record collection module is used to collect binding tokens and cross-locking domain records after the infusion task is completed, generate a traceable transaction record chain, and store it in the central database.

[0007] Preferably, the generation process of the tag data generation module includes: Obtain prescription time parameters, dispensing time parameters, and execution node local clock parameters from the task information access module, and construct a time parameter set; Extract the corresponding node device identifier and calculate the node clock offset to form the node sequence parameter; Generate cross-node random salt values ​​based on a joint hash function of node sequence parameters and time parameter sets; The tag identity code is obtained by performing identity encoding operation based on the task identifier code and cross-node random salt value; The time parameter set, tag identification code, and cross-node random salt value are combined according to a preset sequence to generate an infusion tag information set.

[0008] Preferably, the dual-channel acquisition module includes a first acquisition submodule and a second acquisition submodule; the first acquisition submodule is used to trigger an acquisition event based on the wristband identifier at the patient end, record the wristband code, the patient end spatial coordinate group and the local clock count value, and generate a first acquisition structure unit; the second acquisition submodule is used to trigger an acquisition event based on the infusion bag identifier at the infusion execution end, record the infusion bag code, the pump device identification number and the local timing sequence, and generate a second acquisition structure unit. The first acquisition structure unit and the second acquisition structure unit establish a cross-channel correspondence through the acquisition event sequence number. When the correspondence is formed, the time vector difference is calculated for the timing parameters of the two units. The time vector difference is combined with the spatial coordinate group and the pump device identification number to form an acquisition consistency mapping set.

[0009] Preferably, the extraction process of the context association processing module includes: When receiving dual-channel acquisition vectors, the wristband recognition field, patient position vector and patient device clock parameter in the first acquisition structure unit are parsed to construct a patient spatiotemporal segment; The infusion bag identification field, the pump device identification number at the execution end, and the local clock parameter at the execution end in the second acquisition structure unit are analyzed to construct the spatiotemporal segment of the execution end. The spatiotemporal segments of the patient end and the spatiotemporal segments of the execution end are compared sequentially according to the time parameter sequence to generate an operation sequence chain; A location node correspondence matrix is ​​established based on the location vector and the pump equipment identifier, and the location node correspondence matrix is ​​associated and mapped with the operation sequence chain; After mapping is complete, the time parameter sequence, the set of position vectors, and the matrix corresponding to the position nodes are encapsulated into a hierarchical context association structure and output to the synchronization locking control module.

[0010] Preferably, when establishing the location node correspondence matrix, the context association processing module processes the patient-end location vector in the first acquisition structure unit. The position vector of the execution end device in the second acquisition structure unit Perform spatiotemporal correlation calculations to obtain node position constraint coefficients. The formula expression is: in, The patient's position vector; For the position vector of the execution end device; The Euclidean distance between the position vectors of the two ends; This is the distance attenuation coefficient; For patient-side time parameters; For execution time parameters; Let be a time alignment function, and the value of the time alignment function satisfies: in The time alignment tolerance threshold is used; the node position constraint coefficient is obtained. Afterwards, The device node dimension of the matrix corresponding to the location node is filled in, and the rows and columns of the matrix corresponding to the location node are synchronously adjusted based on the temporal arrangement of the operation sequence chain to ensure that the resulting matrix has a sequence structure consistent with the operation sequence chain; finally, the matrix corresponding to the location node containing the constraint coefficients is written into the spatial fragment layer of the context association structure.

[0011] Preferably, the cross-locking domain construction process of the synchronization locking control module includes: After receiving the local time domain parameters and context association structure of the infusion tag information set, the entire locked time period is divided into multiple continuous time grids according to a preset time scale. Write the tag-end time parameter and the execution-end time parameter into each time grid, and perform sequential detection on the time jumps between grids; When the time jump variable of any adjacent raster exceeds a preset threshold, the corresponding raster is marked as a conflict raster and excluded from the cross-locking domain; Perform two-way data consistency checks within contiguous segments that do not contain conflicting graticles.

[0012] Preferably, the consistency verification process of the synchronization locking control module includes: Tag-side time series Time series of the execution end Calculate the sequence difference components and with the sequence difference components The consistency constraint parameter is used; the formula for calculating the sequence difference component is: in, For the first tag information set A time parameter; For the first context-related structure A time parameter; To determine the number of comparison points within the locked domain; Sequence difference components With preset threshold Compare; when When the locked domain is marked as a verifiable domain, a consistency comparison between the two ends of the node is performed within that verifiable domain; when When this occurs, the lock rejection logic is triggered and the corresponding task segment is isolated.

[0013] Preferably, the working process of the transaction status determination module includes: When receiving the verification output of the cross-locking domain, the tag time chain, device node sequence and spatial segment sequence in the verification output are segmented to form the corresponding transaction segment set; Configuration identification is performed on the time series direction, node sequence continuity and label sequence monotonicity within the transaction fragment set, and detected sequence reversals, node jumps or label re-entries are marked as conflict configurations. According to the type and number of the conflict configuration, the corresponding branch of the state decision tree is input, wherein a timing re-examination flag is written for a transaction segment containing a single sequence inversion configuration, a node locking flag is written for a transaction segment containing a node jump configuration, and a label isolation flag is written for a transaction segment containing a label reentry configuration. After the above-mentioned markings are formed, the overall marking distribution of the transaction fragment set is summarized. When the summarization result only contains the timing re-examination marking, the binding authorization instruction is output. When the summarization result contains the node locking marking or the tag isolation marking, the task isolation logic is entered and the subsequent processing flow is interrupted.

[0014] Preferably, the process of determining the node jump configuration in the conflict configuration includes: The device node sequence in the received transaction segment is retrieved from the preset node topology graph, and the topology weight corresponding to each device node is retrieved. The topology weight includes the path cost between nodes, the lower bound of the node switching time, and the node functional relationship parameter. Perform path continuity analysis on the topology weights of adjacent device nodes and calculate the node switching cost vector. ,in, This represents the path cost from node i to node j. This represents the minimum time difference for node switching. A parameter representing the degree of association of node functions; The cost vector is compared with a preset valid switching domain, and the following conditions are met. The node switching is marked as a node jump configuration, and the node jump configuration is written into the structure tag table of the transaction fragment.

[0015] Preferably, the execution record collection module includes a record construction unit for constructing a phased transaction record structure after the infusion task termination event is triggered. The record construction unit generates a transaction record chain composed of several transaction stage tuples based on the binding token and cross-locking domain records. Each transaction stage tuple includes: a stage identifier parameter representing the infusion task stage, a time vector extracted from the cross-locking domain, a token fragment extracted from the binding token, a node identity fingerprint, and a reference index of the preceding stage tuple. The time vector includes the time difference between the two ends, the locking domain reference time, and the node local clock offset. The sequence obtained by the record construction unit performing unidirectional serialization and arrangement of several transaction stage tuples based on the locking domain reference time is the transaction record chain, and the transaction record chain is written into the corresponding task record area of ​​the central database.

[0016] Based on the above technical solution, the positive and beneficial effects of the present invention are as follows: 1. This invention combines a dual-channel acquisition structure with a cross-time locking domain to integrate the tag generation time, affixing time, scanning time, and pump start time—originally recorded separately by independent devices—into the same transaction time domain for consistency verification. Any execution action triggered by any terminal must complete a bidirectional match with the corresponding transaction within the effective time window of the locking domain. Events exceeding the window will be automatically judged as abnormal input by the system. At the structural level, atomic constraints on multi-node transactions are implemented, ensuring logical synchronization and consistency of data at each time point in the infusion process. This avoids false matches caused by clock drift or recording delays between different devices, resolving mismatches and time reversal issues in infusion tags across multiple terminals.

[0017] 2. This invention effectively addresses the issue of overlapping use of different labels within the same area or time period. For example, when a nurse performs multiple labeling or scanning actions consecutively in a multi-patient scenario, the system can automatically identify potential mismatch events by comparing the operation sequence number with the location information and block the matching confirmation signal. Simultaneously, combined with the real-time logic verification of the transaction status determination module, the system automatically freezes the transaction and prompts for re-verification when it detects that the operation deviates from the normal context path. This association mechanism establishes a self-verification channel for human-machine collaboration at the behavioral level, enabling the system to maintain high matching accuracy and error resistance even under high-intensity nursing work environments, reducing potential medication risks and infusion safety hazards caused by human error or concurrent operations.

[0018] 3. In this invention, each binding token contains a cross-locking domain identifier, an operation context summary, and a transaction sequence number, logically corresponding to a unique infusion event unit. After generating the binding token, the system maps it to the infusion pump execution data and writes it to the central database in real time to form a continuous record chain. When abnormal operations or system delays occur, the transaction chain can be reverse-analyzed to locate the specific device node, operation time, and responsible terminal, thereby achieving accurate tracking and verification of abnormal events. This not only enhances the system's security control capabilities but also provides verifiable execution credentials for the entire infusion process. In high-concurrency clinical environments, this structure effectively prevents record breaks or event overwriting, improving the overall reliability and transparency of the infusion management system. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort, wherein: Figure 1 This is a schematic diagram of the steps of the present invention; Figure 2 This is a schematic diagram illustrating the principle of the context association processing module of the present invention; Figure 3 This is a schematic diagram illustrating the principle of constructing the cross-locking domain in this invention; Figure 4 This is a schematic diagram illustrating the working principle of the transaction status determination module of the present invention; The diagram is labeled as follows: 100, Task Information Access Module; 200, Tag Data Generation Module; 300, Dual-Channel Acquisition Module; 400, Context Association Processing Module; 500, Synchronization Lock Control Module; 600, Transaction Status Determination Module; 700, Execution Record Collection Module. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0021] The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0022] Unless otherwise defined, all techniques and scientific methods used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The descriptions herein are for the purpose of illustrating particular embodiments only and are not intended to limit the invention. The terms "and / or" as used herein include any and all combinations of one or more of the associated listed items.

[0023] Example 1: The infusion information management system is deployed in the comprehensive ward environment of a tertiary hospital. The system consists of a nurse station host, multiple bedside infusion monitoring terminals in the ward, a pharmacy label printing terminal, a master data server, and a time synchronization node.

[0024] During the system deployment phase, the hospital information center configures a master control terminal with an independent transaction clock at the nurses' station. This terminal installs the complete software core of this invention, used to perform core logic such as task data construction, context association processing, synchronization lock control, and transaction status determination. The printing terminal on the pharmacy side connects to the main server via a local area network, and the server distributes the time parameters and tag identification codes from the task data units to it. An infusion monitoring terminal is installed at each patient bedside. This terminal integrates an RFID reader, a QR code scanning component, a local clock module, and a pump control interface, used to perform the first and second data acquisition processes and dual-end data upload.

[0025] In actual operation, after a doctor issues an infusion order in the electronic medical record, the order is pushed to the task data construction module of the HIS system in the form of structured data. The module extracts the order fields, including drug type, dosage, administration time, patient identification, ward and bed information, and generates a task timestamp and transaction sequence number based on the transaction clock of the nurse station's main control terminal. This forms task data, which is then transmitted to the pharmacy printing terminal. The label generation and processing module generates an infusion label information set containing local time domain parameters, label identification codes, and random salt values, and prints the infusion bag label accordingly. The key difference here compared to traditional systems is that there is a one-to-one correspondence between the label identification code and the transaction sequence number of the task data unit. A binding time basis is established from the moment the label is generated, rather than relying on subsequent scanning actions to establish the association.

[0026] Subsequently, the IV bag is sent to the nurses' station for infusion preparation. At this point, the first data acquisition submodule has not yet been activated because the first data acquisition pertains to the patient. After the label is affixed at the nurses' station, the system has not yet established a binding relationship and will not consider the IV bag as having been assigned to a specific patient. Before the infusion is administered, the nurse brings the IV bag to the patient's bedside. Upon receiving the event of the IV bag approaching, the bedside terminal automatically initiates the second data acquisition process, reading the IV bag's identification code, the pump device number, and the local clock time of the bedside terminal, and immediately uploading it to the main control terminal at the nurses' station.

[0027] Meanwhile, in the first data acquisition process, the bedside terminal obtains the patient's identifier by scanning the patient's wristband and simultaneously reads the local clock time of the patient's terminal. Both acquisition processes are triggered by the bedside terminal, but belong to different data paths. After the system uploads these two types of acquired data, the context association processing module 400 parses the two acquisition data packets and extracts key context elements, including but not limited to the patient's wristband ID, infusion bag tag code, acquisition time, device number, bed location, and the triggering order of the two acquisition actions. The module generates a context association structure based on the temporal and spatial relationships between the data fields. This structure is not a simple binary match, but a multi-dimensional structure with operation sequence indicators and device link indicators, used to determine the rationality of the operation sequence during subsequent locking processes.

[0028] During the synchronization locking control phase, the system starts with the local time domain parameters in the tag information set, mapping the timestamps of the two acquired data sets to a unified transaction clock reference domain. By calculating the time offset between the two and combining it with the operation sequence field in the context association structure, a cross-locking domain is established. Essentially, the cross-locking domain is a combination of time domains containing multiple constraints, used to determine whether two acquisition actions form a valid binding within a reasonable time window. This time window is not a fixed value but is given based on the transaction sequence number in the task data unit, the tag generation time, and the hospital's internal time synchronization node. The offset value is calculated dynamically. The system outputs a binding token only if the data from both ends converge in the time domain; otherwise, the system determines that the data is in an unbound state and does not allow the infusion operation to continue.

[0029] After the binding token is generated, the transaction status determination module 600 further judges the current scenario, such as whether there is a tag conflict, whether there is a multi-patient mirror scenario, or whether there is concurrent interference between adjacent beds. If concurrent interference exists, the module will activate task isolation logic to block the interaction path between the current infusion task and other tasks, requiring the nurse to re-execute part of the data collection process. It should be noted that traditional systems rely only on the scanning behavior itself, while this invention is based on a comprehensive judgment of temporal structure, context structure, and multi-node logic to prevent mismatches from the mechanism.

[0030] After the infusion task is completed, the execution record collection module 700 receives the binding token and cross-locking domain records, and generates staged transaction record units. Each stage record unit contains a time-series vector, node identity fingerprint, task stage identifier, binding token fragment, and reference index of the previous stage. The system concatenates multiple stage record tuples to construct a self-consistent transaction record chain, rather than a traditional log. This record chain is written to the central database, allowing the actual execution path of the task to be reconstructed, including the nurse's operation sequence, label application process, bedside collection process, and locking domain convergence status.

[0031] In this embodiment, due to the introduction of local time sources at nodes through the dual-channel acquisition mechanism, the introduction of transaction sequence numbers and tag time parameters through the task construction module, and the introduction of cross-locking domains through the synchronization locking module, the system completely avoids the mismatch windows generated by traditional event chain systems during execution. This approach overcomes a long-standing technical deficiency in the industry, namely the misconception that scanning and matching is sufficient to guarantee a unique correspondence between the patient's identity and the infusion bag's identity. In reality, scanning only provides point-based data and cannot cover the entire task cycle. This invention, by establishing task-level atomic binding at the time-series level, fundamentally eliminates the system's logical dependence on single-point actions.

[0032] In Example 2, the invention is deployed in the emergency infusion area. Unlike the ward scenario in Example 1, the core feature of this scenario is that the infusion execution end is not fixed at the bedside, but rather uses a mobile infusion management cart as the main operating platform. This cart is uniformly configured by the hospital information center, and each cart is equipped with a mobile terminal, including an RFID reader / writer module, a QR code scanning module, a Bluetooth pump interface, a local high-precision clock module, and an edge computing unit supporting independent data caching. The other end of the system still consists of the nurse station host and the central database, but the task data construction module and the synchronization lock control module 500 are both integrated into the bed server to handle frequent patient movement and task switching in the emergency scenario.

[0033] After the emergency room doctor issues the intravenous infusion order, the order data is pushed to the bed server in structured form. The task data construction module then parses and generates the task time domain. In this embodiment, due to the higher concurrency and uncertainty of emergency actions, the task data construction module injects an additional "mobile execution channel identifier" when generating task data units. This identifier records whether the infusion task might be executed by a mobile cart. Simultaneously, a "transferable transaction index" is added to the task data unit. This index allows the system to automatically correct the context association when the patient's location changes.

[0034] Upon receiving the task data unit, the label generation and processing module on the pharmacy side generates a label information set containing local time domain parameters, label identification codes, and cross-node random salt values, and prints the infusion bag label. Similar to Embodiment 1, this label has a binding transaction basis from the moment of generation. However, in emergency scenarios, the label generation and delivery process is shorter, and the difference between the label and the patient's arrival time is more unpredictable. Therefore, this embodiment particularly emphasizes the two-factor structure composed of the local time domain parameters and random salt values ​​in the label, so that the subsequent locking process does not rely on just one set of time fields.

[0035] After the nurse places the IV bag onto the tray above the mobile cart, the cart terminal automatically completes the initialization of the second data acquisition module. Since the cart moves between different beds, its local clock cannot fully rely on the main network for synchronization. Therefore, in addition to recording the IV bag tag code, pump device number, and cart local time, the second data acquisition also records an "instantaneous clock offset." This offset is obtained by a short-range time sampling between the cart and the nurse station host when the cart passes through the nurse station's Wi-Fi coverage area. This is not continuous synchronization, but it is sufficient for time domain compensation during the locking phase.

[0036] Meanwhile, the initial data collection process becomes more complex in emergency situations, as patients may have just arrived by ambulance or have been temporarily placed in the resuscitation area. Therefore, in this embodiment, the first data collection submodule operates differently from the "fixed bedside scanning" in Embodiment 1. Instead, a mobile cart automatically initiates a "patient segment scanning mode" before contacting the patient. When the cart enters a bed area (determined via Bluetooth positioning or BLE beacon), the system activates the wristband scanning component. Upon scanning the patient's wristband ID, it records the location fingerprint and local time of that area, forming the first data collection data which is then uploaded to the bed server. This allows the system to obtain the patient's dynamic location context, rather than simply acquiring an "identity number" as in traditional systems.

[0037] After receiving two sets of collected data, the context association processing module 400 converts the mobile cart's location fingerprint, scanning order, wristband ID, tag identification code, clock offset, and case area number into structured context elements. The association processing in this embodiment emphasizes the generation of spatial behavior chains; that is, the system not only identifies the content of the two types of collection actions but also their movement trajectories and area information. For example, a typical fixed bedside system would not consider the behavior information of "a nurse pushing a cart from area A to area B," but in an emergency scenario, it is necessary to infer whether the collection occurred in a reasonable sequence through location fingerprints and action order. The association module combines this information into a context association structure, which can be regarded as a "spatial-temporal composite descriptor" used to describe the relationship between the cart, the patient, and the infusion bag.

[0038] During the synchronous locking control process, the system maps all time domains to a unified transaction clock based on the local time domain at the time of tag generation and the time data of the two acquisition actions through a clock offset compensation mechanism. At this time, the system determines whether the second acquisition occurs on a reasonable path after the first acquisition based on the context association structure; that is, the cart should pass through the patient area before performing the infusion bag proximity scan, not the other way around. Subsequently, the system calculates whether the cross-locking domain has converged. This convergence condition depends not only on the time window but also on the continuity of the regional fingerprint. For example, if the cart suddenly jumps to a distant area to perform the second acquisition after acquiring the patient's wristband, the locking domain will be determined to be inconsistent with the path inference model.

[0039] The transaction status determination module 600 generates a binding token based on the locking result and adds a "movement channel signature segment" unique to this embodiment to record that the binding event was formed in a mobile environment. When the system detects multiple cross-pairing attempts between the same cart and different patient wristbands within a short period of time, the module automatically triggers the concurrent interference isolation logic, freezing all incomplete binding requests in the cart's current buffer and prompting the nurse to re-execute the data collection. This mechanism represents a further breakthrough from the biases of traditional technologies, as previous systems were prone to incorrect binding due to disordered scanning order in emergency scenarios. This invention uses the context path as the binding judgment basis, freeing the system from relying on nurses to maintain a strict scanning order in a high-pressure environment.

[0040] After the infusion process is completed, the mobile cart reports the stage execution events in its buffer to the execution record collection module 700. Since the cart often operates in areas near the edge of Wi-Fi signal coverage, to ensure the continuity of the transaction record chain, this embodiment allows stage records to be temporarily stored when the network is disconnected and then merged and written into the database after network reconnection. The collection module constructs the transaction record chain according to the time vector of the stage events, the area fingerprint, and the binding token fragment, enabling the hospital to see a clear operational trajectory during subsequent traceability. This includes the entire process of when a tag is generated for a particular infusion bag, when it is placed on the cart, when the cart enters which area, when the data collection is completed, and when the binding is established, rather than a fragmented, single-point record.

[0041] To facilitate a deeper understanding of the technology in this invention, a detailed description of an infusion information management system disclosed in the embodiments of this application is provided below. Please refer to [link / reference]. Figure 1 The system framework diagram shown indicates that this system includes: The task information access module 100 is used to extract prescription task packages from the medical information system, parse medical order parameters, patient identifiers and drug attributes to form an initial task structure. It should be noted that the "prescription task package" in this application is different from the medical order list data provided by the existing HIS. This task package does not simply contain prescription text, but rather the system encapsulates the prescription content, prescription status, execution department affiliation, medical order creation timestamp and auxiliary fields required for internal system scheduling into unitized inputs during the access phase, enabling this system to process infusion-related information based on a unified structure.

[0042] Upon receiving a prescription task package, the module does not directly write the fields to the database. Instead, it rearranges and semantically unifies the fields according to the system's internal transaction chain specifications. The initial task structure is not a mirror copy of the original fields; rather, it contains logical data units that include standardized patient identity indexes, drug attribute tags, prescription execution constraints, and internal time parameters. This structure is not intended for doctors to view but is instead read by subsequent tag generation, context association, and locking control modules to construct time-related transaction domains.

[0043] During field processing, the task information access module 100 also calibrates and reorganizes time fields from different sources. For example, the time of medical order entry is usually affected by the local clock of the doctor's device, rather than the system time, so using it directly will lead to deviations in the subsequent establishment of locking domains. This module generates a unified "initial time parameter" for all tasks based on the system master clock. This parameter is used to mark the time starting point of the task in the transaction chain of this system. Those skilled in the art will understand that without this additional time parameter, the clock data output by the subsequent dual-channel information acquisition module will not be able to be correlated with the medical order time, thus affecting the timing judgment of the cross-locking domain.

[0044] The task information access module 100 also generates an internal "transaction sequence number" when constructing the initial task structure. It should be noted that the transaction sequence number in this application differs from the prescription number or serial number in the HIS. It is a single transaction identifier used internally by this system to identify infusion tasks, possessing cross-node access, cross-terminal identification, and cross-stage tracking capabilities. This sequence number contains internal fields used to distinguish different infusion tasks for the same patient, thereby avoiding the problems of prescription number conflicts or field reuse that occur in traditional HIS under high concurrency conditions.

[0045] Regarding data output, the task information access module 100 sends the initial task structure to the system cache, enabling subsequent modules to directly call it without HIS interaction delays. The structure includes the patient master index, drug attribute tags, execution time parameters, transaction sequence number, and unified initial time parameters, etc. These fields provide the basic semantics for subsequent tag generation, dual-end data acquisition, context association, and lock control.

[0046] The tag data generation module 200 is used to generate an infusion tag information set including local time domain parameters, tag identification codes and cross-node random salt values ​​based on the task initial structure; Because infusion scenarios involve multiple independent devices such as prescription systems, dispensing centers, bedside nodes, and infusion pumps, and these devices often lack a fully synchronized unified clock or a single secure node that can provide reliable randomness, if tag generation still relies on traditional methods that depend on a single timestamp or a single random seed, it is highly susceptible to misidentification under conditions of concurrent tasks, device drift, and tag conflicts, and may even cause conflicting tags to be incorrectly bound to patients or infusion bags. Therefore, the tag data generation module 200 in this application is designed to deliberately incorporate multiple time sources, multiple device identities, and a cross-node entropy mixture into the tag generation process, so that the final infusion tag is not just a record mark, but the foundational root data for subsequent two-end consistency verification, cross-node locking windows, and transaction chain tracing.

[0047] When the module starts working, it first extracts the prescription time and infusion preparation time from the initial task structure. These are not simple timestamps, but rather time points with medical action semantics. It's important to note that the "prescription time" and "infusion preparation time" here are not equivalent to the common concepts of medical order entry time or printing time in existing medical systems. Instead, they more specifically point to the actual node activated in the medical order execution chain, used to locate the task's relative position in the entire process in subsequent stages. Simultaneously, the module reads the local clock of the currently executing node. The emphasis on "local clock" is because medical field equipment typically lacks a strict time synchronization mechanism. Clock drift between different brands of infusion pumps, bedside mobile terminals, and centralized infusion preparation workstations is a continuous phenomenon. Therefore, it's necessary to proactively incorporate this difference into the tag generation logic, rather than passively accepting errors.

[0048] To ensure the usability of time parameters in a distributed system, the module performs an offset calculation on the time readings of each participating node, generating a clock offset value for each node relative to a reference time. The reference time can be the prescription time or provided by a clock source in the system's backend; this is not strictly limited. Different hospital IT architectures may even use gateway servers to provide local time synchronization, as long as the relative offset value can be reconstructed within a controllable time window. The goal is not to establish a high-precision absolute timescale, but rather to allow the system to clearly define the time tendency of each node in the transaction chain, thereby facilitating subsequent replay analysis and task conflict detection.

[0049] These node information include not only offset values ​​but also device identifiers. It should be noted that the device identifier in this application is not a simple serial number or MAC address, but rather an identity fingerprint that can be bound to the device's trusted execution environment, providing unforgeable input values ​​in joint entropy calculation and identity encoding. If implementation conditions permit, this identifier can be a public key fingerprint or a unique identifier for an embedded security module; the specific method used depends on the implementation environment and is not limited thereto.

[0050] After the time and node parameters are organized, the system mixes these parameters with several random number sources from different nodes to generate a cross-node random salt value. This "cross-node" aspect is crucial for overall stability, as single-node random numbers are often affected by device performance, call frequency, and even firmware implementation. If the salt is entirely provided by one end, the unpredictability of the task tags will be completely lost if that device is attacked. Therefore, this application employs a joint hashing method, using a structure related to time, node identity, and node offset as input. This allows the salt value to exhibit multi-source entropy fusion characteristics, ensuring that the prediction or leakage of any one input is insufficient to reconstruct the entire salt value. The more unpredictable the salt value, the less likely subsequent tag identification codes are to be forged or conflicted, which is particularly important for preventing misbinding in medical scenarios.

[0051] After obtaining a random salt value across nodes, the system enters the identity encoding stage, where the task identifier and the salt value are used together in an encoding operation to generate a tag identity code. The encoding tool used here can be adjusted according to the security level. Common methods include using the system key to perform an HMAC or using an asymmetric key for digital signature, as long as the tag identity code is immutable, unforgeable, and verifiable. The identity code is not designed to encrypt the task content, but rather to provide a binding between the task and the salt, allowing any subsequent node to verify the tag's consistency without needing to know the system key.

[0052] The module ultimately combines the time parameter, identification code, and cross-node random salt into a tag information set in a pre-defined order. This order is not strictly required to be uniform; different hospitals' information systems may have different field formats. Therefore, this application does not impose format restrictions, as long as these elements are included and can be correctly parsed in the subsequent two-way verification module. Typically, a version number or checksum is appended at the end for tracking whether the tag generation algorithm has been upgraded or to verify the tag generation process during compliance audits.

[0053] Traditional methods assume that all nodes within the system have consistent time and that all tasks will not be triggered concurrently within the same second. However, these assumptions do not hold true in medical infusion scenarios: time drift of several seconds or even tens of seconds between different devices is very common; infusion tasks experience high concurrency during batch preparation or centralized patient treatment, amplifying the risk of random conflicts; more seriously, once a device's tag is maliciously replaced or a mis-scan occurs, simple tags cannot be identified in the link. By adding a "system state parameter" such as node offset, along with a "multi-source security parameter" of cross-node hybrid entropy, and binding task IDs with keys, the tags logically and naturally carry multi-node imprints. Any attempts to forge or incorrectly reuse tags will be identified in subsequent verification steps.

[0054] Since the tag information set generated by this module serves as the foundation for subsequent transaction link verification, lock window synchronization, and traceability of the execution process, it maintains a high degree of implementation freedom while ensuring security. Those skilled in the art can adjust the organization of parameters according to the number of nodes in the system, device capabilities, network protocols, and backend database structure without affecting the core idea and implementation path of the invention.

[0055] The dual-channel acquisition module 300 is used to acquire wristband identifiers, bedside node identifiers, and local device clocks at the patient end, and infusion bag identifiers, pump device identification numbers, and execution node clocks at the infusion end, generating a dual-channel acquisition vector. It should be noted that the "dual-channel acquisition vector" in this application differs from the unidirectional acquisition vectors commonly found in existing technologies. This vector not only integrates identifiers but also embeds spatiotemporal parameters to achieve dynamic consistency mapping, while existing similar vectors are often limited to static identifier acquisition and cannot effectively cope with operational timing interference or spatial drift. The specific extension dimension of the vector can be determined according to the equipment configuration of the medical institution; no limitation is imposed on this.

[0056] The dual-channel acquisition module 300 is specifically divided into a first acquisition submodule and a second acquisition submodule. The former targets the patient end, and the latter targets the infusion end. The two are linked by event sequence numbers to avoid the island effect caused by independent acquisition. For parameter extraction, the patient end mainly involves wristband identification (unique code, such as RFID serial number, used for patient identification), bedside node identification (device or location code, such as MAC address or bed coordinate group, used for positioning context), and local device clock (real-time stamp, used for timing reference). The infusion end includes infusion bag identification (barcode or QR code encoding, used for drug tracking), pump device identification number (serial number, used for device binding), and execution node clock (pump clock value, used for execution synchronization). The selection of these parameters is based on the inherent attributes of medical order execution, namely, identity authentication, spatial constraints, and temporal consistency, ensuring that acquisition is not limited to surface identification.

[0057] The first acquisition submodule triggers an acquisition event using a wristband identifier, recording the wristband code, the patient's spatial coordinate set (e.g., three-dimensional coordinates obtained through an indoor positioning system), and the local clock count, forming the first acquisition structure unit. The second acquisition submodule triggers an infusion bag identifier, recording the infusion bag code, the pump device identification number, and the local timing sequence, generating the second acquisition structure unit. The "spatial coordinate set" mentioned in this application can be selected according to the environment of the target medical institution, such as Cartesian coordinates or relative positioning coordinates. Different positioning technologies, such as UWB or BLE, have different applicable ranges, and this is not limited. For example, for UWB positioning, the coordinate set can be accurate to the centimeter level, suitable for dense wards; for BLE beacons, the coordinate set focuses more on area division, suitable for corridor layouts.

[0058] The two structural units establish a correspondence by collecting event sequence numbers (incrementing IDs used for cross-channel links), and calculate the time vector difference of timing parameters when the correspondence is formed. ,in To execute the node clock, For local device clocks, this difference quantizes the operating interval to detect potential delays or tampering; subsequently, Δt is compared with the spatial coordinate set S = (x, y, z) and the pump unit identification number. Integrate into a consistent data collection mapping set This mapping set can be viewed as a vector form. The hash function can be used for privacy protection. The aforementioned optical feature parameters can be timestamp offsets or coordinate deviations, etc., which can be determined according to the actual situation.

[0059] The trigger condition is defined as the detection of the identification scanning action. For example, the first submodule activates acquisition when the wristband RFID signal strength exceeds a threshold to avoid accidental touches; the second submodule is similar, starting when the QR code on the infusion bag is successfully decoded. If there is multi-source interference in the environment, such as in a multi-person operation scenario, additional conditions such as signal purity checks can be added to the trigger. In terms of action description, as a possible implementation, the operation of this module can be expanded as follows: Medical staff first scan the wristband at the patient's bedside using a device with an integrated reader / writer. The first submodule immediately captures the wristband code (e.g., "WRB-00123"), spatial coordinate group (e.g., (10.5, 20.3, 1.2)), and local clock (e.g., Unix stamp 1728901234), and encapsulates it into a structural unit; then, it moves to the infusion pump, scans the bag identification, and the second submodule records the corresponding data; after the two are linked by a serial number (e.g., SEQ-1001), Δt is calculated and a mapping set is constructed. If Δt exceeds a preset window (e.g., 30 seconds), it is marked as abnormal for downstream isolation.

[0060] Where the time vector difference formula (Absolute value is taken to ignore direction), the parameter means to quantify the synchronization degree between the two ends. If Δt is too large, it indicates clock drift or human delay; the spatial coordinate set S is used to verify physical proximity, such as calculating Euclidean distance. If d > the threshold (e.g., 5 meters), the mapping set becomes invalid. Although this processing is based on basic vector operations, it effectively integrates multi-modal data, avoiding the limitations of simple identifier matching. Key parts can be implemented via scripts to calculate time differences, such as using a time library to calculate the total second difference and comparing it to a threshold to set a consistency flag.

[0061] In practice, existing technical solutions often assume that single-channel acquisition is sufficient to cover medical order execution, ignoring temporal and spatial dynamics. This makes them susceptible to concurrent interference or forgery. For example, traditional systems rely solely on wristband ID matching, which often leads to confusion across multiple beds. The new solution differs in that it introduces dual-channel parallelism and consistent mapping. It enforces multi-dimensional verification through cross-channel correspondence and Δt constraints, rather than single-point dependency. The solution overcomes this by constructing a mapping set M and using spatiotemporal joint parameters as verification thresholds. For example, if Δt or d exceeds the limit, binding is rejected. This is more robust than the existing biased approach of "only requiring static IDs" and improves the system's ability to detect operational anomalies.

[0062] The context association processing module 400 receives the dual-channel acquisition vector and extracts spatial location signals, operation sequence numbers, and device identity sets to generate a context association structure. Considering the complexity of medical operations, such as concurrent scanning or positional shifts that may occur in multi-patient wards, the context association processing module 400 emphasizes deep analysis and mapping of the acquired data to ensure that the generated structure reflects the actual execution context, rather than simply a data stack. The dual-channel acquisition vector is essentially a composite vector containing independent structural units from both the patient and infusion ends, enabling cross-end association during processing. Existing similar vectors often lack this spatiotemporal embedding and cannot effectively handle potential conflicts in operation sequences. Specifically, the vector encoding format, such as JSON or binary serialization, can be determined based on the network bandwidth and processing load of the system deployment.

[0063] For details, please refer to Figure 2 The module's extraction process begins with receiving the dual-channel acquisition vector. This vector is actually a combination of the first and second acquisition structure units; the former originates from wristband-triggered acquisition at the patient's end, and the latter from bag identification triggering at the infusion end. During the parsing phase, the module first extracts the wristband identification field from the first acquisition structure unit. This is a unique identifier, such as an RFID-based encoded string, used for initial patient identification. Simultaneously, it extracts the patient's location vector. This is a multi-dimensional coordinate system, typically represented in three-dimensional space. Its purpose is to quantify the specific physical location of the patient's bedside, avoiding the ambiguity caused by abstract bed numbers. The domain is generally in real-valued space, but due to limitations in indoor positioning accuracy, it can be confined to the range of [-100, 100] meters. Additionally, the clock parameters of the patient's terminal device are extracted. This is a timestamp value, such as in Unix time format, used to establish a timing baseline. Its purpose is to compare the time with other endpoints to detect synchronization deviations. By combining these elements, a spatiotemporal segment at the patient's end is constructed. This segment can be viewed as a tuple structure: (wristband ID, ... , The significance of this combination arrangement lies in binding identity, location, and time into an inseparable unit, ensuring the integrity of subsequent comparisons, rather than processing each parameter in isolation.

[0064] Accordingly, for the second acquisition structure unit, the parsing process extracts the infusion bag identification field, which is a drug association code, such as the hash value generated by a QR code, used to track specific prescription packages; the execution end pump device identification number, which is a device serial number, such as the pump's UUID, used to bind the hardware entity; and the execution end local clock parameter. ,similar The timestamp is used for timing marking on the execution side. This constructs the execution-side spatiotemporal segment: (bag ID, pump ID, ... , ),in For the execution end device location vector, similar to The coordinates are set, but may originate from the pump's built-in positioning module. Their purpose is to capture the dynamic position of the infusion pump, especially in mobile pump scenarios, to prevent correlation failures caused by position drift. The structural principle of the two spatiotemporal segments is based on the causal logic of medical order execution; that is, the patient-side segment represents the "target" context, and the execution-side segment represents the "action" context. This separation facilitates parallel processing and provides a clear input interface for subsequent sequential comparison.

[0065] Next, the module performs a sequential comparison of the patient-side spatiotemporal segments and the execution-side spatiotemporal segments according to the time parameter sequence. Here, the time parameter sequence refers to... and Ordered pairs, such as those that might form a sequence {( , ), ( , The comparison process involves sorting algorithms, such as timestamp-based quicksort. The resulting operation sequence chain is a linked list or array structure, where each node contains a time pair and a corresponding identifier. Its purpose is to reconstruct the temporal logic of the operations and avoid the chaos caused by out-of-order data collection. For example, if... < This may indicate a pre-execution anomaly and needs to be marked as a potential disturbance. The significance of establishing the operation sequence chain lies in introducing the dimension of sequence number. In this application, "operation sequence number" refers to the index value in the chain, which increments from 1 to quantify the order of events. Its domain is the set of positive integers. In principle, it draws on the Lamport clock in distributed systems, but is simplified to adapt to the computing resources of medical devices.

[0066] This step involves establishing a location node correspondence matrix based on the location vector and the pump equipment identifier. , The pump IDs are mapped to a matrix, such as an m×n matrix, where rows represent patient-side location nodes, columns represent execution-side pump nodes, and corresponding elements are association strength values. The matrix is ​​constructed by first filling in initial values ​​through comparisons of location vectors, then mapping it to the operation sequence chain, injecting the temporal arrangement of the chain into the matrix's row and column order to ensure the matrix structure aligns with the actual operation flow. After mapping, the time parameter sequence and the set of location vectors (…) are then… and The union set of data and the corresponding matrix of position nodes are encapsulated into a hierarchical context association structure. This structure can be nested data objects, such as an outer time series layer and an inner position matrix layer. Its output is sent to the synchronization locking control module 500 for further locking domain establishment. The "hierarchical context association structure" mentioned in this application differs from the planar data structure in the prior art. It adopts a tree-like or multi-layered encapsulation, enabling data access at different levels of abstraction. For example, the root node is the overall context, and the leaf nodes are specific parameters. Existing similar structures are often flat and cannot efficiently support multi-level verification. The serialization depth of the structure can be determined according to the interface requirements of the downstream modules. For example, in high-concurrency systems, a caching layer can be added to optimize access.

[0067] The module also includes spatiotemporal correlation calculations when forming the position-node correspondence matrix. This part introduces the node position constraint coefficient Λ, the calculation formula of which is: The significance of this coefficient lies in quantifying the coupling strength between the two ends of position and time, providing a continuous constraint value rather than a binary judgment, which facilitates subsequent threshold decision-making. In the formula, The patient's position vector, as described above in three-dimensional coordinates, serves as a reference anchor point. This is the position vector of the execution device, similarly representing the position of the pump; Λ is the Euclidean distance between two vectors, used to measure physical proximity. Its domain is non-negative real numbers, and its principle is based on the natural decay of geometric distance to reflect the feasibility of practical operations; for example, excessive distance may indicate mismatched beds. α is the distance decay coefficient, a positive real number parameter, typically in the range [0.1, 1]. Its function is to control the decay rate; a larger value means faster decay at slightly larger distances. Its purpose is to provide adjustability, allowing sensitivity to be adjusted according to ward size. For example, in a small ICU, α can take a larger value for stricter constraints. This combination of exponential terms draws inspiration from the Gaussian kernel function, ensuring that the constraints are continuous and smooth rather than abrupt, which facilitates gradient optimization or threshold setting.

[0068] The other part of the formula is This is a time alignment function, defined as follows: = 1 if | | ≤ ε, otherwise 0; its function is as a time window gate, ensuring that only events with close time contribute to the constraint value, similar to a discrete version of Dirac delta, but thresholded to adapt to the actual clock precision. and These are the absolute values ​​of the difference between time parameters, such as timestamps, on the patient and execution sides, respectively. |Quantify synchronization deviation, defined as a real number, but in practice limited to integer seconds by clock resolution. ε is the time alignment tolerance threshold, a positive real number, such as 5-60 seconds. Its purpose is to tolerate network latency or gaps in human operation. Too small a value may lead to false rejections, while too large a value weakens security. The combination of parameters makes Λ decay exponentially with distance during time alignment, otherwise it is directly 0. This multiplicative structure principle lies in the mathematical implementation of logic and operation, ensuring spatiotemporal dual filtering. After obtaining Λ, it is filled into the device node dimension of the position-node correspondence matrix. For example, matrix element M[i,j] = Λ, if i corresponds to a patient node and j corresponds to a pump node. Then, based on the temporal arrangement of the operation sequence chain, the rows and columns of the matrix are synchronously adjusted, such as reordering rows to match the sequence number of the chain, ensuring that the matrix sequence structure is consistent with the chain. Finally, the matrix containing constraint coefficients is written into the spatial fragment layer of the context association structure.

[0069] As one possible implementation, in actual deployment, consider a typical scenario: a nurse administers an IV to patient A in a ward, first scanning the wristband to trigger data collection at the patient's end, obtaining... = (5.2, 3.1, 0.8), = 1728901234; then scan the infusion bag to get = (5.3, 3.0, 0.9), = 1728901238, Pump ID = "PMP-456". After receiving the vector, the module parses the fragments, compares the time, and generates a sequence chain [( , )], calculate || || ≈ 0.1414 meters, if α = 0.5, then exp(-0.5*0.1414) ≈ 0.932; if ε = 10 seconds, | Since | = 4 ≤ 10, δ=1, Λ ≈0.932. Fill this Λ ​​into the corresponding position in the matrix; for example, in a single-event matrix, it would be [[0.932]]. After adjustment, write it into the spatial layer of the structure. If there are multiple events, such as interference events from another patient B... If the value exceeds ε, then Λ = 0, and the corresponding element of the matrix becomes 0, thus isolating interference.

[0070] Traditional systems might directly pass if the distance is less than a threshold, but exponential decay allows for gradual evaluation, facilitating probabilistic model integration. The domain of parameter α ensures the exp term is between [0,1], and combined with the 0 / 1 switching of δ, it keeps Λ in [0,1], making it easy to use as a weight. ε is established based on clock synchronization protocols, such as the typical deviation of NTP, and in principle, it allows for customization to adapt to the equipment precision of different hospitals; for example, in a precision clock system, ε can be reduced to 1 second. The timing synchronization principle of matrix adjustment is to maintain causal consistency and avoid locking errors caused by reverse mapping. The spatial fragment layer of the final structure encapsulates these elements, ensuring that downstream modules can directly call Λ for constraint verification.

[0071] In this application, "spatial position signal" refers to the position vector extracted from the vector and the distance calculation signal; "operation sequence number" refers to the index in the chain; and "device identity set" refers to the set of wristband ID, bag ID, and pump ID. These terms are explained to clarify their roles in the association process; for example, the identity set is used for matrix labeling, not just as a key. Specifically, the sparse representation of the matrix can be determined based on computational resources, such as the CSR format to save memory, without limitation. For example, on embedded devices, matrix operations can be implemented using NumPy-like libraries, but the algorithm is essentially platform-independent. The innovation of the context association processing module 400 lies in the quantitative integration of spatiotemporal constraints, ensuring the traceability and robustness of the structure. This allows those skilled in the art to reproduce formula calculations based on standard programming frameworks such as Python's NumPy or C++'s Eigen library, and adjust parameters to match specific medical environments without additional hardware modifications.

[0072] The synchronous locking control module 500 is used to establish a cross-locking domain based on the infusion label information set and the context association structure, and to perform dual-end data consistency verification through the time window constraint of the cross-locking domain. Specifically, the cross-locking domain is essentially a dynamic constraint framework that ensures the synchronization of the tagging and execution ends during the medical order execution process through fine-grained time window division and differential analysis. It is particularly suitable for high-risk medical scenarios, such as ICU or chemotherapy infusion procedures, where any timing deviation may lead to patient safety risks. The "cross-locking domain" mentioned in this application is not limited to identity matching but also embeds time grids and differential constraints, enabling it to actively detect and eliminate jump interference. In contrast, existing similar domains often use passive threshold checks, which cannot handle fine-grained anomalies in continuous time sequences.

[0073] Please see Figure 3 The construction of the cross-locking domain begins with receiving input, namely the temporal segments of the local time domain parameters and contextual structure of the infusion tag information set. The module first divides the entire locking time period into multiple continuous time grids according to a preset time scale. This scale is a configurable parameter, typically set based on the medical order cycle, such as in units of 1 second or 5 seconds. This discretizes continuous time into a manageable grid, facilitating local anomaly detection rather than global scanning to reduce computational complexity. The domain of the time grid is a set of positive real number intervals. The structural setting principle borrows from the sampling theorem in signal processing, ensuring that the grid density is sufficient to capture potential jumps, but avoiding resource waste due to excessive density. For example, if the total length of the locking segment is T seconds and the scale is Δt, then the number of grids... Each grid ,in The start time of the segment.

[0074] Within each time grid, the module writes the tag-end time parameter. and execution time parameters ,here It is the kth timestamp extracted from the tag information set, representing the baseline time sequence of the preset medical order; This is extracted from the context structure, representing the actual execution of the observation timing. Both writes employ a synchronous padding mechanism, aligning with the raster index k to ensure correspondence. Subsequently, sequential detection is performed on time jumps between rasters. This step calculates the jump variables of adjacent rasters, such as jumps at the tag end. Similarly, for the execution end The significance of establishing jumps lies in quantifying the continuity of time sequences and detecting nonlinear disturbances such as network latency or human intervention. Its domain is real numbers, but in practice, it is limited to sampling intervals that are integer multiples of clock resolution. The detection process can employ differential operations; if the jump variable |Δ| of any adjacent grid cells... |or|Δ If the value exceeds the preset threshold τ, the corresponding grid will be marked as a conflict grid and excluded from the cross-locking domain. The threshold τ is used to define the tolerance boundary. Its combination arrangement is coupled with the grid scale to ensure that the detection sensitivity is adjustable.

[0075] After excluding conflicting graticules, a two-end data consistency check is performed within the remaining continuous segments, focusing on subfields free of anomalies to ensure that only reliable segments participate in locking. The module further compares the tag-end time series Tt with the execution-end time series. Calculate the sequence difference component Δ, which is given by the formula... Given, among which As a benchmark sequence, representing the ideal medical order sequence, its purpose is to provide a static reference to quantify deviations. Its domain is a set of non-negative real number timestamps, and its structural principle is based on the time domain parameters of prescription parsing, ensuring that the sequence is monotonically increasing to reflect the progress of the task. Injecting a dynamic execution context is used to capture contextual variations, such as operational delays, with the same domain definition. However, it may contain noise. n is the number of comparison points within the locked domain, a positive integer parameter used to define the verification range. Its variable size adapts to different task lengths, and its domain is [1, ...]. ],in Due to memory limitations, it typically uses several hundred points to balance accuracy and efficiency.

[0076] Absolute value in the formula The temporal deviation of individual points is quantified, and their combination is arranged to achieve a cumulative effect through summation (∑). The significance lies in capturing overall inconsistencies rather than local peaks, similar in principle to L1 norm distance, ensuring robustness against outliers. The difference from L2 norm is that L1 focuses more on absolute error, suitable for non-Gaussian noise in medical time series. After obtaining Δ, the module compares it with a threshold. Comparison, this This is a preset upper limit, such as the statistical mean plus standard deviation based on historical data. Its function is to serve as a decision boundary, distinguishing between normal fluctuations and anomalies. Its domain is positive real numbers, and in principle, it can be adaptively adjusted through machine learning, but it is fixed in this implementation to simplify deployment. When Δ < When Δ ≥ 0, the locked domain is marked as a verifiable domain, and a consistency comparison between the two endpoints is performed in that domain. This step can be extended to cross-validation of identity and location, such as comparing the tag identity code with the context device identity set; when Δ ≥ 0. When this occurs, the lock rejection logic is triggered and the corresponding task segment is isolated. This isolation may involve logging and alerts, and its purpose is to prevent the propagation of errors and ensure system fault tolerance.

[0077] As one possible implementation, in a typical infusion scenario, it is assumed that the tag information set provides =[t0, t0+5, t0+10, t0+15] (in seconds, t0 is the starting value), the context structure provides... = [t0+1, t0+6, t0+9, t0+16]; The locked segment is divided into 4 grids, each grid lasting 5 seconds. After writing, a transition is detected: the transition at the tag end is constant at 5 seconds, with no over-threshold (assuming τ=2 seconds); the execution end is similar, but if the third transition is -1 second (assuming an inversion anomaly), then the third grid is marked as a conflict and excluded. The remaining segments n=3, calculate Δ = |1| + |1| + |1| = 3; if If Δ = 5, it is marked as a verifiable field, and the consistency of nodes such as pump ID is further compared. If Δ = 10 (large deviation), locking is rejected, and task segments are isolated, such as removing the corresponding medical orders through a queue.

[0078] The calculation of the sequence difference component Δ avoids mean-based bias, instead using the cumulative absolute difference to highlight the cumulative effect. For example, in long sequences, the accumulation of small biases may indicate system drift, while a single large bias may be directly captured by the threshold. The index of parameter k ranges from 1 to n, ensuring sequence alignment. The principle behind its combination and arrangement of absolute values ​​is non-negativity, guaranteeing that Δ monotonically reflects the degree of inconsistency. Threshold The establishment of this mechanism can be based on historical data from Monte Carlo simulations, its significance being adaptive thresholding; however, in this module, static configuration ensures determinism. The structural principle of the lock rejection logic borrows from the atomicity of transaction processing, ensuring that tasks can be retried after isolation, rather than becoming permanently invalid.

[0079] In this application, "time window constraint" refers to the combination of grid partitioning and differential thresholding, which differs from the sliding window of existing window functions. It uses a fixed grid to facilitate parallel computation. Specifically, τ and τ can be determined based on the hardware clock drift. For example, on a GPS-synchronized pump device, τ can be compressed to 1 second, while on a manual clock it can be relaxed to 30 seconds. Sequential detection of time jumps can be integrated with Fourier transforms to identify spectral anomalies, but the core remains differential thresholding to maintain simplicity. The overall architecture of the module ensures a tight link from input parsing to output decision-making. The domain and function of each parameter serve the needs of medical traceability; for example, the finiteness of n prevents infinite loops, and the L1 form of Δ facilitates hardware implementation. Domain experts can reproduce the formula based on vectorized summation using standard libraries such as NumPy, while threshold adjustment is implemented through configuration files without code refactoring. Through this quantification of spatiotemporal constraints, the synchronization lock control module 500 achieves proactive filtering of potential interference, improving the system's robustness in handling concurrent medical orders.

[0080] The transaction status determination module 600 is used to output binding authorization instructions based on the verification results and to isolate tasks when tag conflicts or concurrent interference are detected. For details, please refer to Figure 4The processing logic of the transaction status determination module 600 takes the structure output by the cross-locking field as input, and the received input includes at least: a tag time chain sequence (which can be represented as...). ), device node sequence ( ), spatial segment sequence ( The tag time chain can be a local device clock value in milliseconds or a Unix timestamp calibrated with a unified reference clock. The actual time format used by the system can be determined based on the deployment environment, and the definition domain is not limited. The device node sequence is usually composed of unique node numbers of devices such as execution pump devices, barcode scanning terminals, and bedside gateways. The node number can be encoded in hexadecimal, integer number, or location tree encoding, which is not limited. The spatial segment sequence usually contains the bed code, ward number, local coordinate vector, or other fields that can measure spatial relationships when collected at the patient end. Its data format can be three-dimensional coordinates, two-dimensional grid coordinates, area identifiers, etc., and will be uniformly calculated into vector form for comparison within the system.

[0081] After receiving the above input structure, the module performs fragment extraction. Fragment extraction requires separating the smallest decidable unit that has a logical relationship within an infusion locking domain from the structure. For example, if the tag time chain contains 6 time points, where time points... If there is a time interval exceeding the preset limit (e.g., 5 seconds), the system will consider it as... Belonging to the same transaction segment, and This belongs to another segment to avoid unnecessary cross-segment misjudgments. As one possible implementation, the upper limit of the time interval can be set to any value within the range of 3–10 seconds, determined by the hospital's operating procedures and network latency characteristics, and is not strictly limited thereto. The results of segment extraction constitute a set of transaction segments, each segment containing a set of time chains, a set of device node sequences, and a set of spatial segments.

[0082] When processing transaction segments one by one, the system first identifies the structure of the time series. The tagged time chain needs to satisfy a non-decreasing relationship, that is... Only then is it considered normal; if it occurs If a reverse sequence structure is formed, it will be considered an anomaly. The domain of reverse sequence does not depend on the time unit or whether the clock is absolute time; the only criterion is the directionality of the sequence. Reasons for reverse sequence may include device clock drift, key press delay, wireless network retransmission, or incorrect actual operation order. Therefore, the system will write a reverse sequence flag to the timing re-check flag bit of the segment instead of directly rejecting the segment. The timing re-check flag can be a Boolean value, a bit flag field, or an integer status code. Using bit flags typically makes subsequent status summarization easier.

[0083] After completing time chain identification, continuity identification is performed on the node sequence, which involves entering the configuration identification loop for transaction segments. Node sequence Essentially, this represents the order of device access during execution, such as wristband scanner → infusion pump → bedside gateway. To determine the rationality of node switching, the system pre-defines a node topology graph. This topology graph is essentially a weighted directed or undirected graph, where nodes represent device entities and edges represent reachability between devices. For ease of understanding by those skilled in the art, an example illustrates the construction of the topology graph: A ward contains two infusion pumps A and B, a bedside scanner C, and a nurse station control terminal D. The topology graph can be defined as a set of nodes {A, B, C, D}, where A and C are connected by an edge, C and D are connected by an edge, and B and D are not directly connected. Each edge between nodes is assigned a topological weight, which includes at least the path cost. Minimum time difference for node switching Node functional correlation Three items. Among them, path cost. This can be represented as the physical distance between nodes, network access cost, or cost of moving across rooms, and can be expressed as an integer or floating-point number; minimum time difference for node switching. This can be set based on statistics of nurses' average operational behavior, for example, the average movement time from the barcode scanner to the infusion pump should not be less than 1 second, and the domain is usually real numbers > 0; node functional correlation. This reflects the operational relationship between two nodes in an infusion task, such as the infusion pump and its associated bedside scanner. The infusion pump and the nurse station printer The system does not require the topology graph to be in a certain format; it only requires that the weight set can participate in the node transition judgment.

[0084] When processing node sequences, the module reads from the topology graph. to The weights are used to construct the cost vector. The cost vector is then compared with the valid handover domain. The valid handover domain can be defined as: When any of the conditions is not met, a nodal jump configuration is formed. For example, when This may indicate that the scanning behavior spanned across beds or regions; when This may indicate that the node switching speed is too fast, exceeding the actual range of care possible; when When a business relationship is not established, such as receiving a barcode scan from the nurse station printer immediately after a patient's wristband scan, this is a clear error. Node jump configurations are identified as high-risk markers, and the system will write them to the node locking flag, indicating that the segment is no longer allowed to participate in binding in subsequent processes.

[0085] Simultaneously, monotonicity testing is performed on the tag sequence to identify tag re-entry configurations. Tag re-entry can be determined by whether the tag ID appears more than once in the segment; if it does, it is considered re-entry. In certain specific scenarios, dual-scan verification is permitted, such as when nurses need to repeatedly scan the infusion bag before starting an infusion. In this case, false positives can be eliminated by pre-setting allowed tag types or time interval conditions in the system. For example, if the same tag ID appears repeatedly within a time interval exceeding a certain threshold (e.g., 5 seconds) and the status field is "Confirm Scan," it is not considered re-entry. The specific rules for allowing re-entry are determined by the hospital's procedures and are not limited. Once a tag re-entry configuration is established, a tag isolation marker is written, which is typically used as the highest level of blocking condition.

[0086] In the subsequent transaction state decision-making process, the aforementioned configuration tags are stored in the segment's structure tag table as status words. The structure tag table can be stored in bitmask, integer enumeration, or structure form. The module performs a decision tree, obtaining the tag distribution of the entire transaction segment set by bitwise or summarizing. For example, if all segments contain only timing re-check tags, it indicates that there is no spatial conflict or label conflict, and the system can continue to execute the binding authorization process. Binding authorization can include generating binding tokens, starting infusion pump task binding, writing back to HIS, or sending MQTT commands to the execution end device, etc., the method used is determined by the system architecture. If a node locking tag or label isolation tag appears in the tag distribution, the module immediately enters the task isolation logic, including terminating the current binding, generating alarm events, locking tag data, or freezing segments. The task isolation logic is a terminating action in this application system; once triggered, all subsequent actions are interrupted to ensure that erroneous data is not used.

[0087] Existing systems typically determine legitimacy by scanning the wristband followed by the medicine bag. However, in multi-device, multi-node concurrent environments, the scanning order itself is unreliable, especially in scenarios with network jitter, device latency, and cross-node switching, leading to issues such as disordered order, data misalignment, and duplicate tags. This application overcomes the technical limitations of traditional solutions in concurrent scenarios by employing a multi-dimensional constraint mechanism based on time direction, node topology path, and the uniqueness of the tag sequence. This mechanism allows the system to determine legitimacy based on computationally verifiable structured conditions, rather than relying on a single source of data.

[0088] The execution record collection module 700 is used to collect binding tokens and cross-locking field records after the infusion task is completed, generate a traceable transaction record chain, and store it in the central database. Specifically, the execution record collection module 700 runs after the infusion task termination event is triggered. This termination event can originate from the "completion status bit" reported by the infusion pump, the "manual termination command" triggered by the bedside terminal, or the "forced termination flag" in abnormal interruption scenarios. After receiving the termination event, the module constructs a staged transaction record structure based on the binding tokens and cross-locking field records. To avoid time misalignment or structural inconsistencies caused by different data sources, the record construction unit first standardizes the two types of input data into an internal structure format before entering the stage tuple generation process.

[0089] It should be noted that the binding token in this application is used to maintain task reference relationships throughout the entire infusion task process. The binding token typically consists of multiple fields, including task ID, patient identifier field, and local verification value bound to the infusion bag label; some of these fields will be extracted as "token fragments" in this module. The purpose of the token fragments is to provide stage-level task association indexes to avoid redundancy caused by repeatedly storing the complete token in the database.

[0090] When constructing the phased transaction record structure, the record construction unit divides the entire infusion task into several phases based on the hospital's actual operating procedures. For example, it can set "start scan phase," "pump lock phase," "infusion execution phase," and "end confirmation phase," but there is no restriction on the specific phase division method. The only requirement for phase division is that each phase should be able to obtain an independent time vector and node fingerprint based on the structural characteristics in the cross-locking domain. The phase identifier parameter can use integer encoding or an enumerated field, which only needs to remain unique within the system.

[0091] The "node identity fingerprint" in this application reflects the node's role in the infusion process. It can be a combination of device model, device number, and role identifier, such as "PUMP-07 / Execution Node" or "SCAN-04 / Scanning Node". This is because the same model of equipment may appear in different wards, and to avoid misassociation, a role factor needs to be introduced as part of the fingerprint. Each transaction stage tuple contains five types of data: stage identifier parameter, time vector, token fragment, node identity fingerprint, and previous stage index. The time vector consists of three components: the time difference between the two ends of the acquisition, the lock field reference time, and the node's local clock offset.

[0092] It should be noted that the dual-end data collection time difference reflects the data collection latency difference between the binding token generation end and the execution node reporting end. Its calculation method can be... To bind the token time field, The node acquisition time is the difference used to detect node clock drift or network latency; the data field can be an integer millisecond or a floating-point millisecond. The lock domain reference time is a globally calibrated baseline time within the cross-lock domain, used to ensure the orderability of stage tuples. The node local clock offset characterizes the offset of a node relative to the reference time, and its purpose is to provide a time correction basis for subsequent analysis.

[0093] The token fragment may contain the lower part of the task number, a tag verification field, or a stage indicator, etc. To avoid redundancy, it does not contain the complete patient information field. For example, only the 4-byte stage encoding segment and the 2-byte task verification segment from the complete token can be extracted, which is sufficient to establish a reference relationship in the database.

[0094] The preceding stage index is used to chain stage tuples together into a linked structure. The index can be an integer sequence number, a hash index, or a logical reference to the previous stage tuple. For example, the preceding index of stage 3 could point to the linked list node number of stage 2, thus ensuring the traversability of the stage chain.

[0095] After generating all stage tuples, the record building unit arranges them in a one-way serialization according to the lock field reference time, forming a transaction record chain in ascending order of reference time. The reason for using one-way serialization is that the execution flow of an infusion task generally only has a forward direction and no random behavior that requires reverse tracing; therefore, there is no need to use a doubly linked list or graph structure, and a one-way chain can meet the traceability requirements.

[0096] Furthermore, the transaction record chain contains a preceding reference in each stage tuple, making the chain structure itself a traceable path without requiring additional concatenation via database fields. This structure is crucial for subsequent auditing, traceability, and quality control. The final transaction record chain is written to the corresponding task record area in the central database. The task record area can use a relational database table or a document-oriented database JSON structure, without restriction; however, it must maintain the inter-stage relationships through chained references. Write operations are typically performed within transaction locks to ensure that the record chain does not break or become corrupted due to concurrent database writes.

[0097] Finally, it should be noted that the mathematical formulas, derivations, symbol definitions, and parameter calculation methods used in this specification are all for the purpose of further clarifying and verifying the technical content of this invention, so that those skilled in the art can more intuitively and accurately understand the working mechanism and technical effects of this invention. These formulas are only used as quantitative expressions or illustrative examples of technical features and do not constitute limiting conditions of the claims of this invention. Those skilled in the art should understand that, without changing the core idea of ​​this invention, the parameter forms, calculation methods, numerical ranges, and even symbol representations involved in the formulas can be equivalently replaced or simplified in engineering according to the actual application environment. The specifics can be determined according to the actual situation, and no limitation is imposed. It should also be emphasized that the formulas in this specification are not theoretical derivations in the style of academic research papers, but rather an engineering description of the embodiments of this invention. Their purpose is to enhance the understandability and implementability of this invention, rather than to increase redundancy and complexity. Those skilled in the art can choose whether to use such quantitative tools when reading this specification, or can achieve the same technical effects through other equivalent methods.

[0098] Furthermore, while specific embodiments of the present invention have been described above, those skilled in the art should understand that these specific embodiments are merely illustrative. Those skilled in the art can omit, substitute, and modify the details of the above methods and systems in various ways without departing from the principles and essence of the present invention. For example, combining the above method steps to perform substantially the same function and achieve substantially the same result according to substantially the same method falls within the scope of the present invention. Therefore, the scope of the present invention is defined only by the appended claims.

Claims

1. An infusion information management system; characterized in that: include: The task information access module is used to extract prescription task packages from the medical information system, parse medical order parameters, patient identifiers and drug attributes, and form the initial task structure. The tag data generation module is used to generate an infusion tag information set, including local time domain parameters, tag identification codes, and cross-node random salt values, based on the task initial structure. The dual-channel acquisition module is used to acquire the wristband identifier, bedside node identifier, and local device clock at the patient end, as well as the infusion bag identifier, pump device identification number, and execution node clock at the infusion end, and generate a dual-channel acquisition vector. The context association processing module is used to receive the dual-channel acquisition vector, extract the spatial location signal, operation sequence number and device identity set, and generate a context association structure. The synchronous locking control module is used to establish a cross-locking domain based on the infusion label information set and the context association structure, and to perform dual-end data consistency verification through the time window constraint of the cross-locking domain. The transaction status determination module is used to output binding authorization instructions based on the verification results, and to isolate tasks when tag conflicts or concurrent interference are detected. The execution record collection module is used to collect binding tokens and cross-locking domain records after the infusion task is completed, generate a traceable transaction record chain, and store it in the central database.

2. The infusion information management system according to claim 1, characterized in that: The generation process of the tag data generation module includes: Obtain prescription time parameters, dispensing time parameters, and execution node local clock parameters from the task information access module, and construct a time parameter set; Extract the corresponding node device identifier and calculate the node clock offset to form the node sequence parameter; Generate cross-node random salt values ​​based on a joint hash function of node sequence parameters and time parameter sets; The tag identity code is obtained by performing identity encoding operation based on the task identifier code and cross-node random salt value; The time parameter set, tag identification code, and cross-node random salt value are combined according to a preset sequence to generate an infusion tag information set.

3. The infusion information management system according to claim 1, characterized in that: The dual-channel acquisition module includes a first acquisition sub-module and a second acquisition sub-module; the first acquisition sub-module is used to trigger an acquisition event on the patient end based on the wristband identifier, record the wristband code, the patient end spatial coordinate group and the local clock count value, and generate a first acquisition structure unit; The second acquisition submodule is used to trigger an acquisition event based on the infusion bag identifier at the infusion execution end, record the infusion bag code, pump device identification number and local timing sequence, and generate the second acquisition structure unit; The first acquisition structure unit and the second acquisition structure unit establish a cross-channel correspondence through the acquisition event sequence number. When the correspondence is formed, the time vector difference is calculated for the timing parameters of the two units. The time vector difference is combined with the spatial coordinate group and the pump device identification number to form an acquisition consistency mapping set.

4. The infusion information management system according to claim 1, characterized in that: The extraction process of the context association processing module includes: When receiving dual-channel acquisition vectors, the wristband recognition field, patient position vector and patient device clock parameter in the first acquisition structure unit are parsed to construct a patient spatiotemporal segment; The infusion bag identification field, the pump device identification number at the execution end, and the local clock parameter at the execution end in the second acquisition structure unit are analyzed to construct the spatiotemporal segment of the execution end. The spatiotemporal segments of the patient end and the spatiotemporal segments of the execution end are compared sequentially according to the time parameter sequence to generate an operation sequence chain; A location node correspondence matrix is ​​established based on the location vector and the pump equipment identifier, and the location node correspondence matrix is ​​associated and mapped with the operation sequence chain; After mapping is complete, the time parameter sequence, the set of position vectors, and the matrix corresponding to the position nodes are encapsulated into a hierarchical context association structure and output to the synchronization locking control module.

5. The infusion information management system according to claim 4, characterized in that: When establishing the location node correspondence matrix, the context association processing module performs a process on the patient-end location vector in the first acquisition structure unit. The position vector of the execution end device in the second acquisition structure unit Perform spatiotemporal correlation calculations to obtain node position constraint coefficients. The formula expression is: in, The patient's position vector; For the position vector of the execution end device; The Euclidean distance between the position vectors of the two ends; This is the distance attenuation coefficient; For patient-side time parameters; For execution time parameters; Let be a time alignment function, and the value of the time alignment function satisfies: in The time alignment tolerance threshold is used; the node position constraint coefficient is obtained. Afterwards, The device node dimension of the matrix corresponding to the location node is filled in, and the rows and columns of the matrix corresponding to the location node are synchronously adjusted based on the temporal arrangement of the operation sequence chain to ensure that the resulting matrix has a sequence structure consistent with the operation sequence chain; finally, the matrix corresponding to the location node containing the constraint coefficients is written into the spatial fragment layer of the context association structure.

6. The infusion information management system according to claim 1, characterized in that: The cross-locking domain construction process of the synchronization locking control module includes: After receiving the local time domain parameters and context association structure of the infusion tag information set, the entire locked time period is divided into multiple continuous time grids according to a preset time scale. Write the tag-end time parameter and the execution-end time parameter into each time grid, and perform sequential detection on the time jumps between grids; When the time jump variable of any adjacent raster exceeds a preset threshold, the corresponding raster is marked as a conflict raster and excluded from the cross-locking domain; Perform two-way data consistency checks within contiguous segments that do not contain conflicting graticles.

7. The infusion information management system according to claim 1, characterized in that: The consistency verification process of the synchronization locking control module includes: Tag-side time series Time series of the execution end Calculate the sequence difference components and with the sequence difference components The consistency constraint parameter is used; the formula for calculating the sequence difference component is: in, For the first tag information set A time parameter; For the first context-related structure A time parameter; To determine the number of comparison points within the locked domain; Sequence difference components With preset threshold Compare; when When the locked domain is marked as a verifiable domain, a consistency comparison between the two ends of the node is performed within that verifiable domain; when When this occurs, the lock rejection logic is triggered and the corresponding task segment is isolated.

8. The infusion information management system according to claim 1, characterized in that: The working process of the transaction status determination module includes: When receiving the verification output of the cross-locking domain, the tag time chain, device node sequence and spatial segment sequence in the verification output are segmented to form the corresponding transaction segment set; Configuration identification is performed on the time series direction, node sequence continuity and label sequence monotonicity within the transaction fragment set, and detected sequence reversals, node jumps or label re-entries are marked as conflict configurations. According to the type and number of the conflict configuration, the corresponding branch of the state decision tree is input, wherein a timing re-examination flag is written for a transaction segment containing a single sequence inversion configuration, a node locking flag is written for a transaction segment containing a node jump configuration, and a label isolation flag is written for a transaction segment containing a label reentry configuration. After the above-mentioned markings are formed, the overall marking distribution of the transaction fragment set is summarized. When the summarization result only contains the timing re-examination marking, the binding authorization instruction is output. When the summarization result contains the node locking marking or the tag isolation marking, the task isolation logic is entered and the subsequent processing flow is interrupted.

9. An infusion information management system according to claim 1, characterized in that: The process of determining the node jump configuration in the conflict configuration includes: The device node sequence in the received transaction segment is retrieved from the preset node topology graph, and the topology weight corresponding to each device node is retrieved. The topology weight includes the path cost between nodes, the lower bound of the node switching time, and the node functional relationship parameter. Perform path continuity analysis on the topology weights of adjacent device nodes and calculate the node switching cost vector. ,in, This represents the path cost from node i to node j. This represents the minimum time difference for node switching. A parameter representing the degree of association of node functions; The cost vector is compared with a preset valid switching domain, and the following conditions are met. The node switching is marked as a node jump configuration, and the node jump configuration is written into the structure tag table of the transaction fragment.

10. An infusion information management system according to claim 1, characterized in that: The execution record collection module includes a record construction unit for building a phased transaction record structure after the infusion task termination event is triggered. The record construction unit generates a transaction record chain composed of several transaction stage tuples based on the binding token and cross-locking domain records. Each transaction stage tuple includes: a stage identifier parameter representing the infusion task stage, a time vector extracted from the cross-locking domain, a token fragment extracted from the binding token, a node identity fingerprint, and a reference index of the preceding stage tuple. The time vector includes the time difference between the two ends, the locking domain reference time, and the node local clock offset. The record construction unit performs unidirectional serialization and arrangement of several transaction stage tuples based on the locking domain reference time. The resulting sequence is the transaction record chain, and the transaction record chain is written into the corresponding task record area of ​​the central database.

Images