Method for constructing knowledge graph of medical consumables supply chain

Abstract

The present application provides a method for constructing a knowledge graph for a medical consumables supply chain, which includes: performing cross-media mapping and distributed desensitization on the collected original medical business data to generate a desensitized semantic data stream; performing temporal relationship extraction on the desensitized semantic data stream to generate an "order creation-review-outbound" event chain; based on a constructed medical time constraint rule library, constraining the "order creation-review-outbound" event chain to generate a dynamic relationship description with time constraints; injecting medical consumables knowledge into the dynamic relationship description with time constraints to generate a medical consumables supply chain description containing "business entity-medical attribute"; and performing a "regulatory clause-business entity-medical standard" ternary mapping on the medical consumables supply chain description to generate a medical consumables supply chain knowledge graph. The solution provided by the present application improves the accuracy of violation warnings and processing, and supports intelligent decision-making throughout the entire chain.

Description

Technical Field

[0001] The present invention relates to the field of data, and in particular to a method for constructing a knowledge graph for a medical consumables supply chain. Background Art

[0002] The medical consumables supply chain is a critical link between production and clinical application. Its efficient operation directly impacts the quality of medical services and patient safety. Furthermore, the circulation of medical consumables is subject to strict timeliness requirements (e.g., emergency surgical consumables require rapid response) and compliance constraints (e.g., implants must meet regulations such as unique identification and traceability, and sterilization standards).

[0003] Currently, for data processing and knowledge management of the medical consumables supply chain, existing technologies mainly adopt the following methods: at the process monitoring level, they mostly rely on preset fixed time thresholds to manage the timeliness of order processing, inventory management and other links. They are unable to dynamically adjust the constraints according to the type of surgery, consumables risk level, etc., and it is difficult to capture the temporal dependencies of event chains such as "order creation-review-warehouse delivery", and the accuracy of timeliness violation warnings and processing is insufficient; in terms of compliance and knowledge integration, they mainly link regulatory clauses with business processes through manual configuration rules, and lack the automated extraction and integration of professional medical knowledge such as biocompatibility and transportation temperature control requirements, resulting in low compliance verification efficiency and fragmented knowledge application, making it difficult to support intelligent decision-making across the entire chain. Summary of the Invention

[0004] In order to solve the above technical problems, the present application provides a method for constructing a medical consumables supply chain knowledge graph to at least solve or alleviate the problems existing in the above-mentioned prior art.

[0005] To achieve the above objectives, according to one aspect of the present application, a method for constructing a medical consumables supply chain knowledge graph is provided, which includes:

[0006] Step 1: Perform cross-media mapping and distributed desensitization on the collected original medical business data to generate a desensitized semantic data stream;

[0007] Step 2: Extract temporal relationships from the desensitized semantic data stream to generate an "order creation - review - delivery" event chain;

[0008] Step 3: Based on the constructed medical time constraint rule library, the "order creation-review-delivery" event chain is constrained and labeled to generate a dynamic relationship description with time constraints;

[0009] Step 4: Inject medical consumables knowledge into the dynamic relationship description with time constraints to generate a medical consumables supply chain description containing "business entity-medical attribute";

[0010] Step 5: Perform a “regulatory clause-business entity-medical standard” ternary mapping on the description of the medical consumables supply chain to generate a medical consumables supply chain knowledge graph.

[0011] The solution provided in this application realizes differentiated time constraint definitions by constructing a medical time constraint rule library to replace the traditional fixed time threshold. At the same time, it extracts temporal relationships and labels constraints on event chains such as "order creation-review-warehouse delivery" to capture the temporal dependencies between process links, so that time monitoring is transformed from independent judgment of a single link to dynamic correlation analysis of the entire process, thereby improving the accuracy of violation warning and processing. In terms of compliance and knowledge integration, by injecting medical consumables professional knowledge into the dynamic relationship description with time constraints, a structured description of "business entity-medical attribute" is formed, realizing the automatic association of professional knowledge and business entities; further, through the ternary mapping of "regulatory clauses-business entity-medical standards", compliance verification is upgraded from manual rule configuration and item-by-item comparison to graphical automatic reasoning based on knowledge association, solving the problems of low compliance verification efficiency and fragmented knowledge application, and supporting intelligent decision-making across the entire chain. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 This is a flow chart of a method for constructing a knowledge graph for a medical consumables supply chain according to an embodiment of the present application;

[0013] Figure 2 This is a schematic diagram of the structure of a device for constructing a knowledge graph for a medical consumables supply chain according to an embodiment of the present application;

[0014] Figure 3 This is a schematic structural diagram of an electronic device according to an embodiment of the present application;

[0015] Figure 4 This is a structural diagram of a medical consumables management system according to an embodiment of the present application. DETAILED DESCRIPTION

[0016] Figure 1 This is a flow chart of a method for constructing a knowledge graph of a medical consumables supply chain according to an embodiment of the present application. Figure 1 As shown, it includes:

[0017] Step 1: Perform cross-media mapping and distributed desensitization on the collected original medical business data to generate a desensitized semantic data stream;

[0018] Step 2: Extract temporal relationships from the desensitized semantic data stream to generate an "order creation - review - delivery" event chain;

[0019] Step 3: Based on the constructed medical time constraint rule library, the "order creation-review-delivery" event chain is constrained and labeled to generate a dynamic relationship description with time constraints;

[0020] Step 4: Inject medical consumables knowledge into the dynamic relationship description with time constraints to generate a medical consumables supply chain description containing "business entity-medical attribute";

[0021] Step 5: Perform a “regulatory clause-business entity-medical standard” ternary mapping on the description of the medical consumables supply chain to generate a medical consumables supply chain knowledge graph.

[0022] In summary, by building a medical time constraint rule library, replacing traditional fixed thresholds, time constraint rules can be dynamically defined based on medical scenario characteristics such as surgical procedure type (e.g., emergency surgery vs. routine surgery) and consumable risk level (e.g., implants vs. general consumables) (e.g., setting stricter outbound time thresholds for emergency surgical consumables), achieving differentiated time management. Furthermore, by extracting the "order creation-review-outbound" event chain and combining it with the rule library to annotate the event chain with timing constraints, the temporal dependencies between each link are captured (e.g., the impact of review timeouts on outbound delivery), generating dynamic relationship descriptions with time constraints. This upgrades time monitoring from independent judgment of a single link to full-process correlation analysis, significantly improving the accuracy of violation warnings. Furthermore, through the injection of medical consumable knowledge, professional medical knowledge such as biocompatibility, sterilization cycle, and transportation temperature control requirements are automatically associated with business entities (e.g., implants, cold chain logistics), forming a structured description of "business entity-medical attributes," replacing manual rule configuration and achieving automated extraction and integration of professional knowledge. Finally, by performing a ternary mapping of "regulatory clauses-business entities-medical standards", a direct link is established between regulatory requirements (such as unique identification traceability), business operations (such as order review and consumables delivery) and medical standards (such as sterilization standards and cold chain transportation specifications). This allows compliance verification to be upgraded from manual item-by-item comparison to graphical automatic reasoning (for example, automatically verifying whether an implant order meets the UDI identification requirements through a graph), supporting intelligent decision-making and compliance management throughout the entire chain.

[0023] Optionally, step 1 includes:

[0024] Step 11: Perform local homomorphic encryption on the collected original medical business data to obtain ciphertext medical business data, which is then distributed to the set federated nodes for distributed desensitization to generate a desensitized data set with traceability marks, including consumable entity identification, security level labels, and desensitization operation logs;

[0025] Step 12: Based on the constructed cross-media mapping engine, feature fusion is performed on the desensitized dataset with traceability tags to implement cross-media mapping to generate a desensitized semantic data stream.

[0026] Optionally, step 12 includes:

[0027] Step 121: Based on a multimodal generative adversarial network, perform semantic embedding processing of medical term enhancement on the desensitized dataset with traceability marks to generate a cross-modal shared semantic vector;

[0028] Step 122: Based on the graph attention network, perform entity association processing on the cross-modal shared semantic vector to generate a multimodal entity mapping table;

[0029] Step 123: Based on the CTC-GNN fusion network, feature fusion is performed on the multimodal entity mapping table to implement cross-media mapping to generate a desensitized semantic data stream.

[0030] In summary, the sensitivity of medical data requires that the encryption process be completed locally at the data provider (e.g., hospitals encrypt patient information before uploading it) to avoid the risk of plaintext transmission. Homomorphic encryption supports secret-state computing (e.g., executing desensitizing algorithms on ciphertext), ensuring a balance between privacy protection and data availability (e.g., ciphertext data can be distributed and trained across federated nodes without leaking the original content). The medical supply chain involves multi-party collaboration (production-circulation-use). Distributed desensitization uses a federated learning mechanism, where each participant only shares desensitizing model parameters rather than the original data (e.g., hospitals, distributors, and logistics providers each train their own local desensitizing models and collaboratively optimize them through a federated parameter server). This complies with the medical data sharing principle of "data remains static, model moves," improving data sharing efficiency while reducing compliance risks.

[0031] Furthermore, given the significant differences in the raw data formats of text, images, and speech (text is sequence data, images are pixel matrices, and speech is waveform signals), the implementation leverages the cross-modal mapping capabilities of generative adversarial networks (GANs) to encode them into a unified semantic space. For example, the "left knee prosthesis" in the order text and the UDI identifier in the RFID image generate the same semantic vector after GAN processing, ensuring that the subsequent graph network can recognize them as the same entity.

[0032] Furthermore, given the abundance of specialized terms in the medical field (e.g., "biocompatibility" and "sterilization cycle"), common semantic embedding models (such as BERT) struggle to accurately capture their underlying meaning. Therefore, in practice, medical terminology enhancement (e.g., using the BERT-Med pre-trained model to initialize a GAN) can improve the semantic representation accuracy of specialized terms (e.g., distinguishing the nuances between "prosthesis" and "prosthetic joint") and avoid supply chain decision errors caused by terminology ambiguity (e.g., incorrectly allocating non-sterile consumables to surgical procedures).

[0033] In this embodiment, the graph attention network and CTC-GNN collaborate, and the entity relationships in the supply chain (such as "consumables-orders-logistics") have dynamic and multi-dimensional characteristics (timeliness level, inventory status, transportation path). The multi-head attention mechanism of GAT can dynamically calculate the association weights between entities (such as adjusting the scheduling priority of "consumables-logistics" according to the urgency of the order), which is more adaptable to the complex constraints of medical scenarios (such as the priority allocation of resources for high-risk surgeries) than traditional graph algorithms (such as GCN).

[0034] Furthermore, in this embodiment, the dual-dimensional processing of temporal and modal features in the CTC-GNN fusion network addresses the need for temporal alignment using the CTC (Connectionist Temporal Classification) model, specifically for voice commands containing temporal information (e.g., the time constraint of "shipping within 10 minutes"). This ensures a precise match between the voice text and the order timestamp. Combined with the graph convolution capabilities of GNNs, this network can simultaneously process both the spatial associations of multimodal features (e.g., the geographic association between "cold chain vehicle location" and "consumables inventory location") and temporal dependencies (e.g., the temporal constraints of "order creation-review-shipping"), generating a desensitized semantic data stream containing spatiotemporal features, providing key input for subsequent time management modules.

[0035] Therefore, the generated desensitized semantic data stream contains complete business logic (entity identification, security level, operation log) and multimodal semantic features (text semantics, image features, voice commands), providing high-quality data input for subsequent steps (such as time constraint annotation and medical knowledge injection). For example, step 3 can accurately annotate the time constraint level of the "order creation-review-delivery" event chain based on the timestamp and entity identification in the desensitized data stream; step 4 can link the entity identification to specific medical attributes (such as the biocompatibility standard of the prosthesis).

[0036] In a specific application scenario, an exemplary implementation of step 1 above is described as follows.

[0037] When performing localized homomorphic encryption, homomorphic encryption algorithms (such as BFV) are used on raw medical business data (such as basic patient information, order details, and private areas in inventory images). This encryption is completed locally at the data provider, ensuring that the ciphertext data supports "secret computing" when processed by federated nodes (for example, desensitization of ciphertext data does not leak the original information). The encrypted data retains key business identifiers (such as consumable IDs and order timestamps), but private fields (such as patient names and hospital addresses) are masked.

[0038] When performing distributed desensitization on federated nodes, a federated learning architecture is constructed, distributing encrypted ciphertext data to each participating federated node (e.g., hospital, distributor, and logistics nodes). Each node trains a desensitization model (e.g., K-anonymity, data perturbation algorithms) based on local data. The model is collaboratively updated via the federated parameter server to prevent cross-domain transmission of raw data. Furthermore, a Shapley value algorithm is used to dynamically allocate privacy budgets, applying stronger desensitization to highly sensitive data (e.g., patient IDs) (e.g., generalizing to "patient-20250611-001") while only standardizing the format of less sensitive business data (e.g., "left knee prosthesis" to "KneeProsthesis-L").

[0039] When generating traceability tags, blockchain (such as Hyperledger Fabric) is used to record desensitized operation logs, including data sources (such as "Hospital A-Order ID-20250611"), desensitization algorithms (such as "K-anonymity-ε=0.5"), and processing timestamps, to form an unalterable traceability chain.

[0040] Specifically, in one application scenario, for example, a regional medical alliance processes an orthopedic implant order, involving patient order data from tertiary hospital A, inventory RFID images from distributor B, and voice delivery instructions from logistics provider C. The implementation process of the above solution is as follows:

[0041] 1. Hospital A homomorphically encrypts the patient name "Zhang San" in the order, and the ciphertext is displayed as "PAT-20250611-001", while retaining the consumable ID "PRO-1234" and the urgency level "Level-1";

[0042] 2. Distributor B desensitizes the UDI code "690123456789" in the RFID image at the edge node, retaining only the last four digits "6789" and associating it with the consumable model "knee prosthesis."

[0043] 3. Each node uploads the anonymized data and operation logs (e.g., "Hospital A-2025-06-11 10:00:00-Apply K-anonymity") to the chain, generating an anonymized data set with traceability tags:

[0044] {

[0045] "entity_id":"PRO-1234",

[0046] "security_level":"Level-2",

[0047] "desensitization_log":[

[0048] {"node":"Hospital A","algorithm":"Homomorphic Encryption + K-Anonymity","time":"2025-06-11T10:00:00Z"},

[0049] {"node":"Dealer B","algorithm":"Image Desensitization + UDI Truncation","time":"2025-06-11T10:05:00Z"} ]

[0051] }

[0052] When performing multimodal GAN ​​semantic embedding processing, for the text modality: the BERT-Med pre-trained model (fine-tuned based on medical corpus) is used to encode the order text and extract semantic features such as "consumables model - surgery type - timeliness requirement" (for example, "cervical dislocation surgery → urgent delivery required" generates a 256-dimensional semantic vector). For the image modality: YOLOv8 is used to detect the UDI identification area in the RFID image, which is converted into a text sequence after OCR recognition. The image semantic vector is then generated using the Vision Transformer. For the voice modality: the CTC (Connectionist Temporal Classification) model is used to convert voice commands into text, and then Tacotron2 is used to generate the voice semantic vector.

[0053] Furthermore, generative adversarial network alignment is performed. Based on the generator, the model processes the data of each modality separately to generate cross-modal shared semantic vectors (for example, mapping the semantic meaning of "urgent" in text, image, and speech to the same vector space coordinates). Based on the discriminator, the model uses a contrastive loss function to force cross-modal shared semantic vectors (such as the text description and image features of "left knee prosthesis") to cluster in a shared space, improving semantic consistency (for example, cosine similarity ≥ 0.9).

[0054] For example, in a specific application scenario, the multimodal data of "urgent order for left knee prosthesis" is processed (the order text is "left knee prosthesis PRO-1234, emergency surgery requires 10 minutes to ship out", RFID image shows inventory status, and voice command is "priority processing PRO-1234").

[0055] 1. After the order text is encoded by BERT-Med, the generated vector contains features such as "PRO-1234", "urgent", and "10 minutes";

[0056] 2. The RFID image is processed by YOLOv8 to locate the UDI area, OCR recognizes it as "PRO-1234", and Vision Transformer generates an image vector;

[0057] 3. Multimodal GAN ​​forces the text and image vectors to align on the "PRO-1234" and "Urgent" dimensions, generating a cross-modal shared semantic vector: [0.85, 0.92, 0.78, ...]. The dimensions include semantics such as consumable ID, timeliness level, and inventory status.

[0058] When processing entity associations in a graph attention network, during the graph structure construction phase, nodes contain business entities (such as consumable IDs, order IDs, and logistics order numbers) and attributes (such as security levels and timestamps) from the desensitized data. Edges define relationships between entities (such as "order contains consumables" and "logistics order number is associated with shipment time"). Edge weights are initialized using cosine similarity or domain knowledge (such as "urgent order → priority shipment" weight + 0.2).

[0059] When processing the graph attention mechanism, the cross-modal shared semantic vector of each node is used to calculate its association strength with neighboring nodes through multi-head attention, and the edge weight is dynamically updated (for example, the association weight between "PRO-1234" and "Urgent Order ID-20250611" is increased to 0.95 after attention calculation), thereby obtaining a multimodal entity mapping table that records "entity ID-associated entity-association weight-semantic feature".

[0060] In a specific application scenario, for example, the order text, RFID image, and voice command entity of "left knee prosthesis PRO-1234" are associated.

[0061] 1. Build a graph structure with nodes including "PRO-1234", "Order ID-20250611", and "Voice Command-001";

[0062] 2. The graph attention network calculates the association weight between "PRO-1234" and "Order ID-20250611":

[0063] Text vector similarity: 0.92 (based on “PRO-1234” keyword matching);

[0064] Timestamp association: If the time interval between order creation time and voice command is less than 2 minutes, the weight is +0.05;

[0065] Final weight: 0.97;

[0066] 3. Generate multimodal entity mapping table:

[0067] {

[0068] "source_entity":"PRO-1234",

[0069] "target_entity":"Order ID-20250611",

[0070] "association_weight":0.97,

[0071] "semantic_features":["urgent","shipping within 10 minutes","sufficient stock"]

[0072] }

[0073] When performing CTC-GNN fusion network feature fusion, CTC voice timing alignment is performed to detect endpoints and frame voice commands, and the CTC model is used to generate time-aligned text sequences (for example, aligning "shipping within ten minutes" to the timestamps 10:00:00-10:00:05). When performing GNN feature fusion:

[0074] The input layer extracts entity features from the multimodal entity mapping table (such as text semantic vectors, image UDI features, and voice command temporal features). The propagation layer uses graph convolution operations (GCN) to infer temporal dependencies between entity features (such as the time interval between "order creation → review completion → delivery"). Medical timeliness rules (such as urgent orders requiring a delivery time of ≤ 10 minutes) are introduced as edge constraints to facilitate feature fusion and cross-media mapping. The output layer generates a desensitized semantic data stream consisting of "entity ID - multimodal features - timestamp - security level - traceability tag."

[0075] In a specific application scenario, the multimodal features of the "left knee prosthesis PRO-1234" are integrated to generate a desensitized semantic data stream that can drive supply chain decisions. The following is an example implementation:

[0076] 1. The voice command "Export within 10 minutes PRO-1234" is aligned to the timestamp 10:00:00 through CTC, generating the text sequence "Urgent delivery, ID-PRO-1234";

[0077] 2. GNN fusion network input:

[0078] Text features: "PRO-1234", "urgent", "10 minutes";

[0079] Image features: The last four digits of the UDI code are "6789", and the inventory quantity is 5 pieces;

[0080] Voice features: timestamp 10:00:00, command type "out of warehouse";

[0081] 3. After graph convolution calculation, generate desensitized semantic data stream:

[0082] {

[0083] "entity_id":"PRO-1234",

[0084] "multimodal_features":[

[0085] [0.85,0.92,...],#text semantic vector

[0086] [0.78,0.88,...],#Image feature vector

[0087] [0.90,0.85,...]#Speech time series feature vector

[0088] ],

[0089] "timestamp":"2025-06-11T10:00:00Z",

[0090] "security_level":"Level-1",

[0091] "traceability":"Hospital A→Distributor B→Logistics C"

[0092] }

[0093] Optionally, in step 3, based on the constructed medical time constraint rule library, the "order creation-review-delivery" event chain is constrained and a dynamic relationship description with time constraints is generated, including:

[0094] Step 31: Based on the surgery type time limit threshold table in the medical time limit constraint rule library, perform time window threshold labeling processing on the "order creation-review-delivery" event chain to obtain a time limit level labeling event chain;

[0095] Step 32: Perform temporal logic compliance verification on the timeliness level marking event chain to obtain a temporal compliance evaluation event chain;

[0096] Step 33: Based on the resource scheduling conflict avoidance rules in the medical time constraint rule library, the time compliance evaluation event chain is subjected to resource constraint association processing to generate a dynamic relationship description with time constraints.

[0097] Optionally, step 31, based on the surgery type time limit threshold table in the medical time limit constraint rule library, performs time window threshold labeling processing on the "order creation-review-warehouse delivery" event chain to obtain a time limit level labeling event chain, including:

[0098] Step 311: parse the time stamp from the "order creation - review - delivery" event chain and match it with the surgery type time threshold table to mark the timeliness level and compliance baseline of the event chain;

[0099] Step 312: Generate an event chain with annotated timeliness level according to the timeliness level and compliance baseline of the annotated event chain.

[0100] Optionally, step 32, performing temporal logic compliance verification on the timeliness level marking event chain to obtain a temporal compliance evaluation event chain, includes:

[0101] Step 321: Based on the LTL linear temporal logic parsing engine and rule priority queue, perform executable logic conversion and priority sorting on the multi-stage temporal logic rule set to generate a prioritized temporal constraint rule expression;

[0102] Step 322: Perform phase time interval analysis and risk factor weighting on the timeliness level labeled event chain to generate a time feature vector with risk weights.

[0103] Step 323: Based on the priority-based timing constraint rule expression, perform timing compliance scoring and dynamic compensation calculation on the time feature vector with risk weight to obtain a timing compliance assessment event chain.

[0104] Optionally, step 33, based on the resource scheduling conflict avoidance rules in the medical time constraint rule library, performs resource constraint association processing on the time compliance evaluation event chain to generate a dynamic relationship description with time constraints, including:

[0105] Step 331: Based on the configured resource scheduling rule graph database and conflict priority rules, perform graph-structured parsing and conflict resolution processing on the resource scheduling conflict avoidance rules to generate a resource constraint knowledge graph;

[0106] Step 332: Based on the multi-source resource state feature extractor, perform resource demand analysis and state association processing on the time sequence compliance assessment event chain to generate a resource-timeliness association feature vector;

[0107] Step 333: Based on the constructed fuzzy logic fusion decision, the resource constraint knowledge graph is used to generate a scheduling strategy and perform conflict compensation processing on the resource-timeliness association feature vector to generate a dynamic relationship description with timeliness constraints.

[0108] In summary, considering the significant scenario differences (e.g., emergency surgery requires a minute-level response), process relevance (order review timeouts directly affect delivery time), and resource competition (critical resources such as cold chain vehicles often face multi-order scheduling conflicts) in the timeliness management of the medical consumables supply chain, existing technologies rely on fixed time thresholds and manual rules, which cannot meet the dynamic and complex nature of medical scenarios. This solution, through a three-level process of "threshold labeling - timing verification - resource linkage", has the following technical benefits:

[0109] Different surgeries have significantly different requirements for consumable response times (for example, emergency cervical dislocation surgery requires delivery within 10 minutes, while routine joint replacement surgery can accept 30 minutes). The surgery-type timeliness threshold table (step 311) presets a mapping between "surgery type-timeliness level-time window" (e.g., Level-1 corresponds to ≤10 minutes, Level-2 corresponds to ≤30 minutes). This enables differentiated management of emergency, sub-emergency, and routine surgeries, avoiding the resource waste and timeliness violations caused by traditional fixed thresholds (e.g., emergency orders delayed due to loose thresholds, or routine orders excessively occupying resources due to strict thresholds). By parsing timestamps from the event chain (order creation, review completion, delivery time) and matching them to the threshold table (step 311), timeliness levels and compliance baselines can be automatically labeled (e.g., "cervical surgery → Level-1 → total delivery time ≤10 minutes"), providing a clear quantitative standard for subsequent time sequence compliance verification and addressing the subjectivity and inconsistency of manually defined baselines.

[0110] After generating the timeliness level labeled event chain (step 312), "order creation-review-delivery" is no longer an isolated link, but an associated event chain with timeliness attributes (for example, timeout in the review link will affect the compliance score of the delivery link), providing structured input for the timing logic verification in step 32, and realizing the upgrade from single-link monitoring to full-process timing dependency analysis (for example, detecting "whether review timeout will inevitably lead to delivery timeout").

[0111] Medical processes often involve temporal logic, such as "review must be completed within 5 minutes of order creation" and "delivery must be performed within 5 minutes of review completion." LTL (Linear Temporal Logic) can convert natural language rules into executable formal expressions (such as `G(order created → F[≤5min] review completed)`). This ensures rule conflicts through model checking (step 321), resolving issues where traditional rule engines cannot handle complex temporal dependencies (such as the sequential constraint of "review before delivery").

[0112] High-risk surgeries (such as cervical spine surgery) have a lower tolerance for timeliness deviations. Step 322 introduces a medical risk factor table (e.g., cervical spine surgery risk factor = 1.5) to weight time intervals, allowing the compliance baseline to dynamically adjust with the risk level (e.g., the review time interval for Level-1 orders is shortened from 5 minutes to 3 minutes), avoiding overly strict control in low-risk scenarios and insufficient control in high-risk scenarios.

[0113] Step 323 optimizes process efficiency while ensuring compliance through time sequence compliance scoring (e.g., 10 points deducted for every minute of delay) and dynamic compensation calculations (e.g., triggering physical logistics expediting due to delays). For example, if an urgent medical order is delayed by 2 minutes, expedited logistics can reduce the shipping time by 3 minutes, and the final total delivery time still meets Level-1 requirements. This avoids the inefficient decision-making that results from strict compliance practices, such as "better to do better than to do better."

[0114] Resource scheduling conflict avoidance rules in the medical time-efficiency constraint rule library (such as "Level-1 orders prioritize cold chain vehicles") often conflict (the same cold chain vehicle is used by multiple Level-1 orders). Step 331 uses a graph database to construct a "timeliness level-resource type-scheduling strategy" ternary relationship graph, uses graph pattern matching to detect conflicts, and combines medical risk weights (cervical spine surgery priority > joint replacement surgery) to resolve conflicts and generate a conflict-free resource constraint knowledge graph. This improves conflict detection efficiency 20 times compared to traditional databases, ensuring conflict-free allocation of emergency surgery resources.

[0115] Step 332 uses a multi-source resource status feature extractor (such as a real-time inventory API and a logistics resource pool interface) to associate the resource requirements of the timing compliance assessment event chain (e.g., "Level-1 order requires 5 left knee prostheses") with the resource status (2 units in stock at the Beijing warehouse, 5 units in the Tianjin warehouse). This generates a resource-timeliness association feature vector (e.g., [Level-1, Tianjin warehouse inventory score 0.9, 2 cold chain vehicles available]), solving the problem of traditional scheduling systems blindly allocating resources based on experience.

[0116] Step 333 uses fuzzy logic fusion decision-making. When multiple feasible strategies exist for the resource-timeliness association feature vector (e.g., "local warehouse delivery + standard logistics" vs. "remote warehouse transfer + cold chain expedited delivery"), parameters such as inventory turnover rate and logistics timeliness deviation are input to generate the optimal strategy (e.g., "Tianjin warehouse has sufficient inventory and cold chain trucks available → transfer + expedited delivery"). For example, if the local warehouse has insufficient inventory for a Level-1 order, but the remote warehouse transfer timeliness meets the required timeliness, fuzzy logic can automatically select "transfer + cold chain expedited delivery," thus avoiding the lag and subjectivity of manual decision-making.

[0117] Exemplarily, the technical implementation of the above step 3 is described in detail as follows.

[0118] When performing timestamp parsing and threshold matching, extract the key timestamp (order creation time) from the event chain. , Review completion time , delivery time ), calculation phase time interval 、 The medical time constraint rule library has a built-in operation type time threshold table, which defines the time level (Level-1 to Level-3) and compliance baseline of different operation types (e.g. "cervical dislocation operation" corresponds to Level-1, and the total time for delivery is minutes; "knee replacement" corresponds to Level-2, with a threshold of 20 minutes. Using an LSTM time series model or rule engine to match surgery types and thresholds, the event chain's timeliness level and compliance baseline are annotated (for example, an emergency surgery triggers Level-1, generating a "warehouse delivery timeout warning threshold = 10 minutes").

[0119] When generating an event chain labeled with timeliness levels, the timestamp, timeliness level, and compliance baseline are encapsulated as structured data, and contextual information such as surgery type and consumables risk level are added to form an event chain with timeliness labels.

[0120] Example description:

[0121] The orthopedics department of a tertiary hospital received an emergency surgery order for cervical dislocation, involving the supply chain process of "left knee prosthesis PRO-1234". Implementation process:

[0122] 1. Parsing event chain timestamps: (Order creation), (Audit completed), (Out of stock), total length 12 minutes.

[0123] 2. The procedure type "Cervical Dislocation" matches Level 1 in the threshold table. The compliance baseline is "Total delivery time ≤ 10 minutes." The timeliness level is marked as "Level 1 (Emergency)." The timeout warning threshold is 10 minutes.

[0124] 3. Generate an event chain for timeliness level marking:

[0125] {

[0126] "event_chain": "Order creation → review → delivery",

[0127] "surgery_type":"cervical dislocation",

[0128] "timeliness_level":"Level-1",

[0129] "compliance_threshold":"10 minutes",

[0130] "timestamps":["10:00:00","10:04:00","10:12:00"]

[0131] }

[0132] When performing LTL logic conversion and rule priority sorting, the ANTLR syntax parser is used to convert natural language timing rules (such as "the review must be completed within 5 minutes after the order is created") into an LTL linear temporal logic formula: G(order created → F[≤5min] review completed).

[0133] Build a rule priority queue (for example, the "outbound within 10 minutes" rule for Level-1 orders has a higher priority than the "outbound within 10 minutes" rule for Level-2 orders). Use model checking technology (such as NuSMV) to verify that there are no conflicts in the rules. Generate a priority timing constraint rule expression (for example, rule ID-001: ).

[0134] When performing time interval analysis and risk factor weighting, calculate the stage time interval Minutes (review time), Minutes (delivery time), a medical risk factor table (cervical spine surgery risk factor = 1.5) is introduced, and time offsets are weighted (actual allowable interval = standard threshold × risk factor, for example, if the audit standard threshold is 5 minutes → 7.5 minutes is allowed). Time series features are extracted using a bidirectional LSTM to generate a time feature vector with risk weights: .

[0135] Compliance scoring and dynamic compensation calculations are performed based on LTL rule expressions: 10 points are deducted for every minute exceeding the threshold (e.g., if delivery exceeds the threshold by 2 minutes, -20 points). The penalty intensity is adjusted based on the risk-weighted threshold (a risk factor of 1.5 increases the allowable delay and the penalty threshold). Dynamic compensation strategies are triggered (e.g., if the delay exceeds 3 minutes, a "physical expedited logistics" recommendation is automatically generated, with a 3-minute compensation time limit). This example demonstrates compliance verification for the aforementioned cervical dislocation surgery event chain.

[0136] 1.LTL rule conversion: "Level-1 order delivery time ≤ 10 minutes" is converted to , priority P1.

[0137] 2. Time feature vector: Minutes (compliant), minutes (exceeding the standard threshold by 3 minutes, and the allowed threshold after risk weighting is 7.5 minutes → exceeding by 0.5 minutes).

[0138] 3. Compliance score: +10 points for the review phase (1 minute earlier), -5 points for the delivery phase (0.5 minutes later), total score +5 points; compensation suggestion generated: "Trigger physical logistics expedited, expected to shorten delivery time by 2 minutes."

[0139] 4. Timing compliance assessment event chain:

[0140] {

[0141] "event_chain": "Order creation (0min) → Review (4min) → Delivery (12min)",

[0142] "standard_thresholds": "Review ≤ 5 minutes, delivery ≤ 5 minutes (total ≤ 10 minutes)",

[0143] "risk_weighted_thresholds": "Review ≤ 7.5min, delivery ≤ 7.5min (total ≤ 15min)",

[0144] "stage_scores":{"Audit":+10,"Output":-5},

[0145] "compensation": "Expedite physical logistics, time compensation 2 minutes"

[0146] }

[0147] When constructing the resource constraint knowledge graph, we used the Neo4j graph database to store resource scheduling conflict avoidance rules and build a ternary relationship between "timeliness level - resource type - scheduling strategy" (e.g., "Level-1 → priority allocation of cold chain vehicles"). We detected rule conflicts through graph pattern matching (e.g., a cold chain vehicle being requested by two Level-1 orders at the same time) and resolved them based on medical risk weights (cervical spine surgery > joint replacement), generating a conflict-free resource constraint knowledge graph.

[0148] When extracting resource-timeliness association features, we extract the timeliness level (Level-1), compliance score (+5 points), and compensation suggestion (physical expediting) from the event chain. Combined with real-time inventory (Beijing warehouse inventory = 2, Tianjin warehouse = 5), and logistics resources (3 cold chain vehicles available), we use GNN to calculate resource demand priority (for example, the association weight of "Tianjin warehouse allocation + cold chain vehicle" is 0.92). This generates a resource-timeliness association feature vector: .

[0149] When generating scheduling strategies and conflict compensation, a fuzzy logic fusion decision is used to input resource characteristics and timeliness requirements to generate a scheduling strategy (e.g., "Inventory < 3 and Level-1 → triggers a transfer from a remote warehouse"). The compliance score from step 32 is associated to generate a dynamic relationship description with timeliness constraints, including a resource scheduling plan, timeliness compensation measures, and compliance instructions. For example, in the resource scheduling scenario for the cervical dislocation surgery order (2 items in stock in the Beijing warehouse, 5 required):

[0150] 1. Resource constraint knowledge graph matching rule: "Level-1 order inventory is insufficient → Tianjin warehouse allocation + cold chain vehicle", no conflict (Tianjin warehouse has sufficient inventory).

[0151] 2. Resource-Timeliness Feature Vector: Level-1, Inventory Score 0.8 (Tianjin warehouse available), Logistics Score 0.9 (Cold Chain Vehicle available).

[0152] 3. Fuzzy logic decision-making: Generate a scheduling strategy: "Allocate 5 pieces from the Tianjin warehouse, using cold chain vehicle ID-C001." Time compensation: "Estimated transit time is 8 minutes, total outbound time is 12 + 8 = 20 minutes → But if expedited delivery is used, the transit time can be reduced to 5 minutes. Is the total delivery time of 17 minutes ≤ the risk-weighted threshold of 15 minutes?" (The logic needs to be corrected here to ensure compliance after compensation. In this example, it is assumed that expedited delivery reduces the total delivery time to ≤ 10 minutes).

[0153] 4. Dynamic relationship description:

[0154] {

[0155] "scheduling_strategy":"Tianjin warehouse allocation + cold chain expedited",

[0156] "timeliness_constraint":"Level-1 (≤10min outbound)",

[0157] "resource_usage":{

[0158] "inventory":"Tianjin warehouse knee prosthesis=5",

[0159] "logistics":"Cold chain vehicle C001, estimated transportation time 5 minutes"

[0160] },

[0161] "compliance_status": "Total time after compensation is 10 minutes (12 minutes for shipping + 5 minutes for transportation → the actual time should be spent on shipping. This example focuses on compliance during the shipping phase)"

[0162] }

[0163] Optionally, in step 4, medical consumables knowledge is injected into the dynamic relationship description with time constraints to generate a medical consumables supply chain description containing "business entity-medical attribute", including:

[0164] Step 41: Perform business entity-medical concept mapping on the dynamic relationship description with time constraints to generate a cross-domain entity association table;

[0165] Step 42: extract and fuse professional attribute features from the cross-domain entity association table to generate a medical attribute enhanced feature vector;

[0166] Step 43: Compliance rules are injected and structured into the medical attribute enhanced feature vector to generate a medical consumables supply chain description containing "business entity-medical attribute".

[0167] Optionally, step 41, performing business entity-medical concept mapping processing on the dynamic relationship description with time constraints to generate a cross-domain entity association table, includes:

[0168] Step 411: extract business entities and perform type annotation processing on the dynamic relationship description with time constraints to generate a business entity feature set;

[0169] Step 412: Perform medical concept matching and ambiguity resolution on the business entity feature set to generate a candidate concept matching list;

[0170] Step 413: Perform cross-domain mapping verification and confidence calculation on the candidate concept matching list to generate a cross-domain entity association table.

[0171] Optionally, step 42, extracting and fusing professional attribute features from the cross-domain entity association table to generate a medical attribute enhanced feature vector, includes:

[0172] Step 421: Perform medical standard parsing and attribute extraction on the cross-domain entity association table to generate a structured medical attribute set;

[0173] Step 422: Perform business-medical feature fusion and weight calculation on the structured medical attribute set to generate a weighted fusion feature matrix;

[0174] Step 423: Perform cross-dimensional normalization and vector generation processing on the weighted fusion feature matrix to generate a medical attribute enhanced feature vector.

[0175] Optionally, in step 43, compliance rule injection and structural processing are performed on the medical attribute enhanced feature vector to generate a medical consumables supply chain description containing "business entity-medical attribute", including:

[0176] Step 431: Perform compliance clause mapping and logic rule generation processing on the medical attribute enhanced feature vector to generate an executable compliance rule set;

[0177] Step 432: Perform business process constraint association and risk score calculation on the executable compliance rule set to generate a compliance-business association matrix;

[0178] Step 433: Perform semantic modeling and format conversion on the compliance-business association matrix to generate a medical consumables supply chain description including "business entity-medical attribute".

[0179] The medical consumables supply chain involves complex expertise (such as biocompatibility and sterilization standards) and strict regulatory requirements (such as UDI traceability and cold chain transportation specifications). However, traditional approaches suffer from issues such as "disconnection between business entities and medical concepts," "inability to structure the application of professional attributes," and "inefficient manual configuration of compliance rules." This solution, through a three-level process of "entity mapping, attribute fusion, and compliance modeling," offers the following technical benefits:

[0180] The "left knee prosthesis ID-1234" in the business system is associated with the "knee prosthesis biocompatibility standard ISO 11756" in the medical field, but the two belong to different semantic spaces. Step 41 establishes a cross-domain association of "business entity → medical concept" through entity extraction (411) - concept matching (412) - mapping verification (413). This solves the semantic difference between "prosthesis" being an inventory unit in business and "implant" in medical treatment, ensuring that supply chain operations can call on professional knowledge (such as selecting a sterilization process based on biocompatibility standards).

[0181] The medical field is full of specialized terminology (e.g., "sterilization cycle" vs. "disinfection time"). Step 412 uses the TransE embedding model combined with medical context features (e.g., Level-1 priority matches "rapid sterilization standard") to accurately map "left knee prosthesis" to the "Orthopedic Implant Sterilization Specification WS 310.2" rather than general device standards. This avoids the risk of misuse of consumables due to terminology misunderstandings (e.g., using non-sterile prostheses in surgery).

[0182] The business entity feature set generated in step 411 (e.g., "Left Knee Prosthesis ID-1234, Type = Orthopedic Implant") serves as the foundation for subsequent knowledge injection. Without annotated entity types, the system would be unable to recognize that "prosthesis" requires adherence to implant-specific standards (e.g., requiring a UDI), leading to compliance vulnerabilities. Mapping verification (step 413) ensures reliable associations through regulatory evidence (e.g., provisions in the Medical Device Classification Catalog). Only mappings with a confidence level ≥ 0.95 are considered to prevent erroneous associations from contaminating the knowledge base.

[0183] Medical standards (such as WS 310.2 Sterilization Specification) are often written in natural language. Step 421 uses a fine-tuned BERT-Med model combined with regular expressions to extract numerical attributes (temperature = 134 ± 2°C, cycle = 45 minutes) from "sterilization temperature 134 ± 2°C, hold 45 minutes," generating a structured set of medical attributes. This is the prerequisite for implementing "automatic sterilization temperature verification" and "intelligent sterilization cycle planning," addressing the inefficiencies (interpretation of a single standard takes 30 minutes) and high errors (misreading rate of 15% within the temperature range) associated with traditional methods that rely on manual interpretation of standards.

[0184] In step 422, when parsing medical standards and extracting attributes from the cross-domain entity association table, the knowledge-enhanced GNN fuses business characteristics (Level-1 timeliness level) with medical attributes (sterilization temperature 134±2°C) to calculate the weight associated with "timeliness level → sterilization cycle" (e.g., the sterilization cycle weight for Level-1 orders + 0.2). For example, urgent orders are automatically matched with the "rapid sterilization process" (with a cycle compressed to 40 minutes), balancing timeliness and sterilization effectiveness and avoiding the inefficiency of "urgent orders waiting for conventional sterilization to complete" caused by fixed sterilization processes.

[0185] In step 423, when performing cross-dimensional normalization and vector generation on the weighted fused feature matrix, numerical (temperature) and rule-based (sterilization label verification) attributes are normalized (e.g., mapping 2-8°C to [0,1]), generating a 256-dimensional medical attribute-enhanced feature vector. This serves as the foundation for subsequent compliance rule generation (step 43) and knowledge graph construction (step 5), ensuring that attributes of different modalities (text descriptions, numerical parameters, and compliance rules) are uniformly processed. For example, this allows machine learning models to directly determine, using vectors, whether cold chain vehicle transportation meets the 2-8°C requirement.

[0186] In step 431, when mapping compliance clauses and generating logical rules for the medical attribute-enhanced feature vector, the "Medical Device Supervision and Administration Regulations" requirement, "implants must be accompanied by a UDI," is converted into the first-order logical expression `∀x(Implant(x)→hasUDI(x))` and associated with the business entity "Left Knee Prosthesis ID-1234," generating the executable rule "Verify UDI code before shipment." This upgrades compliance verification from "manually comparing regulations one by one" to "automatically blocking shipments of prostheses without UDIs," achieving a 100% blocking rate for illegal operations and resolving the issues of traditional manual verification, such as a high missed detection rate (approximately 30%) and slow response time (taking 10 minutes per order).

[0187] In step 432, when linking the executable compliance rule set to business process constraints and calculating risk scores, the executable compliance rules are embedded into the business process through a risk scoring model (e.g., temperature control exceeding the range by +2°C → infection risk +0.05%) and a rule-process mapping diagram (e.g., "UDI verification" is bound to the order review node). For example, the review node automatically triggers UDI code verification; if the code is missing, the product is prohibited from entering the shipping process. This achieves "pre-emptive prevention" rather than "post-event auditing," complying with the "Regulations on the Prevention of Medical Disputes"' requirement for real-time control of high-risk operations.

[0188] When semantic modeling and format conversion are performed on the compliance-business association matrix in step 433, the resulting JSON-formatted description (including business entities, medical attributes, and compliance rules) can be directly integrated into the hospital's HIS system, logistics management system, and regulatory platform. For example, the hospital procurement system uses "business entity-medical attribute" to quickly screen consumables that meet surgical requirements (e.g., automatically filtering prostheses that do not meet rapid sterilization standards for cervical spine surgery). The regulatory platform uses "compliance rules-evidence chain" to quickly audit supply chain compliance, eliminating the need for manual integration of multi-source data and increasing efficiency by 80%.

[0189] Preferably, exemplary implementation details of the above step 4 are described as follows.

[0190] For example, when extracting and annotating business entities, the BERT-Med+CRF named entity recognition model (fine-tuned on 100,000 orthopedic surgery order texts) was used to extract business entities from dynamic relationship descriptions (e.g., "left knee prosthesis ID-1234," "physical cold chain vehicle") and annotate the entity types (consumables / logistics / equipment). A dictionary of entity types was constructed (e.g., "orthopedic implants" includes subcategories such as "knee prosthesis" and "bone screws"), and rule matching was used to supplement the recognition of specialized terminology (e.g., "UDI" is automatically annotated as "Unique Device Identifier").

[0191] When matching and resolving medical concepts, the TransE medical entity embedding model is used to vectorize medical concepts (such as "ISO 11756 biocompatibility standard"). Business entities are then matched to medical concepts using cosine similarity (threshold ≥ 0.8) (e.g., "left knee prosthesis" matches "knee prosthesis biocompatibility standard"). Medical context features are introduced (Level-1 timeliness level → prioritizes matching concepts related to emergency sterilization), and an attention mechanism is used to resolve ambiguity (e.g., distinguishing between the different medical meanings of "prosthesis" and "protective gear").

[0192] When verifying and calculating cross-domain mapping confidence, a three-tiered validation rule is designed (terminology consistency, temporal relevance, and evidence chain integrity). For example, the system verifies that "left knee prosthesis" complies with the "Nomenclature of Orthopedic Implants" and links to the corresponding ISO standard clause. DS evidence theory is used to integrate multi-source verification results to calculate mapping confidence (e.g., terminology consistency 0.4 + temporal relevance 0.3 + evidence completeness 0.3 = total confidence 0.97). Low-confidence mappings trigger manual review.

[0193] For example, in a specific application scenario, the dynamic relationship description of "left knee prosthesis ID-1234" is processed (Level-1 timeliness level, requiring urgent delivery).

[0194] 1. Entity extraction: Extract “Left Knee Prosthesis ID-1234” (Type = Orthopedic Implant) and “Physical Cold Chain Vehicle” (Type = Logistics Equipment) from the description.

[0195] 2. Concept matching: "Left knee prosthesis" was matched to "ISO 11756 biocompatibility standard" (similarity 0.92) and "WS 310 sterilization specification" (similarity 0.88) through the TransE model.

[0196] 3. Mapping verification:

[0197] Terminology consistency: "Left knee prosthesis" conforms to the definition of "orthopedic implant" in the Medical Device Classification Catalogue;

[0198] Timeliness relevance: Level-1 timeliness level is associated with "Rapid Sterilization Standard", and the mapping weight of "WS 310" is enhanced;

[0199] Generate a cross-domain entity association table:

[0200] {

[0201] "business_entity":"Left Knee Prosthesis ID-1234",

[0202] "medical_concepts":[

[0203] {

[0204] "concept":"ISO 11756 Biocompatibility",

[0205] "confidence":0.97,

[0206] "evidence":"Article 4.2 of the Standard for Materials of Orthopedic Implants"

[0207] },

[0208] {

[0209] "concept":"WS 310.2 sterilization temperature 134±2℃",

[0210] "confidence":0.95,

[0211] "evidence": "Order timeliness level Level-1 matches rapid sterilization requirements"

[0212] } ]

[0214] }

[0215] When parsing and extracting medical standards, we used a fine-tuned BERT-Med model to parse medical standard documents (such as the WS 310.2-2016 Sterilization Specification) and combined it with regular expressions to extract numerical attributes (such as "Sterilization temperature 134±2°C" and "Transport temperature 2-8°C"). We also used an entity relationship extraction model to establish associations between attributes and entities (such as "Knee prosthesis → Sterilization temperature 134±2°C"), generating a structured medical attribute set (attribute name, value, unit, and evidence source).

[0216] When integrating business and medical features and calculating weights, a knowledge-enhanced GNN network was constructed, inputting business features (Level-1 timeliness level, Tianjin warehouse allocation scheduling plan) and medical attributes (sterilization temperature, transportation temperature control). A graph attention mechanism was used to calculate association weights (for example, "Tianjin warehouse allocation → transportation temperature 2-8°C" has a weight of 0.92). The medical risk matrix (cervical spine surgery risk factor of 1.5) was incorporated to dynamically adjust weights (in high-risk scenarios, the weight of the temperature control attribute was increased by 30%).

[0217] When performing cross-dimensional normalization and vector generation, numeric attributes (such as temperature) are normalized using Min-Max normalization (2-8°C is mapped to [0, 1]), and rule-based attributes (such as sterilization label verification) are encoded using one-hot encoding. Feature weighting is combined with domain knowledge weights (orthopedic implants = 0.7), and principal component analysis (PCA) is used to reduce the dimensionality to 256, generating a feature vector consisting of "business-medical-weight-risk." In one embodiment, the medical attributes of "Left Knee Prosthesis ID-1234" are extracted and integrated with the business features. The process is as follows:

[0218] 1. Medical attribute extraction: Extract "biocompatibility test cycle 72 hours" from the ISO 11756 standard, and extract "sterilization temperature 134±2℃, cycle 45 minutes" from the WS 310 standard.

[0219] 2. Feature Fusion:

[0220] Business characteristics: Level-1 timeliness rating (normalized value 1.0), Tianjin warehouse transfer (weight 0.8);

[0221] Medical attributes: Sterilization temperature 134±2℃ (normalized value 0.85), transportation temperature 2-8℃ (normalized value 0.92);

[0222] GNN calculates the association weights: "Level-1→Sterilization cycle" has a weight of 0.88, and "Tianjin warehouse allocation→Transportation temperature" has a weight of 0.95.

[0223] 3. Generate medical attribute enhanced feature vector: [

[0225] 1.0,#Level-1 Time Level

[0226] 0.8,#Tianjin warehouse allocation weight

[0227] 0.85,#normalized value of sterilization temperature

[0228] 0.92, #Transport temperature normalized value

[0229] 0.88, #Time-Sterilization Association Weight

[0230] 0.95, #Allocation-Temperature Control Association Weight ]

[0232] When mapping compliance clauses and generating logical rules, a regulatory semantic parsing engine is built to map medical attributes (such as "sterilization temperature 134±2°C") to regulatory clauses (such as Article 5.2 of WS 310.2-2016) and generate first-order logic expressions:

[0233] ∀x(knee prosthesis x→hasSterilizationTemp(x,134±2℃))

[0234] Automatically associate business operations (such as "outbound → verify sterilization temperature records") through the rule template library to form executable compliance rules (rule ID, logical expression, associated attributes, and regulatory source).

[0235] When linking business process constraints and calculating risk scores, a rule-process mapping diagram is constructed, binding compliance rules to business process nodes (e.g., "sterilization temperature verification" is bound to the delivery node). A state transition model is used to verify the rule execution path (if verification is not achieved, delivery is prohibited). A risk quantification model is introduced to calculate risk scores based on attribute deviations (e.g., temperature control out of range +2°C → infection risk +0.05%), generating a "process node-compliance rule-risk score" association matrix.

[0236] During semantic modeling and format conversion, RDF triples are used (business entity - medical attribute - compliance rule). For example, "Left knee prosthesis - must include - UDI" is associated with Article 8.2 of the "Medical Device Supervision and Administration Regulations." A domain template is designed to generate a structured description containing basic business entity information, medical attributes, compliance rules, and risk scores, supporting JSON / XML output. In an exemplary scenario, compliance rules are injected into "Left knee prosthesis ID-1234" and a supply chain description is generated. The technical process is as follows:

[0237] 1. Compliance rule generation:

[0238] "Sterilization temperature 134±2℃" is mapped to Article 5.2 of WS 310.2, generating the rule "Sterilization temperature records must be verified before shipment";

[0239] "Transportation temperature 2-8℃" is mapped to Article 5.2 of the "Cold Chain Management Guidelines", generating the rule "Cold chain vehicles must be used and the temperature must be monitored in real time."

[0240] 2. Risk score calculation: If the temperature control exceeds the range, the infection risk score is increased by 0.05%. Compliance rules are linked to the audit node (verifying the UDI) and the outbound node (verifying the sterilization record).

[0241] 3. Generate structured description:

[0242] {

[0243] "business_entity":{

[0244] "id":"Left Knee Prosthesis ID-1234",

[0245] "type":"Orthopedic Implants",

[0246] "timeliness_level":"Level-1"

[0247] },

[0248] "medical_attributes":{

[0249] "sterilization":{

[0250] "temperature":"134±2℃",

[0251] "cycle":"45min",

[0252] "standard":"WS 310.2-2016"

[0253] },

[0254] "transportation":{

[0255] "temperature":"2-8℃",

[0256] "vehicle_type":"cold chain vehicle"

[0257] }

[0258] },

[0259] "compliance_rules":[

[0260] {

[0261] "rule_id":"RULE-001",

[0262] "description":"Sterilization temperature records must be verified before shipment",

[0263] "risk_level":"High",

[0264] "evidence":"Article 5.2 of WS 310.2-2016"

[0265] },

[0266] {

[0267] "rule_id":"RULE-002",

[0268] "description":"Must use refrigerated trucks for transportation and monitor temperature",

[0269] "risk_level":"Medium",

[0270] "evidence":"Article 5.2 of the Cold Chain Management Guidelines"

[0271] } ]

[0273] }

[0274] Optionally, step 5, performing a "regulatory clause - business entity - medical standard" ternary mapping on the medical consumables supply chain description to generate a medical consumables supply chain knowledge graph includes:

[0275] Step 51: Perform logical formalization and ontology concept mapping on the regulatory clauses in the description of the medical consumables supply chain to generate a regulatory semantic triple set;

[0276] Step 52: extract and verify cross-domain relationships between business entities and medical standards in the description of the medical consumables supply chain to generate a set of business-medical association triples;

[0277] Step 53: Fusion storage and graph processing of the regulatory semantic triple set and the business-medical association triple set are performed to generate a medical consumables supply chain knowledge graph.

[0278] Optionally, in step 51, the regulatory clauses in the description of the medical consumables supply chain are logically formalized and mapped to ontology concepts to generate a set of regulatory semantic triples, including:

[0279] Step 511: Perform semantic parsing and logic formula conversion on the regulatory clause text in the medical consumables supply chain description to generate a regulatory logic expression set;

[0280] Step 512: Perform ontology concept matching and ambiguity resolution on the concepts in the legal logic expression set to generate legal regulation-ontology concept mapping pairs;

[0281] Step 513: Perform semantic modeling and consistency verification on the regulation-ontology concept mapping pair to generate a set of regulation semantic triples.

[0282] Optionally, step 52 is to extract and perform consistency verification on the cross-domain relationships between the business entities and medical standards in the description of the medical consumables supply chain to generate a business-medical association triple set, including:

[0283] Step 521: parse the business entity-medical standard relationship of the medical consumables supply chain description to generate an initial association relationship pair;

[0284] Step 522: Perform weight assignment and risk factor fusion processing on the initial association relationship pairs to generate weighted association relationship pairs;

[0285] Step 523: Perform cross-domain consistency verification and conflict resolution on the weighted association relationship pairs to generate a business-medical association triple set.

[0286] Optionally, step 53, fusing and storing the regulatory semantic triple set and the business-medical association triple set and performing graph processing to generate a medical consumables supply chain knowledge graph, includes:

[0287] Step 531: Perform cross-source data fusion and conflict resolution on the regulatory semantic triple set and the business-medical association triple set to generate a unified semantic space dataset.

[0288] Step 532: Perform hierarchical modeling and relationship optimization on the unified semantic space dataset to generate a structured knowledge graph skeleton;

[0289] Step 533: Perform logical verification and intelligent enhancement processing on the structured knowledge graph skeleton to generate a medical consumables supply chain knowledge graph.

[0290] Considering that the medical consumables supply chain must simultaneously meet regulatory compliance (such as the Medical Device Supervision and Administration Regulations), business collaboration (order-inventory-logistics linkage), and medical professional requirements (biocompatibility, sterilization standards), traditional data management models have core issues such as "disconnection between regulatory provisions and business operations," "separation between medical standards and supply chain processes," and "lack of unified semantics for multi-source data." This solution constructs a reasonable and traceable knowledge graph through a three-level process of "regulatory semanticization, relationship association, and graph fusion," with the following technical benefits:

[0291] Regulatory clauses (such as "implants must be uniquely identified") are expressed in natural language, and machines cannot directly understand their logical constraints. Step 511 uses the RoBERTa-legal medical regulatory fine-tuning model to perform semantic parsing and logical formula conversion on the regulatory clause text in the medical consumables supply chain description. This extracts the subject (implant), action (with unique identifier), and condition (should), and converts them into the first-order logic expression `∀x(Implant(x)→hasUDI(x))`. This enables the system to automatically identify "implants shipped without a UDI" as a violation, addressing the inefficiency of traditional compliance verification, which relies on manual interpretation (manual verification takes 5-10 minutes per order and has a 20% miss rate).

[0292] The term "implant" in the regulation corresponds to the medical ontology concept "OrthopedicImplant." In step 512, using AnchorPROMPT+Incremental Mapping to perform ontology concept matching and ambiguity resolution on the concepts in the regulation's logical expression set, the concept is precisely matched to `http: / / medkg.org / OrthopedicImplant` to avoid confusion with concepts in other domains, such as "oral implants." Without this ontology mapping, the system might mistakenly apply the UDI rule for "orthopedic implants" to the non-medical context of "implantable advertising devices," leading to rule abuse.

[0293] During semantic modeling and consistency verification of the regulatory-ontology concept mapping, step 513 converts regulatory logic into OWL ontology assertions (e.g., `Implant SubClassOf hasUniqueIdentifier some UDI`) to generate RDF triples. This forms the foundation for automated reasoning about regulatory compliance. When the phrase "left knee prosthesis ID-1234 has no UDI code" appears in the graph, the HermiT reasoning engine automatically triggers a violation alert, eliminating the need for manual, complex query statements. This reduces compliance alert response time from minutes to milliseconds.

[0294] The association between the business entity "Left Knee Prosthesis ID-1234" and the medical standard "ISO 11756 Biocompatibility" is not explicitly present in the supply chain data. Step 521 uses the BERT-Med+GCN KE-RE model to parse the business entity-medical standard relationship in the medical consumables supply chain description. It extracts the "Prosthesis-Compliant-Cold Chain Standard" relationship from descriptions such as "Cold Chain Transportation Required." This addresses the limitation of traditional systems that can only process explicit relationships (such as directly marking "Sterilization Required" on orders) and explores implicit compliance requirements (such as biocompatibility indirectly requiring cold chain transportation).

[0295] Step 522 introduces a medical risk matrix (e.g., a 1.5 risk factor for cervical spine surgery). When weighting the initial associations and integrating them with risk factors, the association weight for "Left Knee Prosthesis - ISO 11756" is increased from 0.8 to 0.92. This ensures that core standards for high-risk surgeries (such as sterilization temperature and transport temperature control) are prioritized for verification. Without risk weighting, the system might apply a single standard to consumables for all surgical procedures, leading to compliance vulnerabilities in high-risk scenarios (e.g., consumables for cervical spine surgery are not rigorously verified due to insufficient weighting for temperature control standards).

[0296] Step 523 uses a dual validation mechanism, the rule engine and ontology inference engine, to perform cross-domain consistency verification and conflict resolution on weighted associations. This ensures that contradictory relationships, such as "normal logistics → cold chain standards," are automatically corrected to "normal logistics → room temperature standards." For example, if an order is mistakenly labeled "implant transported by normal logistics," graph verification will identify the ontology constraint that "implants must be transported by cold chain," automatically blocking the scheduling plan and avoiding the risk of consumable failure caused by logistics errors (traditional systems rely on manual inspection, with a 15% miss detection rate).

[0297] The "UDI" at the regulatory layer may be recorded as "Unique Device Identifier" at the business layer. Step 531 uses TransE entity alignment to perform cross-source data fusion and conflict resolution on the regulatory semantic triple set and the business-medical association triple set to identify homologous entities, unify them into `http: / / medkg.org / UniqueDeviceIdentifier`, and resolve naming conflicts according to the "medical standard definition priority" rule (for example, the terminology of the "Medical Device Classification Catalog" shall prevail). This ensures that data from different systems (hospital HIS / distributor ERP / logistics TMS) are interoperable and solves the problem of "inconsistent terminology leading to association failure" in traditional data integration (according to statistics, cross-system terminology ambiguity leads to 30% of data integration failures).

[0298] Step 532 constructs a three-layer architecture of regulatory layer, business layer, and medical layer, for example:

[0299] The regulatory layer stores Article 8.2 of the "Medical Device Supervision and Administration Regulations" and its logical constraints;

[0300] The business layer stores the order, inventory, and logistics information of "left knee prosthesis ID-1234";

[0301] The medical layer stores specific parameters of the ISO 11756 standard.

[0302] This architecture supports cross-layer reasoning (such as "querying all Level-1 orders for implants that do not comply with the ISO 11756 standard"), which is more than 5 times more efficient than querying with a flat data structure.

[0303] Step 533 uses the SPARQL query engine and HermiT inference engine to perform logical verification and intelligent enhancement on the structured knowledge graph skeleton, checking the integrity of the "regulation-business-medical" relationship chain (for example, whether the "implant → regulatory clause → medical standard" chain is closed). If a prosthesis is only associated with a regulatory clause but no corresponding standard, the system automatically marks it as "knowledge missing," triggering a manual completion process to avoid reasoning errors caused by broken relationships in the graph (traditional knowledge bases lack this mechanism, resulting in approximately 25% of relationships having logical gaps).

[0304] By incorporating domain rules such as "Level-1 orders → prioritize rapid sterilization standards," the atlas can automatically recommend the "WS 310.2 Rapid Sterilization Procedure" for urgent orders and link available sterilization equipment resources, achieving a leap from "data storage" to "intelligent decision-making." For example, when an emergency surgery order is generated, the atlas returns a list of compliant consumables, sterilization protocols, and logistics routes in real time, improving decision-making efficiency by 90% compared to manual planning.

[0305] Preferably, exemplary implementation technical details of the above step 5 are as follows.

[0306] For example, when performing regulatory semantic parsing and logical formula conversion, the RoBERTa-legal medical regulatory fine-tuning model is used to parse regulatory texts (such as Article 8.2 of the "Medical Device Supervision and Administration Regulations" "Implants should be accompanied by unique identification"), and extract elements such as the subject (implant), behavior (with unique identification), and condition (should) through the attention mechanism.

[0307] Use a first-order logic transformer to convert natural language into formal expressions:

[0308] ∀x(Implant(x)→hasUniqueIdentifier(x,true))

[0309] When building a knowledge base of regulatory elements, standardize the definitions of terms such as “sterilization” and “cold chain” to eliminate ambiguity (e.g., distinguishing between “unique identifier” and “batch number”).

[0310] When matching and resolving ambiguity in ontology concepts, we used the AnchorPROMPT+Incremental Mapping algorithm to match logical concepts (such as "Implant") to ontology nodes (http: / / medkg.org / Implant) based on the medical regulatory ontology (including the "Medical Device Classification Catalog" ontology). A bidirectional Transformer encoder was used to calculate semantic similarity (threshold ≥ 0.9), and weights were adjusted based on the medical scenario context (such as the "orthopedic implant" business scenario) to resolve polysemous terms (for example, "implant" only matches medical devices, excluding biological implants).

[0311] During semantic modeling and consistency checking, the Protege ontology editor was used to convert logical expressions into OWL ontology assertions (e.g., `Implant SubClassOf hasUniqueIdentifier some UDI`), generating RDF triples. The HermiT reasoner was deployed to verify ontology consistency, ensuring that constraints such as "implant → must have a UDI" were logically consistent. Low confidence mappings (<0.7) triggered a manual review workflow. For example, in one scenario, Article 8.2 of the "Medical Device Supervision and Administration Regulations" was parsed to correlate the unique identification requirements for "Left Knee Prosthesis ID-1234."

[0312] 1. Regulatory analysis: Extract "Implants should be uniquely identified" to generate the logical expression `∀x(Implant(x)→hasUDI(x))`.

[0313] 2. Ontology matching: “Implant” is matched to the ontology node `http: / / medkg.org / OrthopedicImplant`, and “UDI” is matched to `http: / / medkg.org / UniqueDeviceIdentifier`, with similarities of 0.95 for both.

[0314] 3. Semantic modeling: Generate regulatory semantic triples:

[0315] <rdf:statement>

[0316] <rdf:subject rdf:resource="http: / / law.gov.cn / regulation / 8.2" / >

[0317] <rdf:predicate rdf:resource="http: / / www.w3.org / 2000 / 01 / rdf-schema#implies" / >

[0318] <rdf:object rdf:resource="http: / / medkg.org / OrthopedicImplant#hasUDI" / >

[0319] < / rdf:statement>

[0320] During relationship parsing and initial association generation, the BERT-Med+GCN KE-RE model parses medical consumable supply chain descriptions, extracting relationships ("compliant" and "adhering") between business entities (e.g., "left knee prosthesis ID-1234") and medical standards (e.g., "ISO 11756 biocompatibility"). This model supports "one-to-many" relationship extraction (e.g., a single consumable corresponds to multiple sterilization and transportation standards), and uses a multi-head attention mechanism to capture long-range dependencies (e.g., the implicit association between "urgent order" and "rapid sterilization standard").

[0321] When assigning weights and integrating risk factors, a medical risk-weighted GNN was constructed. Business characteristics (Level 1 timeliness) and medical standard characteristics (temperature control range 2-8°C) were input, and the associated weights (e.g., "left knee prosthesis - ISO 11756" weight 0.92) were calculated using a graph attention mechanism. Furthermore, a risk matrix (cervical spine surgery risk factor 1.5) was introduced to dynamically adjust weights. In high-risk scenarios, the weight of core standards (such as sterilization temperature) was increased by 20%.

[0322] During consistency verification and conflict resolution, the rule engine verifies business-medical rules such as "implant → must be associated with the UDI standard" and automatically corrects conflicts (e.g., "general logistics → cold chain standard" is corrected to "general logistics → normal temperature standard"). Ontology consistency verification: The HermiT inference engine is used to ensure that "orthopedic implants" are not associated with "non-sterile transport standards" and generate triples with weights and evidence chains. For example, in one scenario: associating "left knee prosthesis ID-1234" with "ISO 11756 biocompatibility standard" and "WS 310 sterilization specification", the technical implementation process is as follows:

[0323] 1. Relationship analysis: The KE-RE model extracts the initial relationship pair of “left knee prosthesis-compliant-ISO 11756” and “left knee prosthesis-compliant-WS310”.

[0324] 2. Weight calculation: Level-1 aging rating increases the weight of "WS 310 rapid sterilization" from 0.8 to 0.9 (risk factor 1.2).

[0325] 3. Consistency check: Confirm that "WS 310 sterilization temperature 134±2℃" does not conflict with the scheduling plan "cold chain vehicle" and generate a weighted triplet:

[0326] {

[0327] "subject":"Left knee prosthesis ID-1234",

[0328] "predicate":"compliesWith",

[0329] "object":"ISO 11756",

[0330] "weight":0.92,

[0331] "risk_factor":1.5

[0332] }

[0333] When integrating and resolving cross-source data conflicts, a multi-source data federation architecture was constructed, connecting regulatory semantic triples (OWL ontology) with business-medical triples (RDF knowledgebase). The TransE entity alignment algorithm was used to identify homologous entities (e.g., "Left Knee Prosthesis ID-1234" has a unified URI at both the regulatory and business levels). Conflict resolution rules were designed: medical standard definitions took precedence over business-defined ones (e.g., sterilization temperatures were based on ISO standards), and multi-source evidence was retained (e.g., simultaneously linking the "Medical Device Supervision and Administration Regulations" and the "Cold Chain Guidelines").

[0334] For hierarchical modeling and relationship optimization, a three-layer graph architecture was established: the regulatory layer, which stores regulatory clauses and logical rules (node: Article 8.2 of the Medical Device Supervision and Administration Regulations, edge: Constraint → Business Entity); the business layer, which stores consumables, orders, and logistics (node: Left Knee Prosthesis ID-1234, edge: Transfer → Tianjin Warehouse); and the medical layer, which stores standards and attributes (node: ISO 11756, edge: Applicable → Orthopedic Implants). Furthermore, the GraphSAGE algorithm was used to incrementally process dynamic data, and the graph attention mechanism was used to enhance cross-layer associations.

[0335] During logic verification and intelligent enhancement, the SPARQL query engine is used to check the integrity of cross-layer relationships (e.g., whether there are implants with no standard associations), and the HermiT reasoning engine verifies ontology consistency. Domain reasoning rules are injected (e.g., "cold chain transportation → automatically trigger GPS monitoring"), risk scoring attributes are added (e.g., temperature control exceeds the range → infection risk +0.05%), and complex reasoning is supported (e.g., "query the compliance standards of all Level-1 orders"). For example, in the scenario: integrating regulatory, business, and medical triples to generate a knowledge graph for "left knee prosthesis ID-1234":

[0336] 1. Data fusion: Align "Article 8.2 of the Regulations on the Supervision and Administration of Medical Devices" at the regulatory level, "Left Knee Prosthesis ID-1234" at the business level, and "ISO 11756" at the medical level to eliminate cross-source naming differences in "UDI" identification.

[0337] 2. Hierarchical modeling: Construct the cross-layer relationship "Left knee prosthesis - subject to - Article 8.2 of the Medical Device Supervision and Administration Regulations - in compliance with - ISO 11756" and optimize the edge weight to 0.95 (enhanced for high-risk surgical scenarios).

[0338] 3. Intelligent Enhancement: Added the inference rule "Level-1 order → prioritize matching rapid sterilization standards" and the graph supports SPARQL queries:

[0339] SELECT?implant?standard

[0340] WHERE

[0341] ?implant a med:OrthopedicImplant;

[0342] med:governedBy law:8.2;

[0343] med:compliesWith?standard.

[0344] }

[0345] 4. Output knowledge graph (visualize node relationships):

[0346] Regulatory level: Article 8.2 of the Regulations on the Supervision and Administration of Medical Devices → [Restrictions] → Business level: Left knee prosthesis ID-1234;

[0347] Business layer: Left knee prosthesis ID-1234 → [Compliant] → Medical layer: ISO 11756 biocompatibility;

[0348] Medical layer: ISO 11756 → [Applicable] → Orthopedic implant body.

[0349] Figure 2 This is a schematic diagram of the structure of a device for constructing a knowledge graph of a medical consumables supply chain according to an embodiment of the present application. Figure 2 As shown, it includes:

[0350] The first program unit is used to perform cross-media mapping and distributed desensitization on the collected original medical business data to generate a desensitized semantic data stream;

[0351] The second program unit is used to extract temporal relationships from the desensitized semantic data stream to generate an "order creation-review-delivery" event chain;

[0352] The third program unit is used to constrain the "order creation-review-delivery" event chain based on the constructed medical time constraint rule library and generate a dynamic relationship description with time constraints;

[0353] The fourth program unit is used to inject medical consumables knowledge into the dynamic relationship description with time constraints to generate a medical consumables supply chain description containing "business entity-medical attribute";

[0354] The fifth program unit is used to perform a "regulatory clause-business entity-medical standard" ternary mapping on the description of the medical consumables supply chain to generate a medical consumables supply chain knowledge graph.

[0355] Figure 3 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present application; Figure 3As shown, it includes: a memory 301 and a processor 302, the memory is used to store computer-executable instructions, and the processor is used to run the computer-executable instructions to implement any evaluation method described in this application.

[0356] Figure 4 A medical consumables management system provided in an embodiment of the present application includes: a front-end electronic device 401 and a back-end server 402, the front-end electronic device is used to collect original medical business data, and the back-end server is used to perform the following steps: cross-media mapping and distributed desensitization of the collected original medical business data to generate a desensitized semantic data stream; temporal relationship extraction of the desensitized semantic data stream to generate an "order creation-review-outbound" event chain; based on the constructed medical time constraint rule library, constraint annotation of the "order creation-review-outbound" event chain to generate a dynamic relationship description with time constraints; medical consumables knowledge injection into the dynamic relationship description with time constraints to generate a medical consumables supply chain description containing "business entity-medical attributes"; "regulatory clauses-business entity-medical standards" ternary mapping of the medical consumables supply chain description to generate a medical consumables supply chain knowledge graph.

[0357] Front-end electronic devices include: smartphones, tablet computers, and dedicated touch terminals.

[0358] Those skilled in the art should understand that the scope of the invention involved in this application is not limited to the technical solutions formed by the specific combination of the above-mentioned technical features, but also includes other technical solutions formed by any combination of the above-mentioned technical features or their equivalents without departing from the above-mentioned inventive concept. For example, the technical solutions formed by replacing the above-mentioned features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A method for constructing a knowledge graph for a medical consumables supply chain, characterized in that: include: Step 1: Perform cross-media mapping and distributed desensitization on the collected original medical business data to generate a desensitized semantic data stream; Step 2: Extract temporal relationships from the desensitized semantic data stream to generate an "order creation - review - delivery" event chain; Step 3: Based on the constructed medical time constraint rule library, constrain the "order creation-review-delivery" event chain and generate a dynamic relationship description with time constraints; Step 4: Inject medical consumables knowledge into the dynamic relationship description with time constraints to generate a medical consumables supply chain description containing "business entity-medical attribute"; Step 5: Perform a "regulatory clause - business entity - medical standard" ternary mapping on the medical consumables supply chain description to generate a medical consumables supply chain knowledge graph; Step 5 includes: Step 51: Perform logical formalization and ontology concept mapping on the regulatory clauses in the description of the medical consumables supply chain to generate a regulatory semantic triple set; Step 52: extract and verify cross-domain relationships between business entities and medical standards in the description of the medical consumables supply chain to generate a set of business-medical association triples; Step 53: Fusion storage and graph processing are performed on the regulatory semantic triple set and the business-medical association triple set to generate a medical consumables supply chain knowledge graph; Step 51 includes: Step 511: Perform semantic parsing and logic formula conversion on the regulatory clause text in the medical consumables supply chain description to generate a regulatory logic expression set; Step 512: Perform ontology concept matching and ambiguity resolution on the concepts in the legal logic expression set to generate legal regulation-ontology concept mapping pairs; Step 513: Perform semantic modeling and consistency verification on the regulation-ontology concept mapping pair to generate a set of regulation semantic triples.

2. The method according to claim 1, characterized in that Step 1 includes: Step 11: Perform local homomorphic encryption on the collected original medical business data to obtain ciphertext medical business data, which is then distributed to the set federated nodes for distributed desensitization to generate a desensitized data set with traceability marks, including consumable entity identification, security level labels, and desensitization operation logs; Step 12: Based on the constructed cross-media mapping engine, feature fusion is performed on the desensitized dataset with traceability tags to implement cross-media mapping to generate a desensitized semantic data stream.

3. The method according to claim 2, characterized in that Step 12 includes: Step 121: Based on a multimodal generative adversarial network, perform semantic embedding processing of medical term enhancement on the desensitized dataset with traceability marks to generate a cross-modal shared semantic vector; Step 122: Based on the graph attention network, perform entity association processing on the cross-modal shared semantic vector to generate a multimodal entity mapping table; Step 123: Based on the CTC-GNN fusion network, feature fusion is performed on the multimodal entity mapping table to implement cross-media mapping to generate a desensitized semantic data stream.

4. The method according to claim 1, wherein Step 3 includes: Step 31: Based on the surgery type timeliness threshold table in the medical timeliness constraint rule library, perform time window threshold labeling on the "order creation - review - delivery" event chain to obtain a timeliness level labeling event chain; Step 32: Perform temporal logic compliance verification on the timeliness level marking event chain to obtain a temporal compliance evaluation event chain; Step 33: Based on the resource scheduling conflict avoidance rules in the medical time constraint rule library, the time compliance evaluation event chain is subjected to resource constraint association processing to generate a dynamic relationship description with time constraints.

5. The method according to claim 4, characterized in that Step 32 includes: Step 321: Based on the LTL linear temporal logic parsing engine and rule priority queue, perform executable logic conversion and priority sorting on the multi-stage temporal logic rule set to generate a prioritized temporal constraint rule expression; Step 322: Perform phase time interval analysis and risk factor weighting on the timeliness level labeled event chain to generate a time feature vector with risk weights. Step 323: Based on the priority-based timing constraint rule expression, perform timing compliance scoring and dynamic compensation calculation on the time feature vector with risk weight to obtain a timing compliance assessment event chain.

6. The method according to claim 4, characterized in that Step 33 includes: Step 331: Based on the configured resource scheduling rule graph database and conflict priority rules, perform graph-structured parsing and conflict resolution processing on the resource scheduling conflict avoidance rules to generate a resource constraint knowledge graph; Step 332: Based on the multi-source resource state feature extractor, perform resource demand analysis and state association processing on the time sequence compliance assessment event chain to generate a resource-timeliness association feature vector; Step 333: Based on the constructed fuzzy logic fusion decision, the resource constraint knowledge graph is used to generate a scheduling strategy and perform conflict compensation processing on the resource-timeliness association feature vector to generate a dynamic relationship description with timeliness constraints.

7. The method according to claim 1, characterized in that Step 4 includes: Step 41: Perform business entity-medical concept mapping on the dynamic relationship description with time constraints to generate a cross-domain entity association table; Step 42: extract and fuse professional attribute features from the cross-domain entity association table to generate a medical attribute enhanced feature vector; Step 43: Compliance rules are injected and structured into the medical attribute enhanced feature vector to generate a medical consumables supply chain description containing "business entity-medical attribute".

8. The method according to claim 7, characterized in that Step 41 includes: Step 411: extract business entities and perform type annotation processing on the dynamic relationship description with time constraints to generate a business entity feature set; Step 412: Perform medical concept matching and ambiguity resolution on the business entity feature set to generate a candidate concept matching list; Step 413: Perform cross-domain mapping verification and confidence calculation on the candidate concept matching list to generate a cross-domain entity association table.

Images