A medication assistance system and device based on symptom-drug bidirectional verification

Abstract

The present invention discloses a medication assistance system and device based on symptom-drug bidirectional verification, which belongs to the field of smart medical technology. The system includes data preprocessing, entity extraction and alignment, graph retrieval, case retrieval, and bidirectional verification and decision-making assistance modules. The system extracts medical entities through an AC automaton rule engine and a knowledge-enhanced BERT model, and adopts a two-stage term alignment strategy to achieve entity mapping with the knowledge graph; a prompt word-driven operation chain generation mechanism is used to query the knowledge graph to obtain a set of candidate drugs; at the same time, similar cases are retrieved based on vector similarity to generate a set of associated drugs; finally, external medical knowledge base data is integrated, a bidirectional verification and completion strategy is executed, and medication recommendations with clinical safety and coverage are output. The present invention also provides a device structure for realizing the functions of the above system, which effectively improves the accuracy and interpretability of clinical medication assistance decision-making.

Description

Technical Field

[0001] The present invention belongs to the field of smart medical care, and specifically relates to a medication assistance system and device based on symptom-drug bidirectional verification. Background Art

[0002] Current mainstream medical semantic parsing mechanisms, primarily based on rule matching or single machine learning models (such as traditional BERT), face multiple challenges in real-world medical scenarios. For example, limited semantic understanding can easily lead to misjudgment of latent symptoms. Existing knowledge bases are often static, making it difficult to integrate multi-source medical data and resulting in information fragmentation. More importantly, the lack of effective risk control mechanisms can lead to system recommendations that suggest medication contraindications, directly impacting clinical safety. These critical issues severely impact the system's clinical application value.

[0003] Furthermore, while knowledge graphs excel at structured reasoning and large language models (such as ChatGPT) excel at semantic understanding, combining the two still faces key technical hurdles. For one thing, traditional one-way search mechanisms (such as inferring medications solely from symptoms) lack back-verification with case data, potentially leading to incomplete recommendations. Furthermore, the triple structure of knowledge graphs differs from the vector representation of case text, easily leading to information conflicts and contradictory output. Summary of the Invention

[0004] The technical problem to be solved by the present invention is that the existing medical information analysis system has the problems of inaccurate semantic understanding, weak knowledge fusion ability and insufficient safety verification when making decisions. In order to solve the above problems, the present invention provides a medication assistance system and device based on symptom-drug bidirectional verification.

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

[0006] In a first aspect, an embodiment of the present invention provides a medication assistance system based on symptom-drug bidirectional verification.

[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 decision support module.

[0008] Data preprocessing module: used to preprocess the medical knowledge graph, clean the medical question and answer dataset, generate symptom vectors, and establish structured case storage in the vector database.

[0009] Entity extraction and alignment module: used to combine the rule engine and the knowledge-enhanced BERT model to extract symptom entities from medical description text or clinical expression fragments, and align them with the entities in the knowledge graph to obtain the target entity.

[0010] 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 set of candidate drugs by executing the knowledge graph query instructions and logical set operations in the operation chain.

[0011] Case retrieval module: used to vectorize the target entity, match similar cases in the vector database based on the target vector, and generate a set of associated drugs.

[0012] Bidirectional verification and decision-making support module: Based on external medical knowledge base data, it dynamically integrates the candidate drug set and the related drug set, and realizes multi-source fusion decision-making through bidirectional verification 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-symptoms, drug-indications, and drug-contraindications from open source structured medical data sources to 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 analysis on the open source medical conversation dataset, and extract the original symptom text, symptom entity and corresponding doctor's advice of each case.

[0017] The ClinicalBERT model is used to embed the symptom entities and generate multi-dimensional symptom vectors for similarity matching in the case retrieval module.

[0018] A structured case collection is constructed in the vector database. Each case entry contains five core fields: case ID (case_id), symptom entity (symptom_entity), symptom vector (symptom_embedding), doctor's answer text (answer), and raw 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 AC automaton. It uses the pre-built medical knowledge graph entity library to perform string precise matching on medical description texts or clinical expression fragments, extract explicit entities and directly retain the results.

[0021] The model enhancement layer processes the input text through a dual-channel embedding fusion BERT model (DCEF-BERT), where the dual channels include 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 graph neural networks to generate structured knowledge embeddings.

[0023] The context embedding channel retains the original word vector and position encoding of the BERT model and captures the contextual semantics of the input text.

[0024] The stage alignment unit is used to implement multi-level semantic alignment for implicit entities that are not exactly matched, use semantic similarity calculation to screen and input them into the first language model for optimal selection to ensure the 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] Design a dual-channel input structure: knowledge graph embedding channel and context embedding channel.

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

[0028] The contextual embedding channel retains BERT's original word embedding, segment embedding, and position encoding, capturing the local semantics and global dependencies of the input text.

[0029] A dynamic fusion gating mechanism is designed to perform weighted fusion of dual-channel embeddings through a learnable parameter matrix and activation function, which can be specifically expressed as:

[0030] ;

[0031] .

[0032] 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. Contextual embedding is a combination of the original word vector, position encoding, and segment vector generated by the BERT model when processing the input text.

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

[0034] Paired user symptom descriptions and standardized entity labels are collected from open source medical text datasets (such as CMCQA) to construct unstructured training samples.

[0035] Based on the training sample, the underlying parameters of the BERT base model are frozen, and only the parameters of the dual-channel embedding layer, dynamic gating layer, and top-level Transformer block are updated. Fine-tuning is performed using a joint loss function, which is defined as:

[0036] .

[0037] 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 the knowledge graph to the entities in the training data.

[0038] When the coverage is higher than the first threshold, Take the preset value 1, preferably 0.6; when the coverage rate is lower than the second threshold, Take the preset value three, preferably 0.4; when the coverage is between the first threshold and the second threshold, Take the preset value 2, preferably 0.5.

[0039] 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.

[0040] Furthermore, the phase alignment unit specifically includes the following contents.

[0041] The explicit entities output by the rule-driven layer are retained as the aligned results.

[0042] For the implicit entities output by the model enhancement layer, the cosine similarity between each implicit entity and the knowledge graph node is calculated to 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 between the preset entity coverage threshold and the computing resource constraints) candidate entity list.

[0043] 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 that is 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.

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

[0045] The operation chain generation unit calls the second largest 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.

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

[0047] Query operation item: defines the knowledge graph query instruction, including entity name, relationship type (possible disease / recommended medication / contraindication / indication) and intermediate result storage identifier, such as {"type": "query", "entity_set": "Diabetes", "relation": "Contraindication", "store_as": "A"}.

[0048] Logical operation item: defines the set operation for the intermediate results, limiting the use of the exclude, intersect, and merge operators, and specifying the target data and operation rules of the operation, such as {"type": "operation", "name": "exclude", "sources": ["C"], "exclude": ["A","B"]}, where A and B are the key names of the intermediate results.

[0049] The logic execution unit is used to sequentially execute the JSON operation chain, specifically including the following contents.

[0050] 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 Neo4j Bolt protocol, execute a single query or a loop query operation, and temporarily store the results in an intermediate storage area.

[0051] Calling a predefined operator dictionary (e.g., exclude: set(A).difference(B)) to chain the intermediate results, specifically including:

[0052] Exclusion operation: remove the intersection elements with the exclusion set from the source set;

[0053] Intersection operation: extract common elements of multiple sets;

[0054] Merge operation: De-duplicate and combine results from multiple sources.

[0055] The result after the chain processing is persistently stored through the final key name (such as "result") in the intermediate storage area as the final candidate drug set, and is associated with the input interface of the two-way verification and auxiliary decision module.

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

[0057] The ClinicalBERT model is used to vectorize the target entities 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 consistency in the vector space structure.

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

[0059] Coarse quantization partitioning stage: Divide the vector space into Cluster centers are calculated, and candidate partitions are determined by calculating the Euclidean distance between the query vector and each cluster center. The distance formula is:

[0060] .

[0061] Fine search and sorting stage: within the candidate partition, the Euclidean distance between the query vector and each case vector is calculated, and the distance values are sorted in ascending order to screen out the Top-K candidate cases, where K is an integer from 2 to 5.

[0062] The Euclidean distance formula in the fine search stage is:

[0063] .

[0064] 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.

[0065] 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.

[0066] Optionally, the bidirectional verification and auxiliary decision module specifically includes an external knowledge interface unit, a bidirectional verification unit and a fusion decision unit.

[0067] The external knowledge interface unit is used to call the external medical knowledge base API (interface) to perform three data acquisition operations:

[0068] Based on the symptom entities obtained by the entity extraction and alignment module, obtain their full medical aliases to form an extended symptom set (extended_symptom_set);

[0069] Based on the drug entities in the candidate drug set obtained by the graph retrieval module, obtaining the corresponding indication set and contraindication set for each drug;

[0070] Based on the drug entities in the associated drug set obtained by the case retrieval module, the indication set corresponding to each drug is obtained.

[0071] The bidirectional verification unit is used to perform drug safety screening operations.

[0072] Screen the candidate drug pool for drug entities that meet the following two conditions:

[0073] The intersection of the contraindication set corresponding to the drug entity and the extended symptom set (extended_symptom_set) is empty;

[0074] The intersection of the indication set corresponding to the drug entity and the extended symptom set (extended_symptom_set) is not empty.

[0075] The drug entities that meet the above two conditions are combined into a safe candidate drug set (safe_candidate_drug_set).

[0076] The fusion decision unit is used to perform uncovered symptom completion and extended drug labeling operations.

[0077] Based on the union of drug indications in the safe candidate drug set (safe_candidate_drug_set), a symptom set in the medical description text that can be covered by the safe candidate drug set (safe_candidate_drug_set) is determined.

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

[0079] For each drug entity in the associated drug set, if its indication set intersects with the uncovered symptom set, the drug entity is marked as an extended drug to obtain an extended drug set (extended_drug_set).

[0080] The safe candidate drug set (safe_candidate_drug_set) and the extended drug set (extended_drug_set) constitute a final recommended drug set (final_recommendation_set).

[0081] A second aspect of the present invention provides an electronic device for implementing a medication assistance system based on symptom-drug bidirectional verification. The device includes a processor, a memory, and a communication bus. The memory is a computer-readable storage medium storing program code executable by the processor; the communication bus connects the processor and the memory to enable data exchange and communication.

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

[0083] The beneficial effect of this invention is that it significantly enhances the semantic understanding and knowledge integration capabilities of medical information parsing systems. By combining the topological features of knowledge graphs with the contextual semantics of text, the dual-channel embedding fusion BERT model (DCEF-BERT) effectively addresses the inadequate recognition of latent symptoms and complex terminology by traditional single models. It employs multi-level semantic screening and optimal selection from a large language model to precisely align long-tail symptoms and diverse representations, combining the structured reasoning advantages of knowledge graphs with the empirical judgment of clinicians. BRIEF DESCRIPTION OF THE DRAWINGS

[0084] Figure 1 This is a medication assistance system based on symptom-drug bidirectional verification provided by an embodiment of the present invention;

[0085] Figure 2 This is a flow chart of a medication assistance system based on symptom-drug bidirectional verification provided by an embodiment of the present invention;

[0086] Figure 3 2 is a schematic diagram of the structure of the DCEF-BERT provided by an embodiment of the present invention;

[0087] Figure 4 This is a flow chart of bidirectional verification and auxiliary decision-making provided by an embodiment of the present invention;

[0088] Figure 5 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0089] In the embodiments of the present application, the term "plurality" refers to two or more, and other quantifiers are similar thereto. The terms "first", "second", etc. in the specification and claims of the present application are used to distinguish similar objects, and are not used to describe a specific order or precedence. It should be understood that the terms used in this way are interchangeable where appropriate, 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 generally of the same type, and do not limit the number of objects. For example, the first object can be one or more.

[0090] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making any creative efforts shall fall within the scope of protection of the present invention.

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

[0092] The embodiment of the present application provides a medication assistance system and device based on symptom-drug bidirectional verification, which aims to solve the technical problems of inaccurate semantic understanding, weak knowledge fusion ability and insufficient medication safety verification in the existing medical semantic analysis mechanism when making medication decisions.

[0093] See Figure 1 , Figure 1 The invention provides a medication assistance system based on symptom-drug bidirectional verification, which specifically includes: a data preprocessing module, an entity extraction and alignment module, a graph retrieval module, a case retrieval module and a bidirectional verification and decision support module.

[0094] The data preprocessing module is used to preprocess the medical knowledge graph, clean the medical question and answer dataset, generate symptom vectors, and establish structured case storage in the vector database.

[0095] The entity extraction and alignment module is 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.

[0096] The graph retrieval module is 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 set of candidate drugs by executing the knowledge graph query instructions and logical set operations in the operation chain.

[0097] The case retrieval module is used to vectorize the target entity, match similar cases in the vector database based on the target vector, and generate a set of associated drugs.

[0098] The two-way verification and decision-making support module dynamically integrates the candidate drug set and the related drug set based on external medical knowledge base data, and realizes multi-source fusion decision-making through two-way verification screening.

[0099] It's important to clarify that a Large Language Model (LLM) refers to a deep learning system trained on massive amounts of text data, capable of generating natural language text or understanding semantic information. Its architecture can be flexibly configured based on specific application scenarios and is not limited here. In this solution, the first through third language models described all fall under the LLM category. However, due to their different functional tasks, their model architectures will be adjusted accordingly. The specific implementation requires customized training and optimization based on actual business needs and is not limited here.

[0100] It should be understood that an external medical knowledge base interface (Application Programming Interface, or API) refers to an application programming interface (API) that interacts with specialized pharmaceutical databases through standardized protocols, enabling real-time querying of medical knowledge and data access. Its specific interface methods and functional modules can be flexibly configured based on actual business needs and are not specified here. However, due to differences in the knowledge base sources and data formats used by each interface, the request parameters, response structure, and data processing logic will be adjusted accordingly. The specific implementation requires customized development and optimization based on medical business scenarios and is not specified here.

[0101] like Figure 2 As shown, Figure 2 This is a flowchart of a medication assistance system based on symptom-drug bidirectional verification, provided by an embodiment of the present invention. The data preprocessing module, as the fundamental support component of the system, is primarily used to construct a high-quality medical knowledge graph and establish a structured case database. This module comprises a graph construction unit and a case processing unit.

[0102] Among them, the graph construction unit extracts three core relationships: disease-symptoms, drug-indications, and drug-contraindications from open source structured medical data sources, and constructs a medical knowledge graph in the form of "entity-relationship-entity" triples, which is stored in the Neo4j graph database to achieve structured organization oriented to graph queries.

[0103] For example, in the specific implementation, the open source medical knowledge graph (MedicalKG) is used, and relationship extraction and filtering are performed on it by writing automated scripts, and the domain adaptability optimization of the knowledge graph is achieved by using preset relationship constraints.

[0104] The case processing unit focuses on screening and structured parsing of medical conversation datasets (such as CMCQA). This involves extracting the original symptom text, explicit and implicit symptom entities, and corresponding physician recommendations from each conversation. This implementation uses the ClinicalBERT model to embed these extracted symptom entities into vectors, generating a high-dimensional symptom representation (symptom_embedding). This representation, along with fields such as the case ID, physician response, and original text, forms a structured case entry, which is then stored in a unified vector database.

[0105] For example, in a 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, it not only significantly reduces the cost of manual annotation, but also ensures the accuracy of semantic parsing.

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

[0107] Specifically, the rule-driven layer relies on a pre-built medical knowledge graph entity dictionary and uses the AC automaton (Aho-Corasick Automaton) as the core multi-mode string matching algorithm to efficiently retrieve explicit medical entities in clinical expression fragments. Furthermore, the system first constructs all entities in the entity dictionary into a Trie tree and generates corresponding failure pointers during the construction process, thereby forming an automaton structure with state transfer function. During 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 length of the text, which greatly improves the processing efficiency of entity extraction. This method is particularly suitable for fast query scenarios under large-scale entity dictionaries.

[0108] Specifically, such as Figure 3As shown in the figure, the model enhancement layer is based on the Dual-Channel Embedding Fusion BERT (DCEF-BERT) model, which aims to comprehensively utilize the structural information of the knowledge graph and the contextual semantics of natural language text to achieve deep semantic and accurate extraction of implicit medical entities. The model designs a parallel knowledge graph embedding channel and a context embedding channel. The knowledge graph embedding channel uses a 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 a structured semantic embedding. The context embedding channel uses the word vector, segment vector, and position encoding mechanism of the original BERT model to capture the contextual dependencies and semantic details of entity representations in the medical description text input.

[0109] To achieve the organic fusion of two-channel information, DCEF-BERT introduces a dynamic fusion gating mechanism. This mechanism dynamically calculates the fusion weight according to the input context through a learnable parameter matrix and a nonlinear activation function. , achieving a weighted combination of knowledge embedding and context embedding. This structure not only retains the reasoning advantage of graph relationships, but also enhances the ability to express complex language phenomena such as implicit symptoms and ambiguous expressions. The fusion formula is as follows:

[0110] ;

[0111] .

[0112] 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. Contextual embedding is a combination of the original word vector, position encoding, and segment vector generated by the BERT model when processing the input text.

[0113] Optionally, in some specific embodiments, during the training data construction process, a large language model (such as ChatGPT) is first used to perform preliminary entity extraction on open medical text (such as the CMCQA dialogue dataset) to generate candidate pairs of medical descriptions and potential standard entities. This is then followed by secondary validation and manual labeling to ensure that the data covers complex semantics and synonymous variants, providing the model with training samples in real clinical contexts.

[0114] To improve the generalization and accuracy of the DCEF-BERT model in medical entity extraction tasks, a joint loss-based fine-tuning strategy was designed during model training. DCEF-BERT freezes the underlying parameters of the base BERT model and only optimizes the parameters of the dual-channel embedding layer, the gated fusion layer, and the top Transformer encoding layer. The training objective is constrained and optimized using a joint loss function, defined as follows:

[0115] .

[0116] 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 contextual semantics is used to enhance the model's understanding of language expression; the weight coefficient Based on the dynamic setting of knowledge graph coverage, when entity coverage is high, the weight of structural guidance is increased (for example, a value of 0.6), while when it is low, the weight is shifted towards language semantics (for example, a value of 0.4), thus achieving 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.

[0117] To further improve the matching accuracy between implicit entities and the knowledge graph, a staged alignment unit was designed to perform semantic comparison and entity confirmation based on the output of the model enhancement layer. Entities accurately matched by the rule-driven layer are retained as aligned results, while the remaining implicit entities that were not matched enter the semantic alignment process.

[0118] Specifically, the system constructs a vector representation of each implicit entity relative to the entity nodes in the graph and generates a list of top-K candidate entities through cosine similarity calculations. The optimal K value is generally set to 3 to 5, depending on 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 as prompt word templates, along with the implicit entity to be matched and its corresponding candidate entity list. The final output is the entity that most closely matches the contextual semantics and conforms to the semantic consistency of the graph as the target alignment result.

[0119] In this embodiment of the present invention, the graph retrieval module is used to implement structured semantics-based drug reasoning queries. Its core goal is to efficiently filter out a set of candidate drugs related to the input symptoms from the knowledge graph. This module mainly includes two submodules: the operation chain generation unit and the logic execution unit.

[0120] First, the operation chain generation unit receives the aligned target entity and uses a large language model to perform semantic analysis on the medical description text or clinical expression fragment. Combining predefined prompt word templates with graph relationship types (such as "possible disease," "recommended medication," "contraindicated medication," and "indications"), 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 a specific knowledge graph entity and relationship, ensuring logical transparency of the operation process.

[0121] Preferably, in a specific implementation, the structured prompt word template includes four key components: identity indication, operation instruction, reasoning example, and target construction task. This prompt word structure allows the large language model to clearly define the task instructions, constrain its output format, and facilitate subsequent extraction.

[0122] In the graph search module, the logic execution unit executes all query 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 performs the graph search based on the Cypher template.

[0123] Specifically, before executing the query, the system first determines whether the entity referred to in the field is a single entity or an entity collection:

[0124] If it is a single entity, the system directly performs query operations on the entity, for example:

[0125] {"type": "query", "entity_set": "Antipyretics", "relation": "Indications", "store_as": "C"};

[0126] Indicates that the "Indications" relationship query is performed on the single entity "Antipyretics";

[0127] If it is an entity set, each element in the set is parsed in a loop, the same graph query instruction is executed in sequence, and all results are merged into the intermediate storage area, for example:

[0128] {"type": "query", "entity_set": "A", "relation": "Indications", "store_as": "D"};

[0129] This 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 the results in a variable with the key "D." This mechanism ensures high flexibility and scalability in the graph retrieval process, and is suitable for both simple entity path reasoning and complex multi-entity joint query scenarios.

[0130] Logical operations perform set operations between candidate sets based on a predefined operator dictionary, supporting three basic operations: intersection, exclude, and merge. For example, the system can first query all "recommended medications" and then exclude entities related to "contraindicated medications" to obtain a set of candidate medications that meet medication safety rules.

[0131] Specifically, the system defines an operator dictionary (OPERATIONS) to uniformly handle set operations. This dictionary maps each set operation to a specific execution function, automatically calling the appropriate operation method and merging the results. It mainly supports three basic operations:

[0132] exclude: used to remove one or more elements in the exclusion set from the source set. Its implementation form is:

[0133]

[0134] That is, taking the difference of the source set, which is often used to exclude contraindicated drugs from candidate drugs;

[0135] intersect (intersection): used to obtain the common elements of two sets, and its implementation form is:

[0136]

[0137] It can be used to filter out entities that meet multiple relationship conditions at the same time;

[0138] merge: It is used to combine multiple sets to form a union. It is implemented as follows:

[0139]

[0140] Suitable for aggregating the results of multiple query paths into a unified candidate list;

[0141] When the system executes each set operation, it automatically reads the corresponding key name entity set from the intermediate storage area, performs the set operation according to the operation type, and writes the result back to the new identification variable.

[0142] In this embodiment of the present invention, the case retrieval module aims to match highly relevant historical cases within a structured case database based on target symptom entities through similarity calculation. First, the system vectorizes the aligned symptom entities using the ClinicalBERT model, generating an embedding representation with the same dimensions as the symptom vector (symptom_embedding) field in the vector database. To ensure computational efficiency and matching results, the module employs a two-stage approximate nearest neighbor retrieval strategy, first performing coarse quantization and partitioning, followed by refined search and sorting.

[0143] Specifically, in the coarse quantization partitioning stage, the vector space is pre-divided into Cluster centers are used to quickly locate candidate partitions by calculating the Euclidean distance between the query vector and each cluster center during retrieval. The distance formula is:

[0144] .

[0145] In the refined search and sorting phase, only within the candidate partitions, each case vector is sorted by Euclidean distance from the query vector, and the top-K most similar cases are selected (usually K is 2 to 5). The example formula is as follows:

[0146] .

[0147] in, is the symptom query vector, is the candidate case vector, The vector dimension is 768. The matched Top-K cases are input together with their original symptom text and doctor's advice as context. The large language model is called for semantic fusion analysis to further infer the drug set that matches the current medical description text or clinical expression fragment.

[0148] In this embodiment of the present invention, the bidirectional verification and decision-making support module serves as the final decision-making link in the system. It is primarily responsible for cross-validating graph inference results and case matching results, completing drug screening based on external medical knowledge, and forming final medication recommendations with clinical guidance significance. This module comprises three core units: an external knowledge interface unit, a bidirectional verification unit, and a fusion decision-making unit.

[0149] See also Figure 4In the specific implementation, the external knowledge interface unit is mainly used to call the external medical knowledge base API to achieve three types of information acquisition: extracting and aligning symptom entities based on medical description texts or clinical expression fragments, retrieving all their medical aliases, and building an extended symptom set (extended_symptom_set); obtaining the indications and contraindications set of each drug based on the candidate drug set output by the graph retrieval module; and extracting the indication set based on the associated drug set obtained by the case retrieval module.

[0150] In the two-way verification and decision support module, the two-way verification unit is responsible for identifying "safe candidate drugs" with clinical suitability in the cross-comparison of multi-source data. The specific screening logic is as follows: the system first determines whether there is an intersection between the "contraindication set" and the "extended symptom set" for each drug in the candidate drug 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 the "extended symptom set". If there is no intersection, it is considered that the drug lacks clear applicability and is also eliminated. In specific implementation, since the length 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 "empty intersection of contraindications and non-empty intersection of indications" will it be retained as a safe candidate drug set (safe_candidate_drug_set).

[0151] Its specific logic can be described as:

[0152] for each drug in candidate_drug_set do

[0153] if (contraindications(drug) ∩ extended_symptom_set = Ø) and

[0154] (indications(drug) ∩ extended_symptom_set ≠Ø) then

[0155] add drug to safe_candidate_drug_set

[0156] end if

[0157] end for.

[0158] After completing the initial safety screening, the fusion decision unit further integrates drug entities in the associated drug set to complete uncovered symptoms and label them as extended drugs. The system first calculates the union of all drug indications in the safe candidate drug set (safe_candidate_drug_set) and uses this to determine the symptom set currently covered by the medical description. Then, by performing a set difference calculation with the original symptom set in the medical description, it identifies symptoms that are not fully covered (uncovered_symptom_set). For these uncovered symptoms, the system iterates over each drug entity in the associated drug set. If its indication set intersects with the uncovered symptom set, it indicates that the drug has the potential to address the underrepresentation of the current drug recommendation. The drug is then labeled as an "extended drug" and included in the extended drug set (extended_drug_set). In other words, the system identifies drug entities in the associated drug set that are not fully covered by the medical description in the safe candidate drug set, thereby improving the comprehensiveness of the final recommendation results.

[0159] The above specific logic can be described as:

[0160] covered_symptoms ← union of indications in safe_candidate_drug_set

[0161] uncovered_symptom_set ← user_symptoms − covered_symptoms

[0162] for each drug in related_drug_set do

[0163] if indications(drug) ∩ uncovered_symptom_set ≠Ø then

[0164] add drug to extended_drug_set

[0165] end if

[0166] end for.

[0167] Finally, the system merges the safe candidate drug set (safe_candidate_drug_set) with the extended drug set (extended_drug_set) as the final recommended drug set (final_recommendation_set), namely:

[0168] final_recommendation_set ← safe_candidate_drug_set ∪ extended_drug_set.

[0169] See Figure 5 The electronic device includes a processor, a memory, and a communication bus. The memory stores a computer program executable by the processor, which is used to implement all steps of the aforementioned medication assistance system. The communication bus is used to achieve data connection and coordinated operation within the device.

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

[0171] It is important to note that this application does not directly guide, determine, or replace physicians' diagnostic and treatment practices, nor does it provide specific medication recommendations for individuals. The final medication selection should be made by a qualified physician based on the patient's physical signs, medical history, and other medical test data.

[0172] The foregoing description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Those skilled in the art will readily appreciate that various modifications and variations of the present invention are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention are intended to be within the scope of protection 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 dataset, generate symptom vectors, and establish structured case data to store in the vector database; Entity extraction and alignment module: This module is used to combine the rule engine and the knowledge-enhanced BERT model to extract symptom entities from medical description text or clinical expression fragments, and align them with the entities in the knowledge graph to obtain the target entity. The knowledge-enhanced BERT model is a DCEF-BERT model, which 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, generating topological feature embeddings that include disease-symptom hierarchy and drug-indication associations; The contextual 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 a learnable parameter matrix and activation function, 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 using a graph attention network. Contextual embedding is a combination of the original word vector, positional 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 paired user symptom descriptions and standardized entity labels from open source medical text datasets to construct unstructured training samples; Based on the training sample, the underlying parameters of the BERT base model are frozen, and only the parameters of the dual-channel embedding layer, dynamic gating layer, and top-level Transformer block are updated. Fine-tuning is performed 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 by the coverage of the knowledge graph to the entities in the training data: when the coverage is higher than the first threshold, Take the preset value 1; when the coverage 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 fed into the BERT Transformer encoding layer. The multi-head self-attention mechanism captures the interactive features with potential correlations between different channels, improving the recognition of long-tail symptoms and multiple expression ambiguities. Based on the above structure and training method, the knowledge-enhanced BERT model can effectively support the extraction and alignment of symptom entities in medical description texts or clinical expression fragments in the entity extraction and alignment module; 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 set of candidate drugs by executing the knowledge graph query instructions and logical set operations in the operation chain; Case retrieval module: used to vectorize the target entity, match similar cases in the vector database based on the target vector, and generate a set of associated drugs; Bidirectional verification and decision-making support module: Based on external medical knowledge base data, it dynamically integrates the candidate drug set and the related drug set, and realizes multi-source fusion decision-making through bidirectional verification screening.

2. The system according to claim 1, wherein: 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 dataset, extracting the original symptom text, symptom entity and corresponding doctor's advice of each case; The ClinicalBERT model is used to embed the symptom entities and generate multi-dimensional symptom vectors 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, wherein: 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 AC automaton rule engine. It uses the pre-built medical knowledge graph entity library to perform string precise matching on medical description texts 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 relationships and hierarchical paths of entity nodes in the knowledge graph through graph neural networks to generate structured knowledge embeddings; The context embedding channel retains the original word vectors and positional encodings of the BERT model, capturing 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, use semantic similarity calculation to screen and input them 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 phase alignment unit specifically includes: The explicit entities output by the rule-driven layer are retained as aligned results; For the implicit entities output by the model enhancement layer, the cosine similarity between each implicit 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 that is 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.

5. The system according to claim 1, wherein: 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 on the intermediate results, limits the use of three types of operators: exclusion, intersection, and merge, 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 Neo4j Bolt protocol, execute a single query or a loop query operation, and temporarily store the results in an intermediate storage area; Calling the predefined operator dictionary to perform chain processing on the intermediate results, specifically including: Exclusion operation: remove the intersection elements with the exclusion set from the source set; Intersection operation: extract common elements of multiple sets; Merge operation: de-duplicate and combine the results from multiple sources; The chain-processed results are persistently stored using 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 decision-making support module.

6. The system according to claim 1, wherein: The case retrieval module specifically includes: The ClinicalBERT model is used to vectorize the target entities 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 used, which includes: Coarse quantization partitioning stage: Divide the vector space into Cluster centers are calculated, and candidate partitions are determined by calculating the Euclidean distance between the query vector and each cluster center. The distance formula is: ； Refined search and sorting phase: within the candidate partition, the Euclidean distance between the query vector and each case vector is calculated, and the distance values are sorted in ascending order to screen out the top-K candidate cases, where 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.

7. The system according to claim 1, wherein: The bidirectional verification and auxiliary decision module specifically includes an external knowledge interface unit, a bidirectional verification unit and a fusion decision 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, obtaining the corresponding indication set and contraindication set for 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: Screen the candidate drug pool for drug entities that meet the following two conditions: 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: Determining, based on a union of drug indications in the safe candidate drug set, that the union can cover a symptom set in the medical description text; 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 and uncovered symptom set have an intersection, 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 constitute a final recommended drug set.

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

Images