Drug use assisting system and device based on symptom-drug two-way verification

Abstract

The invention discloses a medication assisting system and device based on symptom-medicine two-way verification, and belongs to the technical field of intelligent medical treatment. The system comprises a data preprocessing module, an entity extraction and alignment module, an atlas retrieval module, a case retrieval module and a bidirectional verification and auxiliary decision module. The system extracts a medical entity through an AC automaton rule engine and a knowledge enhanced BERT model, and realizes mapping with a knowledge graph entity by adopting a two-stage term alignment strategy; performing knowledge graph query by adopting an operation chain generation mechanism driven by cue words to obtain a candidate drug set; meanwhile, similar cases are retrieved based on vector similarity, and an associated drug set is generated; and finally, fusing external medicine knowledge base data, executing a bidirectional verification and completion strategy, and outputting medicine recommendation with clinical safety and coverage range. The invention further provides a device structure for realizing the functions of the system, and the accuracy and interpretability of clinical medication aid decision making are effectively improved.

Description

Technical Field

[0001] The present invention belongs to the field of intelligent medicine, and specifically relates to a medication assistance system and device based on two-way verification of symptoms and drugs. Background Art

[0002] The current mainstream medical semantic parsing mechanisms are mainly based on rule matching or single machine learning models (such as traditional BERT), and face multiple challenges in actual medical scenarios: for example, limited semantic understanding ability easily leads to misjudgment of implicit symptoms, and existing knowledge bases are mostly statically designed, making it difficult to integrate multi-source medical data and causing information fragmentation; more importantly, due to the lack of an effective risk control mechanism, the system may give suggestions with medication taboos, directly affecting clinical safety. These key problems seriously affect the clinical application value of the system.

[0003] In addition, although knowledge graphs are good at structured reasoning and large language models (such as ChatGPT) are good at semantic understanding, there are still key technical obstacles in their combination. On the one hand, traditional one-way retrieval mechanisms (such as only deriving drugs from symptoms) lack reverse verification of case data, which may lead to incomplete recommendation results; on the other hand, there are differences between the triple structure of the knowledge graph and the vector representation of case texts, which easily lead to information conflicts and contradictory outputs. Summary of the Invention

[0004] The technical problem to be solved by the present invention is the problems of inaccurate semantic understanding, weak knowledge fusion ability, and insufficient safety verification existing in the existing medical information parsing system during decision-making. To solve the above problems, the present invention provides a medication assistance system and device based on two-way verification of symptoms and drugs.

[0005] The content of the present invention includes the following aspects.

[0006] In the first aspect, an embodiment of the present invention provides a medication assistance system based on two-way verification of symptoms and drugs.

[0007] The system specifically includes: a data preprocessing module, an entity extraction and alignment module, a graph retrieval module, a case retrieval module, and a two-way verification and auxiliary decision-making module.

[0008] The data preprocessing module: is used to preprocess the medical knowledge graph, clean the medical Q&A dataset, generate symptom vectors, and establish structured cases and store them in the vector database.

[0009] The entity extraction and alignment module: is used to combine a rule engine and a knowledge-enhanced BERT model to implement symptom entity extraction in medical description texts or clinical expression fragments, and align with the entities in the knowledge graph to obtain target entities.

[0010] Graph Retrieval Module: It is used to perform structured parsing on medical description texts, generate a multi-step operation chain based on a prompt word template containing the target entity and predefined relationship types, and obtain a candidate drug set by executing the knowledge graph query instructions and logical set operations in the operation chain.

[0011] Case Retrieval Module: It is used to vectorize the target entity, match similar cases in the vector database based on the target vector, and generate an associated drug set.

[0012] Bidirectional Verification and Auxiliary Decision-making Module: Based on the data in the external medical knowledge base, it dynamically integrates the candidate drug set and the associated drug set, and realizes multi-source fusion decision-making through bidirectional verification and screening.

[0013] Optionally, the data preprocessing module includes a graph construction unit and a case processing unit.

[0014] The graph construction unit is used to extract three core relationships of disease-symptom, drug-indication, and drug-contraindication from open-source structured medical data sources, and construct a medical knowledge graph.

[0015] The entity nodes and relationships in the graph are stored in the Neo4j graph database in the form of entity-relationship-entity triples.

[0016] The case processing unit is used to perform case screening and structured parsing on the open-source medical session dataset, and extract the original symptom text, symptom entities, and their corresponding doctor suggestions for each case.

[0017] The ClinicalBERT model is used to perform embedding representation on the symptom entities, generate multi-dimensional symptom vectors, and be used for similarity matching in the case retrieval module.

[0018] A structured case set is constructed in the vector database, and each case entry contains five core fields: case ID (case_id), symptom entity (symptom_entity), symptom vector (symptom_embedding), doctor answer text (answer), and original symptom text (raw_symptoms).

[0019] Optionally, the entity extraction and alignment module adopts a hybrid two-layer architecture and a stage alignment strategy to achieve accurate extraction of symptom entities and alignment with the knowledge graph, including a rule-driven layer, a model enhancement layer, and a stage alignment unit.

[0020] The rule-driven layer is based on the rule engine of the AC automaton. Through the pre-constructed medical knowledge graph entity library, it performs exact string matching on medical description texts or clinical expression fragments, extracts explicit entities, and directly retains the results.

[0021] The model enhancement layer processes the input text through a Dual-channel Embedding Fusion BERT model (DCEF-BERT), where the dual-channel includes a knowledge graph embedding channel and a context embedding channel.

[0022] The knowledge graph embedding channel extracts the topological relationships and hierarchical paths of entity nodes in the knowledge graph through a graph neural network to generate structured knowledge embeddings.

[0023] The context embedding channel retains the original word vectors and position encodings of the BERT model to capture the context semantics of the input text.

[0024] The stage alignment unit is used to perform multi-level semantic alignment on implicitly matched entities, and uses semantic similarity calculation to filter and input into the first large language model for optimal selection to ensure semantic consistency of complex term expressions.

[0025] Furthermore, the Dual-channel Embedding Fusion BERT model (DCEF-BERT) includes designing a dual-channel input structure, designing a dynamic fusion gating mechanism, and model training.

[0026] Designing a dual-channel input structure: a knowledge graph embedding channel and a context embedding channel.

[0027] The knowledge graph embedding channel encodes the node relationship paths of the medical knowledge graph through a graph attention network (GAT) to generate topological feature embeddings including disease-symptom hierarchies and drug indication associations.

[0028] The context embedding channel retains the original word embeddings, segment embeddings, and position encodings of BERT to capture the local semantics and global dependencies of the input text.

[0029] Designing a dynamic fusion gating mechanism, which performs weighted fusion on the dual-channel embeddings through a learnable parameter matrix and an activation function, and can be specifically expressed as: ; .

[0030] Among them, is the fusion weight coefficient, is a learnable parameter matrix, represents a non-linear activation function, the knowledge embedding is a structured entity representation extracted from the medical knowledge graph through a graph attention network, and the context embedding is a combination of the original word vectors, position encodings, and segment vectors generated by the BERT model when processing the input text.

[0031] The fine-tuning method of the model includes collecting training samples and model training.

[0032] Collect paired user symptom descriptions and standardized entity labels from open-source medical text datasets (such as CMCQA) to construct unstructured training samples.

[0033] Based on the training samples, freeze the underlying parameters of the BERT base model, only update the parameters of the dual-channel embedding layer, the dynamic gating layer, and the top-level Transformer block, and perform fine-tuning using a joint loss function, which is defined as: 。

[0034] Among them, is the knowledge graph topological feature matching loss, is the text context semantic matching loss, is the dynamic weight coefficient, and its value is determined according to the coverage rate of entities in the training data by the knowledge graph.

[0035] When the coverage rate is higher than the first threshold, take the first preset value, preferably 0.6; when the coverage rate is lower than the second threshold, take the third preset value, preferably 0.4; when the coverage rate is between the first threshold and the second threshold, take the second preset value, preferably 0.5.

[0036] Input the fused embedding into the Transformer encoding layer of BERT, and capture the interaction features with potential associations between different channels through the multi-head self-attention mechanism, improving the recognition ability for long-tail symptoms and various expression ambiguities.

[0037] Furthermore, the stage alignment unit specifically includes the following.

[0038] Retain the explicit entities output by the rule-driven layer as the aligned results.

[0039] For the implicit entities output by the model enhancement layer, calculate the cosine similarity between each implicit entity and the nodes of the knowledge graph, and generate a corresponding Top-K (K is an integer greater than or equal to 3, and its value is determined based on the balance condition of the preset entity coverage rate threshold and computing resource constraints) candidate entity list.

[0040] Call the first large language model, and based on the prompt template containing medical description text or clinical expression fragments, implicit entities, and the corresponding Top-K candidate entity list, screen out the entity that is most semantically close to the medical description text context from the Top-K candidate entity list corresponding to each implicit entity as the target entity.

[0041] Furthermore, the graph retrieval module includes an operation chain generation unit and a logic execution unit.

[0042] The operation chain generation unit calls the second large language model to parse the medical description text, and generates a structured operation chain based on a prompt template that includes target entities in the aligned knowledge graph and predefined relationship types.

[0043] The structured operation chain describes a multi-step operation sequence in JSON format, including the following two types of operation items.

[0044] Query operation item: Defines a knowledge graph query instruction, including entity name, relationship type (possible diseases / recommended medications / contraindicated medications / indications), and an intermediate result storage identifier, such as {"type": "query", "entity_set": "diabetes", "relation": "contraindicated medications", "store_as": "A"}.

[0045] Logical operation item: Defines set operations on intermediate results, limits the use of three types of operators: exclude, intersect, and merge, and specifies the target data and operation rules for the operation, such as {"type": "operation", "name": "exclude", "sources": ["C"], "exclude": ["A","B"]}, where A and B are intermediate result key names.

[0046] The logical execution unit is used to sequentially execute the JSON operation chain, specifically including the following content.

[0047] Identify the entity_set field in the query operation item, obtain a single entity or a set, call the predefined Cypher template library through the Bolt protocol of Neo4j, execute a single query or a loop query operation, and temporarily store the results in the intermediate storage area.

[0048] Call the predefined operator dictionary (such as exclude: set(A).difference(B)) to perform chained processing on the intermediate results, specifically including: Exclusion operation: Remove the intersection elements of the exclusion set from the source set; Intersection operation: Extract the common elements of multiple sets; Merge operation: Perform deduplication and union on multi-source results.

[0049] Persistently store the results after the chained processing through the final key name (such as "result") of the intermediate storage area as the final candidate drug set, and associate it with the input interface of the two-way verification and auxiliary decision-making module.

[0050] Optionally, the case retrieval module specifically includes the following.

[0051] The ClinicalBERT model is used to vectorize the target entities output by the entity extraction and alignment module, generating a multi-dimensional symptom vector with the same dimension as the symptom_embedding field of the case processing unit to ensure the consistency of the vector space structure.

[0052] Using the symptom vector as the query vector, a two-stage approximate nearest neighbor search is adopted.

[0053] Coarse quantization partition stage: The vector space is divided into cluster centers, and the candidate partition is determined by calculating the Euclidean distance between the query vector and each cluster center. The distance formula is: .

[0054] Fine search and sorting stage: Within the candidate partition, calculate the Euclidean distance between the query vector and each case vector, and arrange the distance values in ascending order to screen out the Top-K candidate cases, where K takes an integer value from 2 to 5.

[0055] The Euclidean distance formula for the fine search stage is: .

[0056] Where is the query vector, is the vector dimension, represents the i-th component of the query vector , represents the i-th component of the i-th cluster center vector ; represents the i-th component of the candidate case vector ; and are respectively the Euclidean distances between

[0057] and the cluster center and the case vector, reflecting their similarity in the vector space.

[0058] Optionally, the two-way verification and auxiliary decision-making module specifically includes an external knowledge interface unit, a two-way verification unit, and a fusion decision-making unit.

[0059] The external knowledge interface unit is used to call the external medical knowledge base API (interface) to perform three data acquisition operations: Based on the symptom entities obtained by the entity extraction and alignment module, obtain all its medical aliases to form an extended symptom set (extended_symptom_set); Based on the drug entities in the candidate drug set obtained by the graph retrieval module, obtain the indication set and contraindication set corresponding to each drug; Based on the drug entities in the associated drug set obtained by the case retrieval module, obtain the indication set corresponding to each drug.

[0060] The two-way verification unit is used to perform drug safety screening operations.

[0061] Screen drug entities from the candidate drug set that meet the following two conditions: The intersection of the contraindication set corresponding to the drug entity and the extended symptom set (extended_symptom_set) is empty; The intersection of the indication set corresponding to the drug entity and the extended symptom set (extended_symptom_set) is non-empty.

[0062] Form a safe candidate drug set (safe_candidate_drug_set) with the drug entities that meet the above two conditions.

[0063] The fusion decision unit is used to perform operations for completing uncovered symptoms and marking extended drugs.

[0064] Based on the union of the indications of the drugs in the safe candidate drug set (safe_candidate_drug_set), determine the set of symptoms in the medical description text that can be covered.

[0065] Perform a difference operation between this set and the total symptom set in the medical description text to obtain an uncovered symptom set (uncovered_symptom_set).

[0066] For each drug entity in the associated drug set, if the intersection of its indication set and the uncovered symptom set exists, mark the drug entity as an extended drug to obtain an extended drug set (extended_drug_set).

[0067] Form a final recommended drug set (final_recommendation_set) with the safe candidate drug set (safe_candidate_drug_set) and the extended drug set (extended_drug_set).

[0068] The second aspect of the present invention provides an electronic device for implementing a medication assistance system based on two-way verification of symptoms and drugs. The device includes a processor, a memory, and a communication bus. The memory is a computer-readable storage medium on which program codes executable by the processor are stored; the communication bus is used to connect the processor and the memory to realize data interaction and communication.

[0069] When the processor executes the computer program in the memory, it can realize all functions of the system, including: construction of a medical knowledge graph and preprocessing of a question-and-answer dataset, extraction and alignment of symptom entities, fusion of multi-case data, two-way verification strategy, and the reasoning process of final medication recommendation.

[0070] The beneficial effects of the present invention are as follows: it significantly improves the semantic understanding and knowledge fusion capabilities of the medical information parsing system. By combining the topological features of the knowledge graph and the context semantics of the text through the Dual-Channel Embedding Fusion BERT model (DCEF-BERT), the system effectively solves the problem of insufficient recognition of implicit symptoms and complex terms by traditional single models. By adopting multi-level semantic screening and the optimal selection of large language models, it accurately aligns long-tail symptoms and diverse expressions, combining the structural reasoning advantages of the knowledge graph and the empirical judgment ability of clinicians. Brief Description of the Drawings

[0071] Figure 1 is a medication assistance system based on two-way verification of symptoms and drugs provided by an embodiment of the present invention; Figure 2 is a flowchart of a medication assistance system based on two-way verification of symptoms and drugs provided by an embodiment of the present invention; Figure 3 is a schematic structural diagram of DCEF-BERT provided by an embodiment of the present invention; Figure 4 is a flowchart of two-way verification and auxiliary decision-making provided by an embodiment of the present invention; Figure 5 is a schematic structural diagram of the electronic device provided by an embodiment of the present invention. Detailed Embodiments

[0072] In the embodiments of the present application, the term "a plurality of" means two or more, and other quantifiers are similar. The terms "first", "second", etc. in the description and claims of the present application are used to distinguish similar objects, rather than to describe a specific order or sequence. It should be understood that such terms can be interchanged under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described herein, and the objects distinguished by "first" and "second" are usually of the same category, and do not limit the number of objects. For example, the first object can be one or more.

[0073] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the protection scope of the present invention.

[0074] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those of ordinary skill in the technical field to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0075] The embodiments of the present application provide a medication assistance system and device based on symptom-drug two-way verification, aiming to solve the technical problems of inaccurate semantic understanding, weak knowledge fusion ability, and insufficient medication safety verification existing in the existing medical semantic parsing mechanism during medication decision-making.

[0076] Please refer to Figure 1 , Figure 1 which is a medication assistance system based on symptom-drug two-way verification provided by the embodiments of the present invention, specifically including: a data preprocessing module, an entity extraction and alignment module, a graph retrieval module, a case retrieval module, and a two-way verification and auxiliary decision-making module.

[0077] The data preprocessing module is used to preprocess the medical knowledge graph, clean the medical Q&A data set, generate symptom vectors, and establish a structured case and store it in the vector database.

[0078] The entity extraction and alignment module is used to combine a rule engine and a knowledge-enhanced BERT model to implement symptom entity extraction in medical description texts or clinical expression fragments, and align with the entities in the knowledge graph to obtain target entities.

[0079] A graph retrieval module for structurally parsing medical description texts, generating a multi-step operation chain based on a prompt template containing the target entity and predefined relationship types, and obtaining a candidate drug set by executing the knowledge graph query instructions and logical set operations in the operation chain.

[0080] A case retrieval module for vectorizing the target entity, matching similar cases in the vector database based on the target vector, and generating an associated drug set.

[0081] A two-way verification and auxiliary decision-making module that dynamically integrates the candidate drug set and the associated drug set based on external medical knowledge base data, and realizes multi-source fusion decision-making through two-way verification and screening.

[0082] It should be clear that a large language model (LLM) refers to a deep learning system trained based on a large amount of text data, capable of generating natural language text or understanding semantic information. Its architecture design can be flexibly configured according to specific application scenarios and is not limited here. In this solution, the first to third large language models all belong to the category of LLM. However, due to differences in the functional tasks they undertake, their model architectures will be adjusted accordingly, and the specific implementation method needs to be customized and optimized according to actual business requirements and is not limited here.

[0083] It should be understood that an external medical knowledge base interface (Application Programming Interface, API) refers to an application program interface that interacts with professional databases in the medical field through a standardized protocol, capable of realizing real-time query and data call of medical knowledge. Its specific docking method and functional modules can be flexibly configured according to actual business requirements and are not limited here. However, due to differences in the knowledge base sources and data formats docked by each interface, its request parameters, response structure, and data processing logic will be adjusted accordingly, and the specific implementation needs to be customized and optimized according to medical business scenarios and is not limited here.

[0084] As Figure 2 shown, Figure 2 is a flowchart of a medication assistance system based on two-way verification of symptoms and drugs provided by an embodiment of the present invention. In the data preprocessing module, as the basic support part of the system, it is mainly used to construct a high-quality medical knowledge graph and establish a structured case library; this module includes a graph construction unit and a case processing unit.

[0085] Among them, the graph construction unit extracts three types of core relationships, namely disease-symptom, drug-indication, and drug-contraindication, from the open-source structured medical data source, constructs a medical knowledge graph in the form of "entity-relationship-entity" triples, and stores it in the Neo4j graph database to achieve a structured organization for graph queries.

[0086] Exemplarily, in specific implementation, the open-source medical knowledge graph (MedicalKG) is adopted, and relationship extraction and filtering processing are performed on it by writing automated scripts, and the domain adaptability optimization of the knowledge graph is realized by using preset relationship constraint conditions.

[0087] The case processing unit focuses on screening and structured parsing of the medical conversation dataset (such as CMCQA). Specifically, it includes extracting the original symptom text, explicit and implicit symptom entities, and corresponding doctor's advice information in each conversation. In this embodiment, the ClinicalBERT model is used to perform vector embedding on the extracted symptom entities to generate high-dimensional symptom representations (symptom_embedding), and together with fields such as case ID, doctor's answer, and original text, they form structured case entries and are uniformly stored in the vector database.

[0088] Exemplarily, in specific implementation, by constructing a structured prompt word template containing key information, specific instructions, and implementation examples, and calling the large language model API to achieve efficient information extraction, which not only significantly reduces the manual annotation cost but also ensures the accuracy of semantic parsing.

[0089] In the embodiment of the present invention, the entity extraction and alignment module adopts a hybrid two-layer architecture and a stage alignment strategy to achieve accurate recognition of symptom entities in medical description texts or clinical expression fragments and high-quality alignment with the knowledge graph, including a rule-driven layer, a model enhancement layer, and a stage alignment unit.

[0090] Specifically, the rule-driven layer relies on a pre-constructed medical knowledge graph entity dictionary and uses the Aho-Corasick Automaton as the core multi-pattern string matching algorithm to efficiently retrieve explicit medical entities in clinical expression fragments. Further, the system first constructs all entities in the entity dictionary into a Trie tree and generates corresponding failure pointers during the construction process, thus forming an automaton structure with state transition functions. In the text scanning stage, the system can identify all matching entity patterns in the input at one time, and the time complexity is only linearly related to the text length, greatly improving the processing efficiency of entity extraction. This method is especially suitable for fast query scenarios under a large-scale entity dictionary.

[0091] Specifically, such as Figure 3As shown, the model enhancement layer is based on the Dual-Channel Embedding Fusion BERT model (DCEF-BERT for short), aiming to comprehensively utilize the structural information of the knowledge graph and the context semantics of natural language text to achieve accurate deep semantic extraction of implicit medical entities. This model designs parallel knowledge graph embedding channels and context embedding channels. Among them, the knowledge graph embedding channel uses the Graph Attention Network (GAT) to encode the adjacency structure of the target entity in the graph, extract its topological path features in multiple relationship networks such as disease-symptom and drug-indication, and generate structured semantic embeddings. The context embedding channel follows the word vector, segment vector, and position encoding mechanisms of the original BERT model to capture the context dependencies and semantic details of entity expressions in the medical description text input.

[0092] To achieve the organic fusion of the two-channel information, DCEF-BERT introduces a dynamic fusion gating mechanism. This mechanism dynamically calculates the fusion weights according to the input context through a learnable parameter matrix and a non-linear activation function , to achieve a weighted combination of knowledge embedding and context embedding. This structure not only retains the reasoning advantages of the graph relationship but also enhances the expression ability for complex language phenomena such as implicit symptoms and ambiguous expressions. The fusion formula is as follows: ; .

[0093] Among them, is the fusion weight coefficient, is the learnable parameter matrix, represents the non-linear activation function. Knowledge embedding is the structured entity representation extracted from the medical knowledge graph through the graph attention network, and context embedding is the combination of the original word vectors, position encodings, and segment vectors generated by the BERT model when processing the input text.

[0094] Optionally, in some specific embodiments, during the construction of the training data, first use a large language model (such as ChatGPT) to perform preliminary entity extraction on open medical texts (such as the CMCQA dialogue dataset) and generate candidate pairs of medical descriptions and potential standard entities. Subsequently, perform secondary verification and manual marking to ensure that the data covers complex semantics and synonymous variant situations, providing training samples in a real clinical context for the model.

[0095] In order to improve the generalization ability and expression accuracy of the DCEF-BERT model in medical entity extraction tasks, a fine-tuning strategy based on joint loss was designed during the model training phase, that is, DCEF-BERT freezes the underlying parameters of the basic BERT model and only optimizes the parameters of the dual-channel embedding layer, gated fusion layer, and top-level Transformer encoding layer. The training objective is constrained and optimized using a joint loss function, which is defined as follows: .

[0096] in, Represents the structural matching loss based on graph embedding, which is used to constrain the model's learning of topological semantics; The entity classification loss that represents the contextual semantics is used to strengthen the model's understanding of language expression; the weight coefficient According to the dynamic setting of knowledge graph coverage, when the entity coverage is high, the structural guidance ratio is increased (such as a value of 0.6), otherwise it is biased towards language semantics (such as a value of 0.4) to achieve a dynamic balance between structure and semantics. This training mechanism effectively improves the model's ability to recognize rare symptoms, ambiguous expressions, and complex dependencies.

[0097] In order to further improve the matching accuracy between implicit entities and knowledge graphs, a stage alignment unit is designed to achieve semantic comparison and entity confirmation based on the output of the model enhancement layer. Among them, the entities that have been accurately hit by the rule-driven layer are directly retained as aligned results; while the remaining hidden entities that have not been hit enter the semantic alignment process.

[0098] Specifically, the system constructs a vector representation of each implicit entity and the entity node in the graph, and generates a Top-K candidate entity list through cosine similarity calculation and screening. Preferably, the K value is generally set to 3 to 5, which is set according to the scale of the knowledge graph and computing resources. Subsequently, a large language model (such as GPT) is called to input medical description text or clinical expression fragments, implicit entities to be matched and their corresponding candidate entity lists in the form of prompt word templates, and finally outputs the entity that is closest to the context semantics and consistent with the semantic consistency of the graph as the target alignment result.

[0099] In the embodiment of the present invention, the graph retrieval module is used to realize drug reasoning query based on structured semantics, and the core goal is to efficiently screen out a set of candidate drugs related to the input symptoms from the knowledge graph. This module mainly includes two submodules: an operation chain generation unit and a logic execution unit.

[0100] First, the operation chain generation unit receives the aligned target entities and calls a large language model to perform semantic parsing on medical description texts or clinical expression fragments. Combining with predefined prompt templates and graph relationship types (such as "possible diseases", "recommended medications", "contraindicated medications", "indications", etc.), it generates a structured operation chain. This operation chain is described in JSON format and consists of a series of query instructions and set operations. Each step points to specific knowledge graph entities and relationships, ensuring the logical transparency of the operation process.

[0101] Preferably, in specific implementation, the structured prompt template includes four key parts: identity indication, operation instructions, reasoning examples, and target construction tasks. This prompt structure can make the large language model clear about the task instructions, constrain its output format, and facilitate subsequent extraction.

[0102] In the graph retrieval module, the logic execution unit executes all queries and set operations in the order of the operation chain. The query operation item identifies the entity_set field, calls the Neo4j graph database, and relies on the Cypher template to perform graph retrieval.

[0103] Specifically, before the system executes a query, it first determines whether the entity referred to in this field is a single entity or an entity set: If it is a single entity, the system directly performs a query operation on this entity. For example: {"type": "query", "entity_set": "antipyretic", "relation": "indication", "store_as": "C"}; It means to perform an "indication" relationship query on the single entity "antipyretic"; If it is an entity set, it will perform loop parsing on each element in the set, execute the same graph query instructions in sequence, and merge all results into the intermediate storage area. For example: {"type": "query", "entity_set": "A", "relation": "indication", "store_as": "D"}; It means that "A" is the entity set generated in the previous step. The system will perform an "indication" relationship query on each element in the set and store all results in the variable with the key name "D". This mechanism ensures the high flexibility and scalability of the graph retrieval process, which is applicable to both simple entity path reasoning and complex multi-entity joint query scenarios.

[0104] Logical operation items perform set operations between candidate sets according to a predefined operator dictionary, supporting three basic operations: intersection (intersect), exclusion (exclude), and merge. For example, the system can first query all "recommended medications" and then exclude the entity set related to "contraindicated medications" to obtain a candidate drug set that complies with the medication safety rules.

[0105] Specifically, an operator dictionary (OPERATIONS) is defined inside the system to uniformly process set operations. This dictionary maps each set operation to a specific execution function, which can automatically call the appropriate operation method and merge the results. It mainly supports three basic operations: exclude (exclusion): used to remove one or more elements from the exclusion set from the source set, and its implementation form is: That is, taking the difference set of the source set, which is often used to exclude contraindicated drugs from candidate drugs; intersect (intersection): used to obtain the common elements of two sets, and its implementation form is: Can be used to filter out entities that simultaneously meet multiple relationship conditions; merge (merging): used to de-duplicate and combine multiple sets to form a union, and its implementation is: Suitable for summarizing the results of multiple query paths into a unified candidate list; When the system executes each set operation, it will automatically read the corresponding key name entity set from the intermediate storage area, perform set operations according to the operation type, and write the result back to a new identification variable.

[0106] In the embodiment of the present invention, the case retrieval module aims to match highly relevant historical cases in the structured case database based on the target symptom entity through similarity calculation. First, the system vectorizes and encodes the aligned symptom entities through the ClinicalBERT model to generate an embedding representation with the same dimension as the symptom vector (symptom_embedding) field in the vector database. To ensure calculation efficiency and matching effect, this module adopts a two-stage approximate nearest neighbor retrieval strategy, first performing coarse quantization partitioning and then fine search and sorting.

[0107] Specifically, in the coarse quantization partitioning stage, a clustering algorithm is used in advance to divide the vector space into cluster centers. During retrieval, the Euclidean distance between the query vector and each cluster center is calculated to quickly locate the candidate partition. The distance formula is: 。

[0108] In the refined search and sorting stage, the Euclidean distance between each case vector and the query vector is sorted only within the candidate partition, and the Top-K most similar cases are selected from it (generally, K ranges from 2 to 5). The example formula is as follows: 。

[0109] Among them, is the symptom query vector, is the candidate case vector, is the vector dimension (such as 768); the matched Top-K cases, together with their original symptom texts and doctor's suggestions, will be used as context inputs to call the large language model for semantic fusion analysis, and further infer the drug set that conforms to the current medical description text or clinical expression fragment.

[0110] In the embodiment of the present invention, the two-way verification and auxiliary decision-making module, as the final decision-making link of the system of the present invention, is mainly responsible for cross-verifying the atlas reasoning result and the case matching result, completing drug screening based on external medical knowledge, and forming the final medication advice with clinical guiding significance. This module includes three core units: an external knowledge interface unit, a two-way verification unit, and a fusion decision-making unit.

[0111] Please refer to Figure 4 , in specific implementation, the external knowledge interface unit is mainly used to call the external medical knowledge base API to implement the acquisition of three types of information: symptom entities extracted based on the medical description text or clinical expression fragment and aligned, retrieve all its medical aliases, and construct an extended symptom set (extended_symptom_set); based on the candidate drug set output by the atlas retrieval module, obtain the indication and contraindication sets of each drug; based on the associated drug set obtained by the case retrieval module, extract its indication set.

[0112] In the two-way verification and auxiliary decision-making module, the two-way verification unit is responsible for identifying "safe candidate drugs" with clinical adaptability in the cross-comparison of multi-source data. The specific screening logic is as follows: First, for each drug in the candidate drug set, the system separately determines whether there is an intersection between its "contraindication set" and "extended symptom set". If there is an intersection, the drug has potential medication risks and needs to be excluded; then it further determines whether there is an intersection between its "indication set" and "extended symptom set". If there is no intersection, it is considered that the drug lacks clear applicability and is also excluded. In specific implementation, since the lengths of each entity expression may be different, the number of characters matched can be used for screening; only when the drug meets the two conditions of "the contraindication is an empty intersection and the indication is a non-empty intersection" will it be retained as the safe candidate drug set (safe_candidate_drug_set).

[0113] Its specific logic can be described as follows: for each drug in candidate_drug_set do if (contraindications(drug) ∩ extended_symptom_set = Ø) and (indications(drug) ∩ extended_symptom_set ≠Ø) then add drug to safe_candidate_drug_set end if end for。

[0114] After the fusion decision-making unit completes the preliminary safety screening, it further integrates the drug entities in the associated drug set and performs the operations of filling in the uncovered symptoms and expanding the drug labels. The system first calculates the union of all the indications of the drugs in the safe candidate drug set (safe_candidate_drug_set), and determines the set of symptoms of the medical description text that can be covered currently based on this. Subsequently, by performing a difference set calculation with the original symptom set in the medical description text, the symptoms that have not been fully covered (uncovered_symptom_set) are identified. For these uncovered symptoms, the system traverses each drug entity in the associated drug set. If there is an intersection between its indication set and the uncovered symptom set, it means that it has the potential to make up for the insufficient coverage of the current drug recommendation plan, and this drug is marked as an "extended drug" and included in the extended drug set (extended_drug_set). In other words, the system will find the drug entities in the associated drug set that cannot fully cover the medical description in the safe candidate drug set, which can improve the comprehensiveness of the final recommendation result.

[0115] The specific logic above can be described as follows: covered_symptoms ← union of indications in safe_candidate_drug_set uncovered_symptom_set ← user_symptoms − covered_symptoms for each drug in related_drug_set do if indications(drug) ∩ uncovered_symptom_set ≠Ø then add drug to extended_drug_set end if end for。

[0116] Finally, the system combines the safe candidate drug set (safe_candidate_drug_set) and the extended drug set (extended_drug_set) as the final recommended drug set (final_recommendation_set), that is: final_recommendation_set ← safe_candidate_drug_set ∪ extended_drug_set。

[0117] Please refer toFigure 5 , the electronic device includes a processor, a memory, and a communication bus; wherein, the memory stores a computer program executable by the processor, and the program is used to implement all steps of the aforementioned medication assistance system. The communication bus is used to achieve data connection and collaborative operation within the device.

[0118] It should be specifically noted that the system involved in this application aims to provide semantic modeling and structured assisted analysis of drug-related knowledge based on medical description texts, clinical expression fragments, knowledge graph relationships, and case data, and belongs to a medical information processing and reference tool; the drug set output by the system is only used as part of the clinical auxiliary information for medical personnel with professional qualifications to make comprehensive judgments in combination with the actual situation during the diagnosis and treatment process.

[0119] It should be particularly noted that the present invention does not have the function of directly guiding, determining, or substituting the doctor's diagnosis and treatment behavior, nor does it provide specific medication advice for individual members of the public. The final medication selection should be determined by a doctor with the corresponding qualifications based on the patient's physical signs, medical history, and other medical test data.

[0120] The above are only the preferred embodiments of the present invention and are not intended to limit the present invention. For those skilled in the art, the present invention can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. A medication assistance system based on symptom-drug bidirectional verification, characterized in that: It includes data preprocessing module, entity extraction and alignment module, graph retrieval module, case retrieval module and two-way verification and decision support module; Data preprocessing module: used to preprocess the medical knowledge graph, clean the medical question and answer data set, generate symptom vectors, and establish structured cases to store in the vector database; Entity extraction and alignment module: used to combine the rule engine and the knowledge-enhanced BERT model to extract symptom entities from medical description texts or clinical expression fragments, and align them with the entities in the knowledge graph to obtain the target entity; Graph retrieval module: used to perform structured analysis on medical description texts, generate a multi-step operation chain based on a prompt word template containing the target entity and a predefined relationship type, and obtain a candidate drug set by executing the knowledge graph query instructions and logical set operations in the operation chain; Case retrieval module: used for vectorizing the target entity, matching similar cases in the vector database based on the target vector, and generating a set of associated drugs; Bidirectional verification and decision-making support module: Based on external medical knowledge base data, dynamically integrate candidate drug sets and related drug sets, and realize multi-source fusion decision-making through bidirectional verification screening.

2. The system according to claim 1, characterized in that The data preprocessing module includes a graph construction unit and a case processing unit; The graph construction unit is used to extract three core relationships of disease-symptom, drug-indication, and drug-contraindication from open source structured medical data sources to construct a medical knowledge graph; Store the entity nodes and relationships in the graph in the form of entity-relationship-entity triples in the Neo4j graph database; The case processing unit is used to perform case screening and structured analysis on the open source medical conversation data set, extracting the original symptom text, symptom entity and corresponding doctor's advice of each case; The ClinicalBERT model is used to embed the symptom entity and generate a multi-dimensional symptom vector for similarity matching in the case retrieval module; A structured case collection is constructed in the vector database, and each case entry contains five core fields: case ID, symptom entity, symptom vector, doctor's answer text and original symptom text.

3. The system according to claim 1, characterized in that The entity extraction and alignment module adopts a hybrid two-layer architecture and a stage alignment strategy to achieve accurate extraction of symptom entities and alignment with the knowledge graph, including a rule-driven layer, a model enhancement layer, and a stage alignment unit; The rule-driven layer is based on the rule engine of AC automaton, and uses the pre-built medical knowledge graph entity library to perform string precise matching on medical description text or clinical expression fragments, extract explicit entities and directly retain the results; The model enhancement layer processes the input text through the DCEF-BERT model, which includes: The knowledge graph embedding channel extracts the topological relationship and hierarchical path of entity nodes in the knowledge graph through the graph neural network to generate structured knowledge embedding; The context embedding channel retains the original word vector and position encoding of the BERT model to capture the contextual semantics of the input text; The stage alignment unit is used to implement multi-level semantic alignment for implicit entities that are not exactly matched, and uses semantic similarity calculation to screen and input into the first language model for optimal selection to ensure the semantic consistency of complex term expressions.

4. The system according to claim 3, characterized in that The DCEF-BERT model includes: Design a dual-channel input structure, including: The knowledge graph embedding channel encodes the node relationship path of the medical knowledge graph through the graph attention network to generate topological feature embeddings containing disease-symptom hierarchy and drug-indication associations; The context embedding channel retains BERT's original word embedding, segment embedding, and position encoding, capturing the local semantics and global dependencies of the input text; A dynamic fusion gating mechanism is designed to perform weighted fusion of dual-channel embeddings through learnable parameter matrices and activation functions, which can be specifically expressed as: in, is the fusion weight coefficient, is the learnable parameter matrix, represents a nonlinear activation function. Knowledge embedding is a structured entity representation extracted from the medical knowledge graph through a graph attention network. Context embedding is a combination of the original word vector, position encoding, and segment vector generated by the BERT model when processing the input text. Fusion embedding is the final feature representation obtained by weighted calculation of knowledge embedding and context embedding under a dynamic gating mechanism. The fine-tuning method of the model includes: Collect pairs of user symptom descriptions and standardized entity labels from open source medical text datasets to construct unstructured training samples; Based on the training samples, the underlying parameters of the BERT base model are frozen, and only the parameters of the dual-channel embedding layer, the dynamic gating layer, and the top-level Transformer block are updated, and fine-tuned using a joint loss function, which is defined as: in, is the knowledge graph topology feature matching loss, is the text context semantic matching loss, is a dynamic weight coefficient, whose value is determined according to the coverage of entities in the knowledge graph in the training data: when the coverage is higher than the first threshold, Take the preset value 1; when the coverage rate is between the first threshold and the second threshold, Take the preset value 2; when the coverage rate is lower than the second threshold, Take the preset value three; The fused embedding is input into the Transformer encoding layer of BERT, and the interactive features with potential correlations between different channels are captured through the multi-head self-attention mechanism, thereby improving the recognition ability of long-tail symptoms and various expression ambiguities.

5. The system according to claim 3, characterized in that The phase alignment unit specifically includes: Keep the explicit entities output by the rule-driven layer as the aligned results; For the hidden entities output by the model enhancement layer, the cosine similarity between each hidden entity and the knowledge graph node is calculated to generate a corresponding Top-K candidate entity list; Wherein, K is an integer greater than or equal to 3, and its value is determined based on a balance condition between a preset entity coverage threshold and computing resource constraints; The first language model is called, and based on the prompt word template containing medical description text or clinical expression fragments, implicit entities and corresponding Top-K candidate entity lists, the entity closest to the contextual semantics of the medical description text is screened out as the target entity from the Top-K candidate entity list corresponding to each implicit entity.

6. The system according to claim 1, characterized in that The graph retrieval module includes an operation chain generation unit and a logic execution unit; The operation chain generation unit calls the second language model to parse the medical description text, and generates a structured operation chain based on a prompt word template containing a target entity aligned with the knowledge graph and a predefined relationship type; The structured operation chain describes a multi-step operation sequence in JSON format, including the following two types of operation items: Query operation item: defines the knowledge graph query instruction, including entity name, relationship type and intermediate result storage identifier; Logical operation item: defines the set operation of the intermediate results, limits the use of three types of operators: exclusion, intersection, and merging, and specifies the target data and operation rules of the operation; The logic execution unit is used to sequentially execute the JSON operation chain, specifically including: Identify the entity_set field in the query operation item, obtain a single entity or a collection, call a predefined Cypher template library through the Bolt protocol of Neo4j, execute a single query or a loop query operation and temporarily store the result in an intermediate storage area; Calling the predefined operator dictionary to chain the intermediate results includes: Exclusion operation: remove the intersection elements with the exclusion set from the source set; Intersection operation: extract common elements of multiple sets; Merge operation: remove duplicates and combine results from multiple sources; The chain-processed results are persistently stored through the final key name in the intermediate storage area as the final candidate drug set, and are associated with the input interface of the two-way verification and auxiliary decision-making module.

7. The system according to claim 1, characterized in that The case retrieval module specifically includes: The ClinicalBERT model is used to vectorize the target entity output by the entity extraction and alignment module to generate a multi-dimensional symptom vector with the same dimension as the symptom_embedding field of the case processing unit to ensure the consistency of the vector space structure; Taking the symptom vector as the query vector, a two-stage approximate nearest neighbor search is adopted, which includes: Coarse quantization partition stage: divide the vector space into The candidate partitions are determined by calculating the Euclidean distance between the query vector and each cluster center. The distance formula is: Fine search and sorting stage: in the candidate partition, the Euclidean distance between the query vector and each case vector is calculated, and the distance values ​​are arranged in ascending order to screen out the Top-K candidate cases, where the value of K is an integer from 2 to 5; The Euclidean distance formula in the fine search stage is: in, is the query vector, is the vector dimension, Represents the query vector The i-th component of Represents the i-th cluster center vector The i-th component of ; Represents the candidate case vector The i-th component of ; and They are The Euclidean distance between the cluster center and the case vector reflects their similarity in the vector space; Based on a pre-built prompt word template, which includes the original symptom text of the candidate case, the doctor's answer and the current medical description text, the third language model is called to perform contextual semantic fusion analysis, generate an associated drug set, and store the symptom entity corresponding to each drug entity in the set.

8. The system according to claim 1, characterized in that The bidirectional verification and auxiliary decision-making module specifically includes an external knowledge interface unit, a bidirectional verification unit and a fusion decision-making unit; The external knowledge interface unit is used to call the external medical knowledge base API to perform three data acquisition operations: Based on the symptom entities obtained by the entity extraction and alignment module, obtain their full medical aliases to form an extended symptom set; Based on the drug entities in the candidate drug set obtained by the graph retrieval module, obtain the indication set and contraindication set corresponding to each drug; Based on the drug entities in the associated drug set obtained by the case retrieval module, obtaining the indication set corresponding to each drug; The bidirectional verification unit is used to perform drug safety screening operations, specifically including: Screening drug entities that meet the following two conditions from the candidate drug set: The intersection of the contraindication set corresponding to the drug entity and the extended symptom set is empty; The intersection of the indication set corresponding to the drug entity and the extended symptom set is not empty; Drug entities that meet the above two conditions are grouped into a safe candidate drug set; The fusion decision unit is used to perform uncovered symptom completion and extended drug labeling operations, specifically including: Based on the union of drug indications in the safe candidate drug set, determining that the symptom set in the medical description text can be covered; Performing a difference operation on the symptom set in the covered medical description text and the total symptom set in the medical description text to obtain an uncovered symptom set; For each drug entity in the associated drug set, if its indication set has an intersection with the uncovered symptom set, the drug entity is marked as an extended drug to obtain an extended drug set; The safe candidate drug set and the expanded drug set are combined to form a final recommended drug set.

9. An electronic device, characterized in that: include: Processor, memory and communication bus; The memory stores a computer-readable program, and when the computer-readable program is executed by the processor, it is used to implement the medication assistance system based on symptom-drug bidirectional verification according to any one of claims 1 to 8; The communication bus is used for data transmission between the processor and the memory.

Images