Drug data management method and system based on drug traceability code

Abstract

The invention discloses a drug data management method and system based on a drug traceability code, and the method comprises the steps: taking the drug traceability code as a core index, carrying out the cross-system correlation of drug knowledge data and transaction scene data, generating structured evidence through the anomaly detection analysis of scene adaptation, and finally aggregating the evidence to achieve the intelligent risk judgment. According to the method, deep association and collaborative analysis are carried out on the physical trajectory data in the drug circulation process and the logic feature data in the use scene through the unified traceability code index, so that the capability evolution from simple flow query to complex mode recognition and risk prediction is realized on the data processing level.

Description

Technical Field

[0001] This invention relates to the fields of data processing and artificial intelligence application technology, and in particular to a method and system for drug data management based on drug traceability codes. Background Technology

[0002] The establishment of a drug traceability system aims to enable the tracking and verification of information throughout the entire drug supply chain, from production to consumption. It has played a crucial role in combating counterfeit drugs and ensuring drug safety. Existing drug traceability systems typically use traceability codes as unique identifiers, recording basic information such as the drug's name, batch number, manufacturer, distribution path (e.g., entry into a hospital or pharmacy), and even the final sales record. However, current traceability systems primarily focus on supply chain transparency and physical anti-counterfeiting measures, with limited data dimensions and depth.

[0003] In the field of medical insurance fund supervision, there exists a specific fraud risk: insured individuals obtain medications through compliant or compliant channels, but do not use them for their own treatment; instead, they resell them for profit, commonly known as medical insurance cash-out or drug reselling. This behavior essentially violates the core principle of the medical insurance fund in providing treatment guarantees for sick insured individuals, resulting in fund losses. Existing technologies struggle to effectively identify this risk because: 1) In hospital settings, while the system can record that medications have been prescribed to specific patients, it cannot automatically and efficiently determine whether the clinical use of the medication (based on electronic medical records) is reasonable and necessary, resulting in a prescription-diagnosis logic breakpoint; 2) In pharmacy settings, the lack of patient medical records as a reference makes it impossible to judge the reasonableness of medication purchases, relying only on simple frequency and quantity thresholds for rough early warning, leading to high rates of underreporting and false alarms.

[0004] Therefore, existing technologies have a significant drawback: drug traceability data (physical flow), medical clinical data (logical rationality), and drug purchase behavior profile data are isolated from each other, failing to undergo deep integration and intelligent analysis. This results in the inability to accurately identify medical insurance fraud risks where drug circulation is legitimate but the intended use is illegal. How to leverage a unified drug traceability code key to connect and link multi-source heterogeneous data, and build an intelligent risk control system capable of simultaneously assessing both physical circulation compliance and the logical rationality of clinical use, has become an urgent technical problem to be solved. Summary of the Invention

[0005] To address the aforementioned technical problems, the technical solution adopted by this invention is as follows: According to a first aspect of the present invention, a method for managing drug data based on drug traceability codes is provided, the method comprising the following steps: S100, in response to receiving the drug traceability code, using the drug traceability code as an index, cross-system association and acquisition of at least two types of data related to the drug, wherein the first type of data includes a set of associated data of drug attributes and their indications, and the second type of data is the transaction scenario data corresponding to the drug traceability code.

[0006] S200, based on the type of the transaction scenario data, perform at least one corresponding anomaly detection analysis, wherein the output of each anomaly detection analysis constitutes an anomaly detection evidence.

[0007] S300, aggregate all the abnormal detection evidence output by the at least one abnormal detection analysis to obtain the corresponding aggregation result, and determine whether the transaction behavior identified by the drug traceability code is in an abnormal state based on the aggregation result, and output the determination result.

[0008] According to a second aspect of the present invention, a drug data management system based on drug traceability codes is provided, the system comprising: The data association module is used to respond to receiving a drug traceability code, and use the drug traceability code as an index to associate and obtain at least two types of data related to the drug across systems. The first type of data includes a set of associated data on drug attributes and their indications, and the second type of data is the transaction scenario data corresponding to the drug traceability code.

[0009] An anomaly detection module is used to perform at least one anomaly detection analysis based on the type of the transaction scenario data, wherein the output of each anomaly detection analysis constitutes an anomaly detection evidence.

[0010] The determination module is used to aggregate all the abnormal detection evidence output by the at least one abnormal detection analysis to obtain the corresponding aggregation result, and based on the aggregation result, determine whether the transaction behavior identified by the drug traceability code is in an abnormal state, and output the determination result.

[0011] The present invention has at least the following beneficial effects: This invention first establishes a standardized data association path across systems by using the drug traceability code as the core index key. This design solves the technical problem of accurately and efficiently acquiring and associating two types of key data (static attribute sets and dynamic scenario data) from dispersed and structurally dissimilar systems (such as drug knowledge bases and transaction record systems), thus constructing a complete and consistent data view for subsequent analysis. Next, by dynamically scheduling and executing corresponding anomaly detection analyses based on data type, the complex risk assessment task is decoupled into multiple independent, functionally specialized evidence generation units. Each analysis outputs standardized anomaly detection evidence, giving the system high configurability and scalability. New analysis models or rules can be easily integrated in a modular manner, thereby continuously improving the ability to identify complex data patterns. Finally, by introducing an evidence aggregation layer, discrete evidence from different analysis units is comprehensively calculated and evaluated. This invention overcomes the limitations of relying on single indicators or fixed rules for judgment. Through comprehensive weighting and logical aggregation, the final state determination is based on a more comprehensive and complementary evidence system, significantly improving the stability, objectivity, and anti-interference capability of the system output results.

[0012] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 A flowchart illustrating a drug data management method based on drug traceability codes provided in an embodiment of the present invention. Detailed Implementation

[0015] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0016] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of this invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0017] It should be noted that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe the steps as sequential processes, many of these steps can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the steps can be rearranged. A process can be terminated when its operation is complete, but it may also have additional steps not included in the figures. A process can correspond to a method, function, procedure, subroutine, subroutine, etc.

[0018] (Example 1) This invention provides a method for drug data management based on drug traceability codes, such as... Figure 1 As shown, the method includes the following steps: S100, in response to receiving the drug traceability code, using the drug traceability code as an index, cross-system association and acquisition of at least two types of data related to the drug, wherein the first type of data includes a set of associated data of drug attributes and their indications, and the second type of data is the transaction scenario data corresponding to the drug traceability code.

[0019] This step aims to use the drug traceability code as a unified entry point to automatically aggregate multi-dimensional drug-related data scattered across different information systems, providing a complete data foundation for subsequent anomaly detection and analysis.

[0020] The drug traceability code can be received through scanning devices (such as medical insurance terminal barcode scanners), mobile application uploads, or manual input. The drug traceability code is typically a unique code conforming to the national drug traceability standard system.

[0021] Upon receiving the drug traceability code, the code structure is first parsed to extract key identification information that can be used for indexing, such as the drug identification code, manufacturer code, production batch number, and serial number. This information is the core key to cross-system data linkage.

[0022] The associated data set of drug attributes and indications is a structured knowledge entity centered on the drug. It is not a simple list, but rather establishes an inherent relationship between drug, attributes, and indications. Specifically, it includes: Drug attributes include static information such as generic name, brand name, chemical composition (or traditional Chinese medicine ingredients), dosage form, specifications, pharmacological category, and storage conditions.

[0023] Indication information: refers to a detailed description of the disease, symptoms, or signs for which the drug is officially approved by the national drug regulatory authority for prevention, diagnosis, or treatment.

[0024] Relationships: Clearly record which indications correspond to which drug attributes (such as specific components or dosage forms). This dataset is typically sourced from and integrated from official drug databases (such as the National Drug Standards Database), approved digital information from drug instructions, and authoritative medical knowledge bases.

[0025] The data set can be obtained in real time or asynchronously by calling the pre-built drug master data service interface or querying the local drug knowledge graph database, using the parsed drug identification code as the key query condition.

[0026] Transaction scenario data refers to dynamic contextual information directly related to a single drug transfer and reimbursement transaction identified by a specific drug traceability code. This transaction scenario data can be obtained by securely interacting with one or more external business systems via an integrated API gateway, based on unified communication protocols (such as HTTPS) and data exchange standards (such as JSON / XML formats): (1) Hospital Information System: When a drug is sold in a hospital, the electronic medical record information corresponding to the prescription is provided as the first type of scenario data. This includes the patient's primary diagnosis, present medical history, physical signs, test results (parts related to the rationality of drug use), as well as the information of the physician who prescribed the drug and the time of prescription.

[0027] (2) Pharmacy Management System: When medicines are sold in retail pharmacies, it provides a profile of the purchaser (such as the purchaser's age, gender, membership level, and historical purchase preferences) and spatiotemporal information of the purchase behavior (such as the time of this purchase, the pharmacy address located by GPS, and related purchase records of the same purchaser within a short period of time).

[0028] In this invention, the purchaser profile is a set of attributes used to depict the characteristics of the purchaser and assess their match with the target population for the drug. Its acquisition does not rely on a single source, but is generated through the fusion of information from one or more of the following channels: Core source: Pharmacy Membership Management System When a customer purchases medication using a membership (such as a mobile phone number or membership card), their pre-stored basic attributes are automatically linked, such as age, gender, and length of membership. By analyzing their historical medication purchase records, consumer behavior tags are generated, such as: frequently purchased medication categories (such as cardiovascular drugs, cold medicines), average spending amount, and purchase frequency. These tags constitute the behavioral dimensions of the customer profile.

[0029] Authoritative source of identity: Medical insurance settlement voucher When settling medical insurance payments by card, the system obtains anonymized medical insurance participant attributes authorized by the participant through a secure interface (such as the National Medical Insurance Electronic Voucher interface). This is one of the most authoritative data sources for profiling participants and may include: Type of insured person (e.g., employee, resident).

[0030] Age range of the insured (e.g., "50-60 years old").

[0031] Related chronic disease registration information (such as whether the patient is registered as a "hypertension" or "diabetes" patient). This information is of great reference value in judging the rationality of purchasing related drugs.

[0032] Expansion and verification sources: compliant external data sources With explicit user authorization and in compliance with laws and regulations, limited data queries can be securely conducted with compliant health management platforms or internet healthcare platforms using technologies such as privacy computing. The purpose is not to obtain detailed medical records, but to verify or supplement health interest tags (such as whether the user has paid attention to knowledge about a certain type of disease) or to obtain descriptions of non-diagnostic symptoms that may be related to the current medication purchase (such as "recent dizziness") as supplementary references for rationality assessment.

[0033] The basic attributes and behavioral tags obtained from the membership system, the authoritative identity and chronic disease registration status obtained from medical insurance vouchers, and the health-related tags or text information obtained from authorized external platforms together constitute multi-source heterogeneous data. This multi-source heterogeneous data is associated, deduplicated, and semantically fused using the medical insurance electronic voucher ID or mobile phone number used for this medication purchase as a unified key value. Ultimately, a structured profile data object of the medication purchaser is dynamically generated, containing standardized fields across multiple dimensions such as demographics, consumption behavior, health status, and potential needs. The spatiotemporal information of the medication purchase behavior directly records the external patterns of this and historical purchase behaviors, primarily generated through the endogenous data of the pharmacy management system.

[0034] The time information in the spatiotemporal information of drug purchase behavior comes from the current behavior and historical patterns. The timestamp of the current behavior is automatically generated by the sales terminal at checkout, while the historical patterns are indexed by the purchaser's ID (such as a medical insurance ID) to query the historical drug purchase time series of all stores within this pharmacy and even the chain group. Based on this, key behavioral indicators can be calculated, such as: Short-term frequency: For example, the number of times the same or similar drugs have been purchased in the past 7 days.

[0035] Regularity of medication purchase time: Does medication purchase always occur outside of normal business hours (such as late at night)?

[0036] Off-season drug purchases: For example, purchasing large quantities of anti-influenza drugs during non-flu peak seasons.

[0037] Spatial information of drug purchase behavior includes the geographical location of the current behavior and historical clustering analysis. The geographical location of the current behavior is determined by the fixed GPS coordinates or unique code of the pharmacy store, while the historical clustering is calculated by analyzing the geographical distribution of the purchaser's historical transactions.

[0038] The historical clustering analysis in the spatial information is used to identify abnormal spatiotemporal behavior patterns of drug buyers in pharmacies, mainly including two typical scenarios: regional jumping and store clustering.

[0039] Regional skipping is defined as: a purchaser buying the same medication from different pharmacies located geographically distant within a short time window (e.g., one day). The distance between these pharmacies can be determined using one or more configurable quantification rules: Geographic distance rule: When the straight-line distance or route planning distance between two medicine purchase locations exceeds a preset threshold (e.g., 50 kilometers); Administrative jurisdiction rules: When two drug purchase locations belong to different specific administrative regions (e.g., different prefecture-level cities); Travel time rule: When it is difficult to make a round trip between two places using conventional transportation methods within the time window.

[0040] Meeting any one of the rules will determine that the two locations are far apart, thus triggering the regional jump anomaly flag.

[0041] Store clustering is defined as: a patient consistently and frequently concentrates their medication purchases at the same or a few pharmacies. This type of anomaly can be quantitatively identified using multi-dimensional indicators, such as: Long-term concentration index: Over a period of more than six months, more than 80% of the purchases of medicines covered by medical insurance occurred at the same pharmacy, and the total number of purchases ranked among the top (e.g., top 5%) of customers at that pharmacy during the same period. High-frequency indicators for specific drugs: For drugs with the same generic name or pharmacological category, the number of times the purchaser buys the drug from the same pharmacy within one month exceeds the reasonable frequency of drug use under the standard treatment plan by more than a multiple (e.g., 3 times). Cross-category high-frequency indicators: The purchaser makes multiple (e.g., three or more) medical insurance settlements at the same pharmacy within a short period of time (e.g., one week), and the purchased drugs cover multiple different treatment categories (e.g., three or more). This pattern is inconsistent with conventional diagnosis and treatment logic.

[0042] All the thresholds in the above quantitative rules (such as time period, distance, percentage, multiple, etc.) are configurable parameters and can be adjusted according to regulatory policies and business needs. The quantitative results generated by this analysis constitute a key part of the spatiotemporal information of drug purchasing behavior and serve as the core basis for triggering abnormal behavior pattern indication signals.

[0043] (4) Medical insurance settlement system: Provides the voucher information that the transaction has triggered medical insurance reimbursement, including settlement time, reimbursement type, medical insurance fund payment amount, personal account payment amount, etc., to confirm that the transaction falls within the scope of supervision.

[0044] (5) Drug traceability platform: Provides logistics information of the traceability code, such as inbound and outbound records and current status ("sold"), as an auxiliary verification of the authenticity of the transaction.

[0045] After obtaining data from the above multiple channels, the data is cleaned and standardized (e.g., the time is unified to UTC timestamps and the diagnostic codes are unified to the ICD-10 standard). Using the drug traceability code as the core key, the first type of data (static knowledge) and the second type of data (dynamic transaction scenarios) are combined in memory or a temporary database to form a complete data record for this analysis task, which can be called by subsequent steps S200.

[0046] In this invention, the transaction scenario data includes either a first type of scenario data or a second type of scenario data; the first type of scenario data includes electronic medical record information related to diagnosis and treatment, and the second type of scenario data includes a profile of the drug purchaser and spatiotemporal information of the drug purchase behavior.

[0047] In this invention, the associated data set is preferably stored and organized in the form of a knowledge graph to support efficient and accurate association queries and reasoning. The drug knowledge graph is a semantic network, wherein: Nodes represent entities, including but not limited to drugs, chemical components of drugs (or traditional Chinese medicine ingredients), indications (diseases or symptoms), and contraindications.

[0048] Edges represent relationships between entities, mainly including treatment relationships (such as "drug A is used to treat disease B") and conflict relationships (such as "drug C and drug D are pharmacologically antagonistic" or "drug E is prohibited from being used for disease F").

[0049] S200, based on the type of the transaction scenario data, perform at least one corresponding anomaly detection analysis, wherein the output of each anomaly detection analysis constitutes an anomaly detection evidence.

[0050] The anomaly detection and analysis is adapted to different data types in the scenario, and specifically includes the following branches: S210, If the transaction scenario data is the first type of scenario data, then perform a clinical applicability analysis.

[0051] The clinical suitability analysis, which takes the specific drug identified by the drug traceability code as the analysis target, is configured to: match the diagnostic information in the electronic medical record information with the indication information in the associated data set and calculate the matching degree; compare the calculated matching degree with a preset matching degree threshold; when the matching degree is lower than the preset matching degree threshold, generate and output a behavioral abnormality indication signal indicating abnormal clinical suitability, which serves as evidence of abnormality detection.

[0052] In clinical suitability analysis, the analysis is conducted independently on a per-drug traceability code basis. If the matching degree of a drug is lower than a preset matching degree threshold, an abnormal evidence signal of clinical suitability for that drug is generated.

[0053] The preset matching threshold is a configurable system parameter that can be optimized through machine learning. Initially, a baseline value can be obtained based on historical compliant prescription data (for example, taking the 5th percentile of the historical compliant prescription matching distribution as the initial threshold). In subsequent workflows, it can be dynamically adjusted based on feedback from manual review. If the matching degree is normalized to the [0, 1] interval, an exemplary initial threshold can be set to 0.6. This value is only an example; the actual threshold needs to be determined according to the above logic.

[0054] The calculation of the matching degree in the clinical applicability analysis can adopt different levels of technical approaches depending on the implementation requirements: Technical Path 1: Intelligent Reasoning Path Based on Deep Semantic Understanding In this approach, clinical applicability analysis is achieved by invoking a pre-trained large-scale language model (such as a general-purpose model like the GPT series or GLM, or a domain-specific model fine-tuned for medical text). The analysis process is as follows: The prompt engineering approach involves constructing a structured prompt that takes the drug name (or its chemical composition), a diagnostic description extracted from electronic medical records, and official indications obtained from a related dataset as input. The prompt will clearly define the role of the instruction model as an expert in reviewing rational drug use.

[0055] Model Reasoning and Judgment: Based on its inherent medical knowledge and understanding of natural language, the large language model infers whether a diagnosis belongs to or is highly relevant to the indications of the drug. The model not only performs literal matching, but also understands the logical relationship between synonyms, disease classifications, and the scope of drug action (e.g., determining whether a broad-spectrum antibiotic is suitable for community-acquired pneumonia).

[0056] Structured output: Large models are required to output a structured analysis result, which includes at least a binary or multivariate reasonableness judgment (such as “highly matched”, “likely relevant”, “mismatch”) and a confidence score or brief inference.

[0057] Evidence generation: If the output of the analytical model is judged as "mismatched" or the confidence score is lower than the preset threshold, a behavioral abnormality indicator signal indicating abnormal clinical applicability will be automatically generated. This signal records the summary of the model's judgment and reasoning as part of the evidence content.

[0058] Technical Path Two: Inference Path Based on Retrieval Enhancement Generative Framework In this approach, clinical applicability analysis is implemented using a retrieval-enhanced generative framework. This framework aims to improve the accuracy, authority, and interpretability of the analysis by coupling precise external knowledge retrieval with the controllable reasoning capabilities of a large-scale language model. The implementation process may include the following: Knowledge Base Construction and Retrieval: Maintain and access an external, structured pharmaceutical clinical knowledge base. This base aggregates authoritative information such as drug standard instructions, clinical practice guidelines, authoritative pharmacological monographs, and post-marketing study abstracts, and establishes structured associations between drugs and their indications, contraindications, and use in special populations.

[0059] When the analysis is initiated, the most relevant evidence entries are retrieved in real time from the knowledge base using the current drug identifier and diagnostic information extracted from electronic medical records as the joint search key. These entries may include: a list of diseases for which the drug is clearly applicable, relevant treatment guideline recommendation paragraphs, and explicit contraindication warnings.

[0060] Evidence-based reasoning guided by a large model: Retrieved relevant evidence entries, original diagnostic information, and drug information are combined to form a structured prompt, which is then input into a large language model. Through prompting engineering, the model is strictly guided to play the role of an "evidence-based reviewer," with the core instruction being: "Please strictly rely on the provided external authoritative evidence to determine whether the diagnosis falls under the indications for this drug, and cite specific evidence to explain the reasoning process." Generate verifiable conclusions: After reasoning based on the provided evidence, the large language model outputs a structured conclusion. This conclusion not only includes judgments such as "applicable," "use with caution," and "not applicable," but must also include specific sources of evidence cited for its reasoning (e.g., "According to Chapter X of the 2023 Chinese Guidelines for the Prevention and Treatment of XX Disease, this drug is recommended for…, but the patient also has contraindication Y, therefore it is not applicable"). This design ensures the transparency of the analysis process and the auditability of the conclusions.

[0061] Evidence Generation: The final analysis results are generated based on the conclusions produced by the large language model. If the conclusion is inapplicable or should be used with caution (and exceeds the risk tolerance), a behavioral abnormality indicator signal for clinical applicability is generated. This abnormality indicator signal not only contains the abnormal conclusion, but also encapsulates the key evidence references used as the basis for reasoning, thus forming a high-value abnormality detection evidence that is self-explanatory and easy for manual review.

[0062] The beneficial effects of this technical approach are that by introducing an external authoritative knowledge base as a factual benchmark, it effectively constrains and guides the reasoning direction of large models, avoiding potential problems such as illusions or outdated knowledge, and making the analysis results combine the efficiency of artificial intelligence with the rigor and verifiability of human experts.

[0063] Technical Path 3: Matching Path Based on Traditional Semantic Vectors This technical approach provides a fundamental and classic method for conducting clinical applicability analysis. Its core lies in quantifying the degree of matching between diagnostic statements and drug indication statements by calculating the correlation between them in a semantic space or a predefined knowledge network. This method focuses on achieving efficient and stable text relevance assessment. Specifically, it can be implemented through the following two types of technical solutions or a combination thereof: 3.1 Semantic Similarity Calculation Based on Domain Text Embedding Model This approach utilizes domain embedding models (e.g., models based on BERT, BioBERT, etc.) pre-trained on a large amount of medical text. During implementation, diagnostic information text (e.g., "essential hypertension, grade II") and drug indication information text (e.g., "for the treatment of essential hypertension") are input into the model to obtain their high-dimensional semantic vector representations. Subsequently, the cosine similarity or the reciprocal of the normalized Euclidean distance between the two vectors is calculated, and this value is used as the matching score. This approach effectively captures the deep semantics of clinical terms and understands synonyms and near-synonyms.

[0064] 3.2 Relationship Calculation Based on Standardized Knowledge Graph This approach relies on mapping free text to a standardized terminology system. In implementation, diagnostic information and drug indication information are first mapped to corresponding nodes in a standard medical terminology set (e.g., diagnosis to ICD-10 encoding nodes, drug to ATC encoding nodes). Then, in a pre-constructed medical knowledge graph, the topological correlation between these two nodes is calculated, using them as the starting and ending points. The correlation can be measured by the reciprocal of the shortest path length or characterized by scores output by more complex graph algorithms (such as Personalized PageRank, TransE, and other relational embedding models). The advantage of this approach is that the judgment criteria are clear, interpretable, and entirely based on an authoritative knowledge system.

[0065] The methods encompassed in this approach form a reliable technological foundation for achieving diagnosis-indication matching. Together with the aforementioned Technological Path 1 (large-scale deep inference) and Path 2 (RAG framework), it constitutes a complete technological spectrum from basic matching to deep inference, and then to evidence-enhanced inference. In practical implementation, different technological paths can be flexibly selected or integrated based on varying requirements for computational efficiency, accuracy, and interpretability.

[0066] Technical Path 4: Matching Path Based on Knowledge Graph Traversal and Graph Structure Association Matching Calculation This technical approach provides a highly interpretable method for conducting clinical applicability analysis based on deterministic knowledge. Its core innovation lies in treating the drug knowledge graph as a computable and traversable reasoning network. By executing a graph traversal algorithm and calculating the graph structural correlation between nodes, the degree of matching between drugs and diagnoses is quantified.

[0067] The specific implementation process is configured to include the following steps: 4.1 Graph Node Location The specific drug node identified by the drug traceability code serves as the starting point (source node) for reasoning. Simultaneously, diagnostic information extracted from electronic medical records is mapped to the corresponding diagnostic node in the same knowledge graph, serving as the target point (target node) for reasoning.

[0068] 4.2 Graph Traversal and Relationship Path Discovery In the knowledge graph, starting from the drug node, a graph traversal algorithm (such as breadth-first search or depth-first search) is executed along edges of the "treatment relationship" type as valid paths. The purpose of this process is to discover all valid relationship paths that can lead from the drug node to the diagnosis node. These paths intuitively reveal the chain of evidence that "the drug is used to treat a certain disease".

[0069] 4.3 Calculation of Matching Degree Based on Graph Topology In this approach, the matching degree is specifically achieved by calculating the graph association degree between the drug node and the diagnosis node within the knowledge graph. The core principle is that in a knowledge graph, the more direct and stronger the connection between two nodes through a treatment relationship path, the higher their treatment association and the higher the matching degree. This is specifically quantified using one or more graph algorithms: Shortest path inverse method: Calculate the shortest path length (i.e., the number of edges traversed) between the source node and the target node. The matching degree is set to the reciprocal of this length. This method assumes that direct connections (such as those that go straight to the target node) are more relevant than indirect connections (such as those that pass through intermediate nodes).

[0070] Weighted path aggregation method: If the edges of the knowledge graph are attached with weights (such as confidence weights that represent the strength of the treatment relationship), the matching degree can be calculated as the weight aggregation value of all valid paths (such as summation or taking the maximum value), or the cumulative weight of the optimal path.

[0071] Graph embedding similarity method: This method uses graph embedding technology to map the nodes of the entire knowledge graph to a low-dimensional vector space, so that closely connected nodes in the graph are also close to each other in the vector space. Then, the cosine similarity between the drug node vector and the diagnosis node vector is directly calculated as the matching degree.

[0072] 4.4 Generation of Abnormal Evidence The calculated matching degree, i.e., the map correlation degree, is compared with a preset matching degree threshold. If the matching degree is lower than the threshold, a behavioral abnormality indicator signal indicating abnormal clinical applicability is generated. The confidence score of this signal can be directly derived from the aforementioned correlation degree calculation result, thereby ensuring the traceability of evidence.

[0073] This technical approach differs fundamentally from the semantic vector method in Technical Approach Three. It does not rely on the statistical semantic features of text, but rather performs explicit reasoning entirely based on a predefined structured medical logical relationship network (graph). Its advantages are: Highly interpretable: Any conclusion of a match or mismatch can be intuitively explained by showing the specific relationship paths found (or not found) in the graph.

[0074] Logical certainty: The reasoning process is based on explicit medical knowledge relationships, avoiding the uncertainty of statistical models.

[0075] Complementing the advanced path: It provides an efficient way to implement the retrieval step in technical path two, and can also serve as a benchmark for verifying the rationality of the output of technical path one.

[0076] Therefore, technical path four represents a core analysis method based on symbolic logic and deterministic knowledge in this invention, which complements other paths based on numerical statistics and probability models, together forming a complete, robust and interpretable intelligent analysis system.

[0077] S220, if the transaction scenario data is the second type of scenario data, then perform behavioral pattern anomaly analysis.

[0078] The behavioral pattern anomaly analysis is configured as follows: S2201, based on the spatiotemporal information of the drug purchase behavior, analyze the spatiotemporal clustering value or frequency value of the drug purchase behavior, and / or, based on the drug purchaser profile, analyze the matching degree value between the drug purchaser profile and the target population of drugs indicated by the associated data set.

[0079] In one illustrative embodiment, the spatiotemporal aggregation value CS satisfies the following condition: CS = 1 - HHI, where HHI is the Herfindahl-Hirschman exponent, and HHI = Σ i∈n (P) i ) 2 , where P i Let represent the proportion of drug purchases made at pharmacy i to the total number of drug purchases. The summation range is all n pharmacies where the purchaser has made purchases within a certain period (e.g., the past year). This value is between 0 and 1. The lower the value, the more abnormal the spatial clustering (the value is 0 when all purchases are concentrated at one pharmacy; the value approaches 1 when the distribution is completely uniform).

[0080] In an illustrative embodiment, the frequency value F satisfies the following condition: F = BA / BT. BA is the actual number of times the same generic drug was purchased within a selected observation period (e.g., 30 days). BT is the theoretically reasonable maximum number of purchases within the same observation period, determined based on the drug's instructions, standard treatment duration, and medical insurance payment policy. For example, if a certain antihypertensive drug is routinely taken once daily, with a maximum 30-day dosage of 30 units, and the smallest package contains a 7-day supply, then the reasonable maximum number of purchases is approximately 4.3 times (30 / 7).

[0081] In one illustrative embodiment, the matching degree value M satisfies the following condition: M = Σ j∈P (w) j ×f(h1) j h2 j (), where P represents the set of feature dimensions involved in the matching calculation. For example, P = {age, gender, chronic disease registration under medical insurance}. It defines which aspects are compared. j represents a specific feature dimension in the set P. h1 j This represents the feature value of the purchaser in the j-th feature dimension. For example, when j is age, h1 j This could be the specific age of the person purchasing the medication (e.g., 45 years old). h2 j This represents the baseline value or range of the target population for the drug in the j-th feature dimension. For example, when j is "age", h2 j This could be the age range of the target population for this drug (e.g., "40-75 years old"). f(h1) j h2 j Let f(j) represent the similarity calculation function for the j-th feature dimension. Its function is to calculate the feature value h1 of the medicine purchaser. j Compared with the target population characteristic benchmark h2 j The similarity score between the values ​​is typically normalized to the [0,1] interval. For example, for age (a continuous value), f can be a similarity calculation based on a Gaussian kernel function; for whether a specific chronic disease is registered (a discrete value), f can be an indicator function where a match is 1 and a mismatch is 0.j Let represent the weight of the j-th feature dimension in the overall matching degree calculation, and it usually satisfies Σ j∈P w j =1. The weights reflect the differences in the importance of different features in judging the rationality of drug purchases. For example, for a specific hypoglycemic drug, the weight of the disease type registered under medical insurance (such as whether it is registered as diabetes) will be significantly higher than the weight of the gender characteristic.

[0082] It should be noted that the formula for calculating the matching degree is a mathematical expression of an exemplary calculation method. In a real system, the feature set, weight assignments, and the specific form of the similarity function can all be configured, adjusted, and optimized based on drug characteristics, medical knowledge, or historical data training results.

[0083] S2202 When any of the spatiotemporal aggregation value, frequency value, or matching value exceeds the corresponding preset threshold, a behavioral anomaly indication signal is generated and output as evidence of anomaly detection.

[0084] In one illustrative embodiment, the preset threshold for determining abnormal behavior patterns can be configured as follows: The preset spatiotemporal clustering threshold can be set to 0.3. When the calculated spatiotemporal clustering value is lower than this threshold, it is determined that there is spatial anomalous clustering.

[0085] The preset frequency threshold can be set to 1.5 or 2.0. When the calculated frequency value exceeds this threshold, it is determined that there is an abnormal frequency of drug purchases.

[0086] The preset profile matching threshold can be set to 0.7. When the calculated matching score is lower than this threshold, it is determined that the profile of the purchaser does not match the target population of the drug.

[0087] All the specific threshold values ​​above are merely illustrative examples used to clearly illustrate the technical solution of this invention. In actual system deployment, these thresholds are all configurable and adjustable parameters. Their specific values ​​can be dynamically set and optimized based on different drug characteristics, regional medical insurance policies, historical data statistical analysis results, and the stringency of risk control. The scope of protection of this invention is not limited to the above-mentioned example values, but extends to the method itself for anomaly detection based on such configurable thresholds.

[0088] Furthermore, the anomaly detection analysis also includes drug conflict analysis, which is configured to: based on the drug attributes (especially its chemical composition or pharmacological category), search the purchaser's historical medication records for records of mutually exclusive drug use; if mutually exclusive records are found, output a behavioral anomaly indication signal indicating drug conflict as evidence of anomaly detection.

[0089] In terms of execution logic, the drug conflict analysis is adapted to different scenarios: in the first scenario (hospital scenario), the multiple anomaly detection analyses in S200 adopt a hierarchical and progressive execution strategy.

[0090] The execution of at least one anomaly detection analysis specifically includes: (1) First, perform drug conflict analysis as a rigid safety check. The core of this design is that violations of drug contraindications are the highest priority risks, and the conclusions are clear and non-negotiable.

[0091] (2) The clinical suitability analysis shall be performed only if the drug conflict analysis does not output a behavioral abnormality indication signal indicating drug conflict abnormality.

[0092] If the drug conflict analysis outputs an anomaly indicator signal, the transaction can be directly determined to be high-risk based on this single piece of evidence, without needing to initiate the more computationally complex clinical applicability analysis. This significantly improves the efficiency of high-risk transaction determination and saves system resources. If the drug conflict analysis does not output an anomaly indicator signal, it indicates that the safety baseline check has been passed, and the clinical applicability analysis, as a deeper assessment of rationality, will continue to be performed to determine the degree of match between the drug and the diagnosis.

[0093] This safety-first, progressive assessment strategy simulates the rigorous logic of professional medical review, making the entire analysis process both efficient and in-depth. It avoids unnecessary complex calculations in known high-risk situations, while ensuring the hierarchy and accuracy of risk assessment.

[0094] In the second scenario (pharmacies scenario), the drug conflict analysis and the behavioral pattern anomaly analysis are performed in parallel or sequentially and independently, with no fixed logical dependency between them. The analysis results (regardless of whether a conflict exists) will be used as independent evidence, and together with the evidence generated by the behavioral pattern analysis, will be input into the subsequent aggregation and judgment steps.

[0095] In one specific implementation, the drug conflict analysis is achieved by querying the set of related data stored in the form of a knowledge graph. Using the current drug or its chemical components as the query node, the knowledge graph is traversed along conflict relationship edges to quickly locate all known sets of mutually exclusive drugs. Subsequently, this set is compared with the purchaser's historical medication list to complete the conflict retrieval.

[0096] Furthermore, when the transaction scenario data simultaneously includes first-type scenario data (such as electronic medical record information) and second-type scenario data (such as spatiotemporal information of drug purchase behavior and drug purchaser profile), the anomaly detection step (S200) is configured to execute clinical applicability analysis and behavioral pattern anomaly analysis in parallel. In this hybrid scenario, evaluation will be performed simultaneously based on two independent dimensions: diagnostic logic and behavioral pattern, generating independent anomaly detection evidence for subsequent steps to perform comprehensive aggregation and judgment. Further, each piece of anomaly detection evidence generated in step S200 is structured as a data object containing an evidence type identifier and a confidence score. The evidence type identifier is used to uniquely distinguish the specific anomaly detection analysis type corresponding to the evidence, such as clinical_applicability, drug_conflict, purchase_frequency, geographical_aggregation, etc. This identifier determines the processing logic and weight applicable to the evidence in the subsequent aggregation and judgment steps. The confidence score is a quantitative value used to characterize the credibility or severity of the anomaly detection result. This score can originate from the analysis process itself (e.g., similarity score in matching calculation, the magnitude of deviation of behavioral indicators from the threshold) or can be directly output by the analysis model (e.g., probability values ​​given by machine learning models).

[0097] S300, aggregate all the abnormal detection evidence output by the at least one abnormal detection analysis to obtain the corresponding aggregation result, and determine whether the transaction behavior identified by the drug traceability code is in an abnormal state based on the aggregation result, and output the determination result.

[0098] In this invention, each input anomaly detection evidence (such as clinical suitability anomalies, drug conflict anomalies, behavioral pattern anomalies, etc.) is accompanied by two types of metadata: evidence type identifier and confidence score. Before aggregation, a basic weight is assigned to each evidence type according to a predefined evidence weight configuration table. This basic weight reflects the relative importance of this type of anomaly in the overall risk assessment (for example, the weight of "drug conflict anomaly" is usually much higher than that of "drug purchase frequency anomaly").

[0099] Specifically, the aggregation of all anomaly detection evidence output by the at least one anomaly detection analysis yields the corresponding aggregation result. This involves assigning weights to each anomaly detection evidence and performing weighted calculations to obtain the aggregation result.

[0100] In one illustrative embodiment, the weighted aggregation calculation can be implemented using an exemplary aggregation calculation function, the expression of which is: RS=Σ r∈G (D) r ×WCr ×T r ).

[0101] Where RS represents the aggregated risk score, which is the final quantitative result obtained through weighted calculation, used to comprehensively characterize the overall risk level of this transaction. This score will be compared with a preset judgment threshold to determine whether an abnormal state exists. G represents the set of anomaly detection evidence participating in this aggregate calculation. r represents a specific anomaly detection evidence in set G. D r This represents the confidence score of evidence r. This score is output by the anomaly detection analysis that generated the evidence (such as clinical applicability analysis, behavioral pattern anomaly analysis, etc.), and is a value between 0 and 1 (or 0 and 100), used to quantify the reliability or severity of the anomaly detection result. WC r This represents the weight coefficient corresponding to evidence r. This coefficient is obtained from a predefined weight mapping table based on the "evidence type identifier" of evidence r, reflecting the relative importance of this type of anomaly in the overall risk assessment (e.g., the weight coefficient for "drug conflict anomaly" is typically significantly higher than the weight coefficient for "drug purchase frequency anomaly"). T r This represents the time decay factor applied to evidence r (an optional parameter). For evidence related to historical behavioral patterns (e.g., spatiotemporal clustering calculated based on medication purchase records over the past year), this factor can be calculated to decay based on the time elapsed since the behavior involved in the evidence occurred (e.g., exponential decay), and its value ranges from 0 to 1. For evidence only relevant to the current transaction (e.g., the match rate of this diagnosis), its value is typically 1, indicating no decay. Σ_ r∈G This represents the summation of the weighted products of all evidence in set G.

[0102] In this invention, determining whether the transaction behavior identified by the drug traceability code is in an abnormal state based on the aggregation result and outputting the determination result can be achieved in the following two ways: Method 1: Output the binary decision result In this approach, the method is executed, and a binary judgment result of "normal" or "abnormal" is ultimately output. The S300 comprehensive judgment steps specifically include: S301, Priority Determination: First, check all anomaly detection evidence to see if there is any evidence that is preset to a high-risk type (such as "drug conflict anomaly"), and if its confidence score exceeds the high-risk confidence threshold set separately for that high-risk type. If the conditions are met, the transaction is directly determined to be in an abnormal state, and the process jumps to S303; otherwise, proceed to S302.

[0103] S302, Abnormal State Determination: If the above direct determination conditions are not met, proceed to this step. Compare the calculated aggregate risk score (RS) with a dynamic determination threshold. If the aggregate risk score exceeds the dynamic determination threshold, the transaction behavior is determined to be in an abnormal state; otherwise, it is determined to be in a normal state.

[0104] In this invention, the dynamic judgment threshold is not a fixed value; its value is dynamically calculated and generated by a risk factor model based on the multidimensional contextual features of the transaction. Key factors affecting this threshold include, but are not limited to: the medical insurance settlement amount of the transaction, the inherent risk level of the drug involved, and the credit score of the purchaser based on historical records. For example, for transactions involving high-value, high-risk drugs or purchasers with low credit, a lower judgment threshold will be used to implement stricter risk control.

[0105] S303, Decision Result Output: Output a structured decision result, which includes at least a conclusion on an abnormal or normal state.

[0106] Method 2: Output the classification result This approach provides a more refined risk assessment, outputting specific anomaly status levels. Its S300 comprehensive judgment steps specifically include: S310, Priority Determination: First, check all anomaly detection evidence to see if there is any evidence pre-defined as high-risk (e.g., "Drug Conflict Anomaly"), and if its confidence score exceeds the high-risk confidence threshold set separately for that high-risk type. If this condition is met, directly determine the anomaly status level of the transaction as the pre-defined highest risk level (e.g., "Urgent High Risk"), and then proceed to S330 to output the result. Otherwise, execute S320.

[0107] S320, Risk Level Determination: If the above direct classification conditions are not met, proceed to this step. Compare the calculated aggregate risk score (RS) with a dynamic judgment threshold. By determining the threshold range in which the RS value falls, map it to the corresponding abnormal state level.

[0108] The multiple level thresholds divide the risk continuous spectrum into several discrete levels. For example, thresholds T1 < T2 < T3 can be set to define: If RS≤T1, then it is considered normal; If T1 < RS ≤ T2, then it is judged as low risk; If T2 < RS ≤ T3, then it is classified as medium risk; If RS > T3, it is considered high risk.

[0109] The threshold values ​​(T1, T2, T3, ...) can be statically configured, or more preferably, dynamically configured. Their specific values ​​can be fine-tuned based on the context of the transaction (e.g., transaction amount, drug risk level, buyer credit), thereby achieving differentiated tiered management.

[0110] S330, Graded Result Output: Output a structured judgment result, which must include the determined abnormal state level. Preferably, the result may further include the aggregated risk score (RS), a list of key evidence types that triggered the abnormality, and the identifier of the judgment rule used, thereby providing a clear and traceable decision-making basis for subsequent differentiated handling processes (such as "low risk" only recording, "medium risk" prompting review, and "high risk" automatic interception and alarm).

[0111] Furthermore, a closed-loop feedback mechanism can be established to compare the final manual verification results with the judgment results. Using this data, machine learning algorithms can be used to periodically optimize the weights of evidence types and dynamic judgment thresholds, enabling the aggregated judgment model to continuously adapt and improve accuracy.

[0112] Furthermore, to form a closed-loop regulatory system, the method also includes the following processing steps: S400, Anomaly Report Generation and Push: When the S300 outputs an anomaly status (or an anomaly status of a specific level or higher), the report generation process is automatically triggered. This process is configured as follows: Report Generation: Based on the key anomaly detection evidence that triggered this judgment and related raw data, a structured and visualized risk report is automatically generated. This report clearly presents the anomaly type, risk level, key evidence chain (such as details of mismatch between diagnosis and medication, charts of abnormal behavior patterns, etc.), and related transaction traceability information in an easy-to-understand format, including charts and text summaries.

[0113] Secure push: The generated report will be pushed instantly to one or more pre-configured designated monitoring terminals (such as the medical insurance bureau's review system, hospital management department workstations, etc.) through a preset secure channel (such as a medical private network secure data exchange platform, encrypted message queue, etc.).

[0114] The beneficial effects of this step are: it achieves a seamless connection from automatic risk identification to handling prompts, delivers the results of intelligent analysis to the responsible supervisors in an intuitive and reliable manner, greatly improves the timeliness and accuracy of risk handling, and completes a closed loop of automated management of the entire process of "monitoring-analysis-judgment-response".

[0115] In summary, the present invention provides a drug data management method based on drug traceability codes, which has at least the following technical effects: 1. Improved efficiency and quality of association and fusion of multi-source heterogeneous data: By using drug traceability codes as a unified and unique index key, this invention effectively solves the technical challenge of quickly and accurately associating static drug attribute data and dynamic transaction scenario data in a distributed system. This design achieves low-coupling and high-precision fusion of two types of data (static knowledge base and dynamic behavior flow), providing a structurally complete and semantically related data foundation for subsequent analysis, and significantly improving the utilization efficiency of data resources.

[0116] 2. A scenario-oriented and scalable anomaly detection and analysis capability is achieved: By dynamically adapting and executing corresponding anomaly detection analyses based on the type of transaction scenario data, this invention constructs a modular and configurable analysis framework. Each analysis serves as an independent evidence generation unit, and its output is standardized into structured anomaly detection evidence. This design not only enhances the system's flexibility in handling different business scenarios (such as in-hospital medication and pharmacy drug purchases) but also allows for easy integration of new analysis models, thereby continuously improving the ability to identify complex anomaly patterns.

[0117] 3. A robust automated decision-making mechanism based on evidence aggregation was constructed: By aggregating discrete evidence generated from various anomaly detection analyses and making a comprehensive judgment based on the aggregation results, this invention upgrades traditional judgments based on single rules or thresholds to decisions based on multi-dimensional evidence weights and correlations. This mechanism reduces over-reliance on single data sources or analysis models, enhances the stability, objectivity, and anti-interference ability of the overall judgment conclusion, and realizes an intelligent closed loop from data to decision.

[0118] (Example 2) This embodiment provides a drug data management system based on drug traceability codes, the system comprising: The data association module is used to respond to receiving a drug traceability code, and use the drug traceability code as an index to associate and obtain at least two types of data related to the drug across systems. The first type of data includes a set of associated data on drug attributes and their indications, and the second type of data is the transaction scenario data corresponding to the drug traceability code.

[0119] An anomaly detection module is used to perform at least one anomaly detection analysis based on the type of the transaction scenario data, wherein the output of each anomaly detection analysis constitutes an anomaly detection evidence.

[0120] The determination module is used to aggregate all the abnormal detection evidence output by the at least one abnormal detection analysis to obtain the corresponding aggregation result, and based on the aggregation result, determine whether the transaction behavior identified by the drug traceability code is in an abnormal state, and output the determination result.

[0121] Furthermore, the system also includes: The data storage module is used to store the associated data set and organize the relationships between drugs, indications, chemical components and contraindications in the form of a graph database, providing knowledge query support to the anomaly detection module.

[0122] Furthermore, the anomaly detection module includes: The first analysis unit is used to perform clinical applicability analysis on transaction scenario data containing electronic medical record information; The second analysis unit is used to perform behavioral pattern anomaly analysis on transaction scenario data containing spatiotemporal information of drug purchase behavior. The first analysis unit and the second analysis unit can run in parallel or independently triggered by a scenario.

[0123] Furthermore, the system also includes: The interface adaptation module is used to adapt to the data interface specifications of medical insurance systems in different provinces and encapsulate the judgment results into standardized reporting messages that meet the local medical insurance supervision requirements.

[0124] Furthermore, the system is deployed in a secure interaction zone between the medical private network and the medical insurance private network. It uses a network gateway to achieve one-way data collection and communication from the medical side to the medical insurance side, ensuring the security of data flow. It should be noted that this system embodiment is based on the same inventive concept as the aforementioned method embodiment, and the functions and implementation methods of each module in the system correspond to the corresponding steps in the method embodiment. Therefore, the relevant technical features, implementation details, and achievable technical effects disclosed in the method embodiment are also applicable to this system embodiment, and will not be repeated here.

[0125] This invention also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being configured to perform the method described in this invention.

[0126] This invention also provides a computer-readable storage medium storing computer-executable instructions for performing the methods described in this invention.

[0127] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this invention can be achieved, and this is not limited herein.

[0128] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A drug data management method based on drug traceability codes, characterized in that, The method includes the following steps: S100, in response to receiving the drug traceability code, using the drug traceability code as an index, cross-system association and acquisition of at least two types of data related to the drug, wherein the first type of data includes a set of associated data of drug attributes and their indications, and the second type of data is the transaction scenario data corresponding to the drug traceability code; S200, based on the type of the transaction scenario data, perform at least one corresponding anomaly detection analysis, wherein the output of each anomaly detection analysis constitutes an anomaly detection evidence; S300, aggregate all the abnormal detection evidence output by the at least one abnormal detection analysis to obtain the corresponding aggregation result, and determine whether the transaction behavior identified by the drug traceability code is in an abnormal state based on the aggregation result, and output the determination result.

2. The method according to claim 1, characterized in that, The transaction scenario data includes either a first type of scenario data or a second type of scenario data; the first type of scenario data includes electronic medical record information related to diagnosis and treatment, and the second type of scenario data includes a profile of the drug purchaser and spatiotemporal information on drug purchase behavior.

3. The method according to claim 2, characterized in that, S200 specifically includes: If the transaction scenario data is of the first type, then a clinical applicability analysis is performed; If the transaction scenario data is the second type of scenario data, then perform behavioral pattern anomaly analysis.

4. The method according to claim 3, characterized in that, The clinical suitability analysis is configured to match the diagnostic information in the electronic medical record information with the indication information in the associated data set, and when the matching degree is lower than a preset matching degree threshold, output a behavioral abnormality indication signal indicating abnormal clinical suitability as evidence of abnormality detection.

5. The method according to claim 3, characterized in that, The behavioral pattern anomaly analysis is configured to: analyze the spatiotemporal clustering value or frequency value of the drug purchase behavior based on the spatiotemporal information of the drug purchase behavior, and / or, Based on the profile of the drug purchaser, analyze the matching degree between the profile of the drug purchaser and the target population of drugs indicated by the associated data set; When any of the spatiotemporal aggregation value, frequency value, or matching degree value exceeds the corresponding preset threshold, an abnormal behavior indication signal is output as evidence of abnormality detection.

6. The method according to any one of claims 1 to 5, characterized in that, The anomaly detection analysis also includes drug conflict analysis, which is configured to: based on the drug attributes, search in historical medication records for records of mutually exclusive drug use; if such records exist, output a behavioral anomaly indication signal indicating drug conflict as evidence of anomaly detection.

7. The method according to claim 1, characterized in that, In S300, all anomaly detection evidence output by the at least one anomaly detection analysis is aggregated to obtain the corresponding aggregation result. Specifically, weights are assigned to each anomaly detection evidence and weighted calculations are performed to obtain the aggregation result.

8. The method according to claim 1, characterized in that, The determination result includes an abnormal state level; S300 specifically includes: comparing the aggregation result with multiple level thresholds to determine the abnormal state level.

9. The method according to claim 1, characterized in that, The associated data set is stored in the form of a knowledge graph, wherein the nodes of the knowledge graph include drug chemical components, indications, and contraindications, and the edges of the knowledge graph represent treatment relationships or conflict relationships; at least one anomaly detection analysis in S200 is implemented based on traversing the knowledge graph.

10. A drug data management system based on drug traceability codes, characterized in that, The system includes: The data association module is used to respond to receiving a drug traceability code, and use the drug traceability code as an index to associate and obtain at least two types of data related to the drug across systems. The first type of data includes a set of associated data on drug attributes and their indications, and the second type of data is the transaction scenario data corresponding to the drug traceability code. An anomaly detection module is used to perform at least one anomaly detection analysis based on the type of the transaction scenario data, wherein the output of each anomaly detection analysis constitutes an anomaly detection evidence. The determination module is used to aggregate all the abnormal detection evidence output by the at least one abnormal detection analysis to obtain the corresponding aggregation result, and based on the aggregation result, determine whether the transaction behavior identified by the drug traceability code is in an abnormal state, and output the determination result.

Images