Medical clinical assistance system based on multiple hypothesis validation

Abstract

The application relates to a medical clinical auxiliary system based on multiple hypothesis verification, which fuses a clinical diagnosis thinking chain and a theoretical diagnosis thinking chain to perform multiple hypothesis verification, generates an optimized examination list, and outputs a structured report, can effectively identify critical and severe diseases with low probability and high mortality, simulates a clinical thinking chain to perform rigorous diagnosis, reduces medical hallucinations, and thus improves the accuracy and safety of diagnosis.

Description

Technical Field

[0001] This application relates to the field of medical artificial intelligence technology, and in particular to a medical clinical assistance system based on multiple hypothesis verification. Background Technology

[0002] In clinical medical practice, the application of artificial intelligence technology has gradually penetrated into the field of diagnostic assistance to improve the efficiency of consultations for both doctors and patients. Existing assisted diagnostic systems mainly rely on large language models to process the natural language complaints input by users, and quickly generate preliminary diagnostic suggestions or reports through recognition models.

[0003] However, these systems generally suffer from significant limitations: their designs often focus on common and simple disease scenarios, making it difficult to effectively identify low-probability but high-fatality critical illnesses. For example, in cases of overlapping or atypical symptoms, the system is prone to overlooking potentially high-risk diseases due to biased training data. Furthermore, existing technologies cannot realistically simulate the clinical thought process doctors rely on during diagnosis—the logical process of gradually narrowing down the diagnostic scope through multi-step reasoning, differential diagnosis, and evidence verification. They cannot perform deterministic logical reasoning based on medical knowledge graphs, nor can they enforce constraints on the generation process to conform to clinical norms, thus failing to meet the safety and reliability requirements of complex medical scenarios.

[0004] In addition, the system often exhibits medical hallucinations during operation, outputting content that does not conform to medical facts or treatment guidelines, such as recommending unreasonable examinations or generating incorrect diagnostic conclusions. This may not only lead to unauthorized examinations and increase the financial burden on patients, but may also cause delays in treatment or even medical accidents. Summary of the Invention

[0005] This application provides a medical clinical assistance system based on multiple hypothesis testing, which can effectively identify critical illnesses with low probability and high mortality, simulate clinical thought chains for rigorous diagnosis, and reduce medical illusions, thereby helping to improve the accuracy and safety of diagnosis.

[0006] The first aspect of this application provides a medical clinical support system based on multiple hypothesis testing, comprising:

[0007] The clinical entity extraction module is used to receive the user's chief complaint data input in natural language and generate the user's clinical entities from the chief complaint data based on standard medical terminology encoding. The clinical diagnostic path construction module, which is connected to the clinical entity extraction module, is used to match and filter multiple candidate cases from the medical record database based on the clinical entities, and to construct a clinical diagnostic thought chain based on the multiple candidate cases. The theoretical diagnostic path construction module, which is connected to the clinical entity extraction module, is used to construct a theoretical diagnostic thinking chain based on the clinical entities and in combination with a preset medical knowledge graph. An examination planning module connected to the clinical diagnostic pathway construction module and the theoretical diagnostic pathway construction module is used to construct a fusion diagnostic thinking chain based on the clinical diagnostic thinking chain and the theoretical diagnostic thinking chain; to perform a preliminary diagnosis on the clinical entity using the fusion diagnostic thinking chain, and to calculate the information gain of the preliminary diagnostic results using a competitive hypothesis approach; and to generate an examination form based on the information gain and the preliminary diagnostic results, wherein the examination form contains multiple examination items. The report constraint generation module, connected to the inspection planning module, is used to obtain the inspection data corresponding to the inspection form, and to output an auxiliary report based on the inspection data and the preliminary diagnosis results using the base large language model.

[0008] In one possible implementation, the clinical entity extraction module includes: An interface unit, connected to the input module of the medical system, is used to receive the user's chief complaint data input in natural language, wherein the chief complaint data includes at least physical condition, symptoms, past medical history and medical records; An entity recognition unit, connected to the interface unit, is used to call a medical language model to perform word segmentation and medical named entity recognition on each piece of information in the chief complaint data, and to abstract symptom entities, sign entities, past medical history entities, and medication entities based on the recognition results. The encoding conversion unit, connected to the entity recognition unit, is used to perform context disambiguation processing on ambiguous entities in the symptom entity, the sign entity, the past history entity, and the medication entity based on a preset medical dictionary to obtain a standard entity set; and to map each entity in the standard entity set to a standard medical terminology encoding system to obtain clinical entities.

[0009] In one possible implementation, the clinical diagnostic pathway construction module includes: The clinical phenotype anchoring unit is used to construct a patient feature vector based on the clinical entity and to select Top-K candidate cases by calculating the cosine similarity between the patient feature vector and the pre-stored case prototype vector. The first differential diagnosis reasoning unit is used to statistically analyze the distribution of diagnostic results corresponding to the Top-K candidate cases, generate a candidate disease set, and construct a probabilistic clinical diagnostic thinking chain based on the candidate disease set.

[0010] In one possible implementation, the first differential diagnostic reasoning unit is specifically used for: The diagnostic logic and diagnostic features of each candidate case are extracted, and the disease probability distribution of each candidate case in the Top-K candidate cases is calculated based on the diagnostic features. Based on the diagnostic logic and diagnostic features, a corresponding clinical diagnostic thought chain is constructed, and each clinical diagnostic thought chain is assigned a priority according to the disease probability distribution.

[0011] In one possible implementation, the theoretical diagnostic path construction module includes: The query unit is used to use the clinical entity as a graph query node to filter candidate graphs in the medical knowledge graph database that contain at least two identical symptom entities, sign entities, past medical history entities, and medication entities. The differential diagnosis reasoning unit is used to perform reverse causal path traversal based on the candidate atlas along the relationship between symptoms, diseases, and examinations, extract disease nodes and examination nodes related to the clinical entity, and construct a differential diagnosis subgraph containing multiple competing diseases.

[0012] In one possible implementation, the inspection planning module includes: The fusion unit is used to perform consistency analysis between the clinical diagnostic thinking chain and the theoretical diagnostic thinking chain, and to construct a fusion diagnostic thinking chain based on the analysis results. The pre-diagnosis unit is used to diagnose the clinical entity based on the fusion diagnostic thinking chain to obtain a diagnostic space; The gain unit is used to calculate the uncertainty entropy value of each disease option in the diagnostic space; and to calculate the expected information gain of each candidate examination item by simulating the diagnostic changes under different examination results based on the uncertainty entropy value through multiple hypothesis verification. The indicator planning unit is used to select the inspection items with the greatest information gain to generate an inspection list.

[0013] In one possible implementation, the gain unit is specifically used for: Extract local sub-graphs of Top-K diseases in the diagnostic space; Enumerate candidate examination items in the local subgraph and simulate the distribution of diagnosis under different results for each candidate examination through multiple hypothesis testing. The expected information gain for each candidate examination is calculated based on the diagnostic distribution.

[0014] In one possible implementation, the gain unit is specifically used for: Calculate the Shannon entropy of each candidate examination item under the corresponding diagnostic distribution; Predict the probability of occurrence of candidate examination items under different outcomes, and calculate the updated diagnostic entropy under different outcomes; The difference between the Shannon entropy and the diagnostic entropy is calculated, and the information gain of the corresponding candidate examination item is determined by comparing it with the preset expected entropy.

[0015] In one possible implementation, the inspection planning module further includes a diagnostic closed-loop update unit, specifically used for: Obtain the inspection results returned by the external inspection system, wherein the inspection results are the inspection data corresponding to the inspection form; Based on the examination results, the likelihood of each disease option in the diagnostic space is calculated, and the occurrence probability of each disease option is updated using Bayes' theorem. Determine whether the disease option with the highest probability of occurrence among all disease options exceeds a preset threshold; otherwise, continue to plan and calculate the information gain of each examination item.

[0016] In one possible implementation, the report constraint generation module includes: The data fusion unit is used to receive the examination data, the preliminary diagnosis results, and the diagnostic path information in the fusion diagnostic thinking chain, and to perform structured fusion to generate unified diagnostic context data. An evidence chain construction unit, connected to the data fusion unit, is used to extract positive causal paths supporting the target disease from the fusion diagnostic thinking chain, and to screen key evidence nodes based on the examination data to construct a positive evidence chain. The exclusion chain construction unit, connected to the evidence chain construction unit, is used to identify candidate diseases competing with the target disease based on the examination data, extract the falsified causal paths, and construct a reverse exclusion evidence chain. The report generation unit, connected to the evidence chain construction unit and the exclusion chain construction unit, is used to call the base large language model to generate a structured auxiliary diagnostic report based on the positive evidence chain and the reverse exclusion evidence chain.

[0017] The technical solution provided in this application may include the following beneficial effects: This application provides a medical clinical assistance system based on multiple hypothesis testing. The system includes: a clinical entity extraction module, used to receive chief complaint data input by a user via natural language, and generate the user's clinical entities from the chief complaint data based on standard medical terminology encoding; a clinical diagnostic path construction module connected to the clinical entity extraction module, used to match and filter multiple candidate cases from a medical record database based on the clinical entities, and construct a clinical diagnostic thought chain based on the multiple candidate cases; and a theoretical diagnostic path construction module connected to the clinical entity extraction module, used to construct a theoretical diagnostic thought chain based on the clinical entities and a preset medical knowledge graph; and a system connected to the clinical entity extraction module. The examination planning module, connected to the clinical diagnostic pathway construction module and the theoretical diagnostic pathway construction module, is used to construct a fusion diagnostic thinking chain based on the clinical diagnostic thinking chain and the theoretical diagnostic thinking chain; to perform a preliminary diagnosis on the clinical entity using the fusion diagnostic thinking chain, and to calculate the information gain of the preliminary diagnostic results using a competitive hypothesis approach; to generate an examination form based on the information gain and the preliminary diagnostic results, wherein the examination form contains multiple examination items; and a report constraint generation module, connected to the examination planning module, is used to obtain the examination data corresponding to the examination form, and to output an auxiliary report based on the examination data and the preliminary diagnostic results using a base large language model.

[0018] In this application, by constructing a clinical diagnostic thinking chain and a theoretical diagnostic thinking chain, and then integrating them to perform multiple hypothesis verifications, an optimized examination form is generated and a structured report is output. This approach can effectively identify critical illnesses with low probability and high mortality, simulate a clinical thinking chain for rigorous diagnosis, and reduce medical illusions, thereby improving the accuracy and safety of diagnosis.

[0019] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0020] The above and other objects, features and advantages of this application will become more apparent from the more detailed description of exemplary embodiments thereof in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments thereof.

[0021] Figure 1 This is a schematic diagram of a medical clinical support system based on multiple hypothesis testing, as shown in an embodiment of this application. Figure 2 This is another schematic diagram of the structure of a medical clinical support system based on multiple hypothesis verification, as shown in the embodiments of this application; Figure 3 This is an overall architecture diagram of a medical clinical support system based on multiple hypothesis testing, as shown in the embodiments of this application; Figure 4 This is a schematic diagram of the parallel processing flow of clinical phenotype anchoring and atlas differential diagnosis shown in the embodiments of this application; Figure 5 This is an algorithm logic diagram of the inspection planning module shown in an embodiment of this application; Figure 6 This is a timing diagram illustrating the data interaction between the system, the medical base model, and the doctor's workstation, as shown in the embodiments of this application. Detailed Implementation

[0022] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to make this application more thorough and complete, and to fully convey the scope of this application to those skilled in the art.

[0023] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0024] It should be understood that although the terms "first," "second," "third," etc., may be used in this application to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0025] In traditional medical auxiliary diagnostic systems, the lack of a simulation mechanism for doctors' clinical thought processes means that existing models cannot perform deterministic logical reasoning based on medical knowledge graphs. This leads to the neglect of diseases with low incidence but high mortality rates. At the same time, the system cannot enforce compliance with treatment guidelines, which can easily generate examination suggestions that do not meet medical standards and diagnostic outputs based on illusions. This affects the accuracy and compliance of diagnoses. In terms of diagnostic accuracy, the system lacks sufficient coverage of complex diseases, while in terms of compliance, the system deviates from the examination suggestions and treatment guidelines.

[0026] For example, in an emergency department setting, when a patient inputs chief complaints such as "chest pain, cold sweats, and shortness of breath," the existing system only matches common disease patterns and outputs a preliminary diagnosis of "gastroesophageal reflux," without considering high-mortality diseases such as acute myocardial infarction. The system does not utilize medical knowledge graphs to construct multiple hypothesis verification paths, thus failing to generate key examination suggestions such as electrocardiograms, making it impossible to identify potential critical illnesses in a timely manner. In particular, key symptom entities in the chief complaint data are misclassified, leading to a break in the diagnostic thought process, and the examination planning process lacks logical reasoning for competing diseases.

[0027] If the above problems are not addressed, the system will be unable to effectively handle the differential diagnosis of low-probability, high-risk diseases, leading to an increased risk of missed diagnoses of high-mortality diseases, continued occurrence of examination behaviors that do not conform to the diagnostic and treatment guidelines, and the possibility of erroneous diagnostic outputs based on hallucinations, which may result in erroneous diagnostic and treatment decisions, thereby endangering patients' lives and violating medical regulatory requirements. Furthermore, the diagnostic space is not reasonably constrained, resulting in a lack of traceable evidence chains to support auxiliary reports.

[0028] For this, see Figure 1 and 2 This application proposes a medical clinical support system based on multiple hypothesis testing. The following section combines... Figure 3-6 The system structure and working principle proposed in this application are described in detail.

[0029] like Figure 1 As shown, the system includes: a clinical entity extraction module 110, a clinical diagnostic path construction module 120, a theoretical diagnostic path construction module 130, an examination planning module 140, and a report constraint generation module 150.

[0030] The clinical entity extraction module 110 receives the user's chief complaint data input in natural language and generates the user's clinical entities from the chief complaint data based on standard medical terminology encoding. The chief complaint data refers to the patient's or their family's description of their condition to the doctor in natural language, typically including symptoms, signs, medical history, and medication history. The clinical entities refer to the standardized medical concepts extracted from the chief complaint data, such as specific disease names, symptom descriptions, physical signs, drug names, and examination items. Generating the user's clinical entities from the chief complaint data based on standard medical terminology encoding specifically involves performing medical named entity recognition, context disambiguation, and standard medical terminology encoding mapping on the natural language chief complaint data to generate a set of clinical entities.

[0031] In one implementation, the clinical entity extraction module 110 can be configured to directly receive text information input by the user and match the text using a preset keyword list. When a keyword is matched, it is recognized as a preliminary medical concept. Subsequently, these preliminary concepts can be mapped to a medical glossary to obtain standardized clinical entities. For example, if the user inputs "headache," the system recognizes "headache" and maps it to the standard entity "headache."

[0032] In another implementation, the clinical entity extraction module 110 can employ a rule-based text analysis method to identify medically relevant phrases in the chief complaint data by defining a series of grammatical rules and patterns, and convert them into structured clinical entities. For example, rules can be used to identify "fever" and "cough" as independent symptom entities in "fever with cough".

[0033] The clinical diagnostic pathway construction module 120 is connected to the clinical entity extraction module 110 and is used to match and filter multiple candidate cases from the medical record database based on the clinical entity, and to construct a clinical diagnostic thinking chain based on the multiple candidate cases; wherein, the clinical diagnostic thinking chain refers to the diagnostic path constructed by the system based on the patient's clinical entity and matching and filtering similar cases from historical cases.

[0034] Specifically, the clinical diagnostic pathway construction module 120 can be configured to use extracted clinical entities as query conditions for direct matching in a pre-stored medical record database. For example, by calculating the overlap between clinical entities and the symptoms and signs recorded in the medical records, several cases with high overlap can be selected as candidate cases. Subsequently, the diagnostic results of these candidate cases can be statistically analyzed, and the frequently occurring diagnostic results and their corresponding main symptom pathways can be used as a preliminary clinical diagnostic thought chain. For example, if multiple candidate cases are diagnosed as "cold" and all are accompanied by "fever and cough," then "fever—cough—cold" can be used as a clinical diagnostic thought chain.

[0035] The theoretical diagnostic path construction module 130 is connected to the clinical entity extraction module 110 and is used to construct a theoretical diagnostic thinking chain based on the clinical entity and in combination with a preset medical knowledge graph. The medical knowledge graph refers to medical domain knowledge organized and stored in the form of a graph, which includes entities such as diseases, symptoms, examinations, and drugs, as well as the relationships between them. The theoretical diagnostic thinking chain refers to the diagnostic path constructed by the system based on the patient's clinical entity and in combination with the medical knowledge graph through logical reasoning.

[0036] In this embodiment, the theoretical diagnostic path construction module 130 can be configured to use clinical entities as starting nodes and perform single-hop or double-hop neighbor node queries in the medical knowledge graph. For example, it can query disease nodes directly associated with "fever" and examination nodes further associated with these disease nodes. Thus, a network containing these disease and examination nodes can be constructed as a preliminary form of the theoretical diagnostic thought chain. This network can only include the direct association between symptoms and diseases, without delving into causal or differential relationships. For example, when "chest pain" is input, the system can directly extract diseases related to "chest pain," such as "angina" and "pneumonia," from the knowledge graph and incorporate these diseases as components of the theoretical diagnostic thought chain.

[0037] Specifically, the clinical diagnostic path construction module 120 can be understood as matching candidate cases in the historical medical record database based on the clinical entity set, and generating a first diagnostic path graph based on the recorded diagnostic results, diagnostic features and case similarity in the candidate cases. The first diagnostic path graph includes clinical entity nodes, candidate disease nodes, case evidence nodes, relationship edges and confidence weights corresponding to the relationship edges.

[0038] The theoretical diagnostic path construction module 130 uses the clinical entity set as query nodes, traverses the path along the relationship edges between symptoms, diseases, and examinations in the medical knowledge graph, and generates a second diagnostic path graph. The second diagnostic path graph includes candidate disease nodes, candidate examination nodes, and causal relationship edges related to the clinical entity set. Consistency analysis is performed on the first diagnostic path graph and the second diagnostic path graph. A fusion diagnostic path graph is generated based on consistent paths, conflicting paths, and high-risk retained paths. A diagnostic space containing multiple competing disease hypotheses and their probability distributions is formed based on the fusion diagnostic path graph.

[0039] The examination planning module 140 is connected to the clinical diagnostic pathway construction module 120 and the theoretical diagnostic pathway construction module 130, and is used to construct a fusion diagnostic thinking chain based on the clinical diagnostic thinking chain and the theoretical diagnostic thinking chain; to perform a preliminary diagnosis of the clinical entity using the fusion diagnostic thinking chain, and to calculate the information gain of the preliminary diagnostic results using a competitive hypothesis approach; and to generate an examination form based on the information gain and the preliminary diagnostic results, wherein the examination form contains multiple examination items. The fusion diagnostic thinking chain refers to a comprehensive diagnostic path formed by combining the clinical diagnostic thinking chain and the theoretical diagnostic thinking chain after consistency analysis. This thinking chain aims to integrate empirical knowledge and theoretical knowledge to provide a basis for diagnosis. The information gain refers to a quantitative indicator that reduces diagnostic uncertainty by introducing new examination items or information during the diagnostic process.

[0040] In one implementation, the examination planning module 140 can be configured to use diseases co-occurring in both the clinical and theoretical diagnostic thought chains as the core of the integrated diagnostic thought chain. Subsequently, a preliminary diagnosis can be made based on the frequency of occurrence or preset weights of these core diseases. For the optimal selection of examination indicators, a diagnostic value score can be pre-assigned to each examination item. After the preliminary diagnosis, the system directly selects several examination items with high scores and adds them to the examination list. For example, if the preliminary diagnosis points to a respiratory disease, the system can directly add examination items such as "chest X-ray" and "complete blood count" to the examination list based on preset scores.

[0041] Specifically, the examination planning module 140 selects candidate examination items from the diagnostic space, simulates the impact of each candidate examination item on the update of the probability distribution under different examination results, calculates the expected information gain of each candidate examination item, and generates examination suggestions or examination forms to be confirmed based on the expected information gain. Further, it obtains the examination results corresponding to the examination suggestions or examination forms to be confirmed, and performs likelihood calculations and probability updates on the disease hypotheses in the diagnostic space based on the examination results to obtain the updated diagnostic space.

[0042] The report constraint generation module 150 is connected to the inspection planning module 140 and is used to obtain the inspection data corresponding to the inspection form, and to output an auxiliary report based on the inspection data and the preliminary diagnosis results using the base large language model; wherein, the base large language model refers to a deep learning model trained on large-scale text data, which has the ability to understand and generate natural language.

[0043] In this embodiment, the report constraint generation module 150 can be configured to directly input the acquired examination data and preliminary diagnostic results into the base language model. Upon receiving this information, the base language model can generate a text report containing diagnostic suggestions and a description of the examination results based on its internally trained knowledge and patterns. For example, upon receiving "abnormal blood routine" and "preliminary diagnosis of infection," the base language model can generate a report describing the infection and suggesting further treatment. This process may not involve structured constraints or logical verification of the generated content, relying solely on the generation capabilities of the large language model.

[0044] Specifically, the report constraint generation module 150 constructs a positive evidence chain and a reverse exclusion chain based on the updated diagnostic space, the fused diagnostic path diagram, and the examination results, and inputs the positive evidence chain and the reverse exclusion chain as logical constraints into the large language model to constrain or verify the generation of the structured auxiliary diagnostic report.

[0045] This system constructs clinical diagnostic thinking chains and theoretical diagnostic thinking chains in parallel through the clinical diagnostic pathway construction module 120 and the theoretical diagnostic pathway construction module 130, effectively simulating the logical thinking of doctors in making differential diagnoses by combining experience and theoretical knowledge in actual diagnosis and treatment.

[0046] The inspection planning module 140 achieves intelligent optimization of inspection items by constructing a fusion diagnostic thinking chain and calculating information gain using competitive assumptions. This differs from existing methods that generate inspection lists based on experience or preset rules.

[0047] The report constraint generation module 150 utilizes the base large language model to generate auxiliary reports and provides structured, evidence-supported reports by integrating examination data and preliminary diagnostic results. This overcomes the "medical illusion" problem that may occur with existing large language models in the medical field.

[0048] In summary, the medical clinical support system of this embodiment, through the collaborative work of multiple modules, effectively simulates the clinical thinking of doctors, improves the accuracy and comprehensiveness of diagnosis, optimizes the rationality of examination planning, and ensures the rigor and reliability of auxiliary reports, thereby enhancing the intelligence level of medical clinical support.

[0049] like Figure 2 As shown, the clinical entity extraction module 110 includes an interface unit 111, an entity recognition unit 112, and an encoding conversion unit 113.

[0050] Interface unit 111 is the input terminal of clinical entity extraction module 110. Its function is to establish a connection with the input module of an external medical system to receive the chief complaint data entered by the user in natural language. This chief complaint data is understood to be the raw information describing the patient's condition, typically including physical status, specific symptoms, past medical history, and other relevant medical record information. Interface unit 111 can be configured to receive data in various ways. For example, it can be a text input box integrated into an electronic medical record system, allowing doctors or patients to directly enter text; it can be a speech recognition interface to convert the patient's spoken condition into text data; or it can be a data interface for batch importing structured or unstructured chief complaint text from other medical information systems, such as doctor workstations, electronic medical record systems, internet consultation systems, or speech recognition systems.

[0051] The entity recognition unit 112 is connected to the interface unit 111. Its core function is to perform deep processing on the received chief complaint data using a medical language model to identify and abstract key medical entities. Specifically, the entity recognition unit 112 first performs word segmentation on the chief complaint data, dividing the continuous text into meaningful word sequences. Subsequently, it performs medical named entity recognition (NER) to accurately identify entities with specific medical significance from the word sequences, such as symptom entities (e.g., "cough," "fever"), signs entities (e.g., "rash," "edema"), past medical history entities (e.g., "history of hypertension," "history of diabetes"), and medication entities (e.g., "aspirin," "penicillin"). The medical language model can be a pre-trained model based on deep learning. For example, it can use a Transformer architecture model trained on a large amount of medical text, such as BioBERT or ClinicalBERT, to perform entity recognition with its powerful semantic understanding capabilities. Alternatively, it can be a hybrid model that combines rule matching and statistical learning methods, which performs initial recognition through a predefined medical dictionary and grammatical rules, and then uses machine learning algorithms such as Conditional Random Field (CRF) or Support Vector Machine (SVM) for optimization and validation.

[0052] The encoding conversion unit 113 is connected to the entity recognition unit 112, and its main task is to standardize and encode the medical entities identified by the entity recognition unit 112. Given the complexity and ambiguity of medical terminology in natural language, the encoding conversion unit 113 first performs context disambiguation processing on potentially ambiguous symptom entities, sign entities, medical history entities, and medication entities based on a pre-defined medical dictionary, ensuring that each entity has a clear medical meaning, thus obtaining a standard entity set. For example, the term "cold" may refer to the common cold or influenza in different contexts, which can be distinguished through context analysis. Subsequently, the encoding conversion unit 113 maps each entity in the standard entity set to a standard medical terminology encoding system, such as the International Classification of Diseases (ICD), Systematic Medical Nomenclature (SNOMED CT), or Medical Subject Headings (MeSH), ultimately generating unified clinical entities. This mapping process can employ rule-based dictionary matching algorithms to match standard entities with preset codes one-to-one or many-to-one; it can also use semantic similarity-based algorithms to calculate the similarity between entities and their coded descriptions and select the best-matching code; or it can utilize ontological reasoning techniques to search for the entity's superordinate concepts or synonyms in the medical knowledge graph to achieve more accurate code conversion.

[0053] The clinical entity extraction module 110 of this application, through the collaborative work of the interface unit 111, entity recognition unit 112, and encoding conversion unit 113, realizes the transformation from unstructured natural language complaint data to standardized clinical entities. Specifically, the interface unit 111, acting as a bridge between the system and the user, is responsible for accurately receiving raw natural language complaint data containing information such as the patient's physical condition, symptoms, past medical history, and medical records. Subsequently, this raw data is transmitted to the entity recognition unit 112. The entity recognition unit 112 utilizes its built-in medical language model to perform refined word segmentation processing on the received complaint data and execute medical named entity recognition, thereby transforming unstructured text information into preliminary, medically meaningful symptom entities, sign entities, past medical history entities, and medication entities. This process effectively extracts key medical concepts from massive amounts of text. Next, the encoding conversion unit 113 intervenes. It first performs context disambiguation processing on potentially ambiguous entities identified by the entity recognition unit 112 based on a pre-set medical dictionary, ensuring that each entity has a unique and accurate medical meaning, thus forming a clear set of standard entities. Finally, the encoding conversion unit 113 maps all entities in this set of standard entities to a unified standard medical terminology encoding system, ultimately generating standardized clinical entities. Through this phased and progressive processing flow, the proposed solution effectively overcomes the ambiguity and diversity of natural language expressions, ensuring that the subsequent clinical diagnostic thinking chain construction module 120 and theoretical diagnostic path construction module 130 receive high-quality, unambiguous, and standardized clinical entity data, thereby providing a solid data foundation for the entire medical clinical support system and significantly improving the accuracy and reliability of diagnostic reasoning.

[0054] This application further proposes that the clinical diagnostic pathway construction module 120 includes: a clinical phenotype anchoring unit 121, used to construct a patient feature vector based on the clinical entity, and to select Top-K candidate cases by calculating the cosine similarity between the patient feature vector and the pre-stored case prototype vector; and a first differential diagnosis reasoning unit 122, used to statistically analyze the distribution of diagnostic results corresponding to the Top-K candidate cases, generate a candidate disease set, and construct a probabilistic clinical diagnostic thought chain based on the candidate disease set.

[0055] The clinical phenotype anchoring unit 121 aims to transform the patient's discrete clinical information into a unified, computable numerical representation, and based on this, quickly locate and filter historical cases most similar to the current patient's condition in a large medical record database.

[0056] The implementation methods can include: one approach is to use deep learning models, such as recurrent neural networks (RNNs) or Transformer models, to sequence encode clinical entities and generate fixed-length patient feature vectors; another approach is to use pre-trained medical domain word embedding models (e.g., Word2Vec or FastText models trained on large-scale medical texts) to map each clinical entity into a vector, and then aggregate these entity vectors (e.g., by averaging or weighted averaging) to form patient feature vectors.

[0057] When selecting Top-K candidate cases, a threshold-based method can be used, i.e., setting a cosine similarity threshold and selecting all cases with similarity higher than that threshold; or the top K cases with the highest similarity can be directly selected. A patient feature vector is a numerical representation of a patient's clinical entity in a multidimensional space, capable of capturing the inherent relationships and semantic features of patient symptoms, signs, medical history, and other information. Pre-stored case prototype vectors are numerical representations of the clinical characteristics of each historical case in the medical record database in a multidimensional space, typically calculated and stored in advance when cases are added to the database.

[0058] Cosine similarity is a metric that measures the cosine of the angle between two non-zero vectors. Its value ranges from -1 to 1 and is commonly used to assess the similarity between two case feature vectors. A higher value indicates a higher similarity. Top-K candidate cases refer to the K historical cases with the highest cosine similarity to the current patient's feature vector.

[0059] In practical applications, when the clinical diagnostic thought chain is expressed using the first diagnostic path diagram, a patient feature vector is generated based on the clinical entity set; the similarity between the patient feature vector and the case prototype vector in the historical medical record database is calculated, and candidate cases whose similarity meets the threshold condition or ranks in the top K are selected; the recorded disease diagnosis results in the candidate cases are statistically analyzed to form the disease prior probability; the diagnostic features and diagnostic logic in the candidate cases are extracted, and the diagnostic features, disease prior probability, and case similarity are written into the first diagnostic path diagram. 4. The case prototype vector is generated based on symptoms, signs, past medical history, examination results, recorded diagnosis results, and diagnosis time series in historical cases, and is pre-stored when the case is entered into the database; the case similarity includes cosine similarity, semantic similarity, entity overlap, or a weighted combination thereof.

[0060] The first differential diagnosis reasoning unit 122 is responsible for statistically analyzing the diagnostic information of the selected Top-K candidate cases, and on this basis, constructing a clinical diagnostic thinking chain with probability information.

[0061] The implementation methods can include: one method is to analyze the diagnostic records of Top-K candidate cases, count the frequency of each disease, and convert it into a frequency distribution to obtain a set of candidate diseases and their corresponding probabilities; another method is to use Bayesian inference or decision tree algorithms to associate the symptoms, signs and diagnostic results of candidate cases to construct a probabilistic graphical model, where nodes represent diseases and edges represent the conditional probabilities of symptoms and diseases, thus forming a probabilistic clinical diagnostic thinking chain.

[0062] The distribution of diagnostic results refers to the frequency or proportion of different disease diagnoses among the Top-K candidate cases. The candidate disease set refers to the set of all diseases that have occurred among the Top-K candidate cases.

[0063] Probabilistic clinical diagnostic thinking chain refers to a diagnostic path or graph structure that includes disease nodes and their corresponding probabilities of occurrence. It can quantify the likelihood of different diseases and provide probabilistic basis for subsequent differential diagnosis.

[0064] The proposed solution significantly improves the efficiency and accuracy of the clinical diagnostic pathway construction module 120 through the collaborative work of the clinical phenotype anchoring unit 121 and the first differential diagnosis reasoning unit 122. Specifically, after the clinical entity extraction module 110 generates the patient's clinical entities, the clinical phenotype anchoring unit 121 first transforms these clinical entities into structured patient feature vectors. This transformation process utilizes advanced natural language processing and machine learning technologies, enabling the quantification and comparison of the patient's complex clinical information. Subsequently, the clinical phenotype anchoring unit 121 calculates the cosine similarity between the patient feature vector and the pre-stored case prototype vectors in the medical record database, enabling it to quickly and accurately select Top-K candidate cases from a massive number of historical cases that are most similar to the current patient's clinical presentation. This vector similarity-based selection mechanism overcomes the semantic gap and insufficient recall that may exist in traditional keyword matching, ensuring the high relevance of the selected cases.

[0065] Building upon this foundation, the first differential diagnostic reasoning unit 122 conducts in-depth statistical analysis of the diagnostic results of these highly correlated Top-K candidate cases, thereby generating a candidate disease set containing all possible diseases and further constructing a probabilistic clinical diagnostic thought chain. This probabilistic thought chain not only lists possible diagnoses but, more importantly, quantifies the probability of each disease, providing a clear probabilistic basis for subsequent differential diagnosis. In this way, the system can learn and summarize diagnostic patterns from real-world clinical data, making the constructed clinical diagnostic thought chain more clinically instructive and reliable. This approach closely integrates the patient's clinical entity with the diagnostic experience of historical cases, extracting valuable diagnostic clues from massive amounts of data and providing doctors with more precise and quantitative auxiliary diagnostic support.

[0066] In another embodiment, the first differential diagnosis reasoning unit 122 is specifically used to: extract the diagnostic logic and diagnostic features of each candidate case, and calculate the disease probability distribution of each candidate case in the Top-K candidate cases based on each diagnostic feature; construct a corresponding clinical diagnostic thinking chain based on the diagnostic logic and the diagnostic features, and assign a priority to each clinical diagnostic thinking chain according to the disease probability distribution.

[0067] This section involves an in-depth analysis of Top-K candidate cases. First, the inherent diagnostic logic and key diagnostic features of each candidate case are meticulously extracted. Diagnostic logic can be understood as the reasoning process, decision-making path, or treatment guidelines documented in the case, from symptoms to diagnosis. For example, what examinations are typically performed after the appearance of a certain symptom, and how the disease is inferred based on the examination results. Diagnostic features refer to key indicators clearly documented in the case, such as clinical manifestations, examination results, and pathological findings, that are highly correlated with the specific disease.

[0068] One approach is to use natural language processing technology to perform in-depth analysis of the text data of candidate cases, and identify statements describing the diagnostic process and key medical terms through methods such as pattern matching and information extraction.

[0069] Another approach is to pre-build a knowledge base or rule set containing diagnostic logic templates and feature lists for common diseases, and then compare candidate cases with this knowledge base to extract matching diagnostic logic and features.

[0070] Subsequently, based on these extracted diagnostic features, the probability of occurrence of the disease represented by each candidate case in the current patient context is accurately calculated, thus forming a disease probability distribution. This disease probability distribution reflects the relative likelihood of each disease occurring given the patient's clinical entity and the Top-K candidate cases.

[0071] One approach is to use machine learning models, such as support vector machines, logistic regression, or Bayesian networks, to take the extracted diagnostic features as input, combine them with historical data to train the model, and output the posterior probability of each disease.

[0072] Another approach is based on statistical methods, such as counting the frequency of each disease in the Top-K candidate cases and adjusting it with expert experience or preset weights to obtain the probability distribution of the diseases.

[0073] Based on this, the previously extracted diagnostic logic and diagnostic features are organically combined to construct multiple specific clinical diagnostic thought chains. Each thought chain clearly describes the reasoning process from the patient's clinical entity to the diagnosis of a specific disease.

[0074] The clinical diagnostic thinking chain is a reasoning sequence that starts from the patient's clinical entity, goes through a series of symptoms, signs, examinations, differential diagnoses, etc., and ultimately points to the diagnosis of one or more diseases.

[0075] One approach is to utilize graph database technology, treating each step in the diagnostic logic (such as symptoms, examinations, and diseases) as nodes and the relationships between them (such as "cause," "hint," and "exclusion") as edges, thus constructing a directed graph structure. Diagnostic features then serve as the attributes of the nodes or the weights of the edges.

[0076] Another approach is to use a rule-based expert system, which encodes the diagnostic logic into a series of "if-then" rules. When a specific diagnostic feature is met, the corresponding rule is triggered, the diagnostic conclusion is deduced step by step, and the reasoning path is recorded.

[0077] Finally, based on the previously calculated disease probability distribution, each constructed clinical diagnostic thought chain is assigned a corresponding priority. The priority reflects the urgency or importance of considering and verifying the disease pointed to by that thought chain in the current context.

[0078] One approach is to directly use the previously calculated disease probability distribution as the priority score for the corresponding clinical diagnostic thought chain; the higher the probability, the higher the priority.

[0079] Another approach is to weight the probability of a disease by combining factors such as its severity and the urgency of treatment, thus creating a comprehensive priority score. For example, even if the probability of a certain disease is slightly low, if its mortality or disability rate is extremely high, its corresponding thought chain priority can be increased.

[0080] In this way, this embodiment further refines the originally potentially vague "probabilistic clinical diagnostic thinking chain" into specific diagnostic paths with clear priorities and operability, effectively solving the problem of having only probability distributions but lacking specific action guidance. It provides more accurate and efficient input for subsequent planning of examination indicators, significantly improving the efficiency and accuracy of clinical diagnosis.

[0081] In one specific embodiment, the theoretical diagnostic path construction module 130 includes a query unit 131 and a differential diagnostic reasoning unit 132.

[0082] The query unit 131 is used to filter candidate graphs from the medical knowledge graph database that contain at least two identical symptom entities, sign entities, medical history entities, and medication entities, using clinical entities as graph query nodes. This query unit 131 interacts with the medical knowledge graph database to obtain information related to patient clinical entities. Its function is to receive clinical entities generated by the clinical entity extraction module 110 and use them as the starting node for graph queries. To improve query efficiency and relevance, the query unit 131 is designed to filter candidate graphs that contain at least two identical types of entities (e.g., two symptom entities, two sign entities, two medical history entities, or two medication entities). This filtering mechanism ensures that the obtained graph fragments have a certain degree of complexity and relevance, avoiding overly broad queries based on only a single entity. The query unit 131 can be implemented using a graph database query language (e.g., SPARQL, Cypher) or can perform query operations by calling a preset knowledge graph API interface.

[0083] The differential diagnosis reasoning unit 132 performs a reverse causal path traversal along the symptom-disease-examination relationship edges in the candidate graph, extracting disease nodes and examination nodes related to clinical entities, and constructing a differential diagnosis subgraph containing multiple competing diseases. Based on the candidate graph selected by the query unit, this unit 132 performs deep reasoning analysis. Its core function is to perform a reverse causal path traversal along the predefined symptom-disease-examination relationship edges in the medical knowledge graph. This means that the reasoning process starts from observed symptoms or signs, traces back to the diseases that may cause these symptoms, and further identifies examination indicators related to these diseases. Through this traversal, the differential diagnosis reasoning unit 132 can extract disease nodes and examination nodes directly related to clinical entities. Finally, the unit 132 organizes these extracted nodes and their relationships to construct a differential diagnosis subgraph containing multiple competing diseases, providing a structured theoretical basis for subsequent diagnostic decisions. This differential diagnosis reasoning unit 132 can be implemented based on graph traversal algorithms (such as depth-first search and breadth-first search) combined with a medical rule engine or probabilistic reasoning model.

[0084] In practical applications, within the theoretical diagnostic path construction module 130, the query unit 131 first receives clinical entities provided by the clinical entity extraction module 110. The query unit 131 uses these clinical entities as graph query nodes to intelligently filter through a vast medical knowledge graph database. Its filtering logic involves identifying and extracting candidate graphs that contain at least two of the same types of symptom entities, sign entities, past medical history entities, and medication entities. This mechanism effectively focuses the search scope of the knowledge graph on areas with stronger correlation and complexity to the patient's clinical manifestations, thereby avoiding blind or inefficient traversal of the entire knowledge graph.

[0085] Subsequently, the differential diagnosis reasoning unit 132 receives these filtered candidate graphs. This unit 132 performs a reverse causal path traversal along the pre-defined symptom-disease-examination relationship edges in the medical knowledge graph. Specifically, it starts from the patient's symptoms and signs, inversely deduces the diseases that may lead to these clinical manifestations, and further identifies the examination indicators that can differentiate these diseases. Through this systematic traversal and reasoning, the differential diagnosis reasoning unit 132 can accurately extract disease nodes and examination nodes related to clinical entities, and ultimately construct a differential diagnosis subgraph containing multiple competing diseases. This subgraph not only clearly shows the association between different diseases and the patient's clinical entity, but also indicates the key examinations required to differentiate these diseases, thus providing a structured and theoretical diagnostic basis for the subsequent examination planning module, effectively solving the problem of efficiently extracting differential diagnosis information from massive amounts of medical knowledge.

[0086] Suppose the clinical entity extraction module 110 identifies the patient's clinical entities as including "fever," "cough," "sore throat," and "past history: asthma." After receiving these clinical entities, the query unit 131 of the theoretical diagnostic path construction module 130 uses them as query nodes to search the medical knowledge graph database. The query unit 131 prioritizes candidate graphs that simultaneously contain the symptom entities "fever" and "cough," or simultaneously contain the symptom entity "fever" and the past history entity "asthma." For example, it might filter graph fragments related to diseases such as "common cold," "influenza," "acute bronchitis," and "pneumonia," because these diseases typically present with symptoms such as "fever" and "cough." Next, the differential diagnosis reasoning unit 132 performs a reverse causal path traversal based on these selected candidate graphs. For the symptoms "fever" and "cough," the differential diagnosis reasoning unit 132 traces back to disease nodes such as "common cold," "influenza," "acute bronchitis," and "pneumonia." Simultaneously, it identifies examination nodes related to these diseases. For example, "influenza" might require "influenza virus nucleic acid testing," while "pneumonia" might require "chest X-ray" or "complete blood count." Through this traversal, the differential diagnosis reasoning unit 132 ultimately constructs a differential diagnosis subgraph, which clearly shows multiple competing diseases such as "common cold," "influenza," "acute bronchitis," and "pneumonia," as well as their relationships with the patient's clinical entities and differential examinations.

[0087] In practical applications, when the theoretical diagnostic thinking chain is expressed using a second diagnostic path graph, at least two entities in the clinical entity set are used as joint query conditions to retrieve candidate subgraphs containing the joint query conditions in the medical knowledge graph. In the candidate subgraphs, forward or reverse path traversal is performed along the relational edges from symptoms to diseases, signs to diseases, past history to diseases, diseases to examinations, and examinations to diseases. Disease nodes and examination nodes related to the clinical entity set are extracted to generate a second diagnostic path graph containing multiple competing diseases.

[0088] Through the aforementioned technical solutions, the theoretical diagnostic path construction module 130 can efficiently and accurately extract highly relevant differential diagnostic information from a complex medical knowledge graph based on the patient's clinical entities. The intelligent filtering mechanism of the query unit 131 effectively focuses the search scope of the knowledge graph, avoiding interference from invalid information. The differential diagnostic reasoning unit 132, through reverse causal path traversal, systematically identifies disease nodes and examination nodes related to clinical entities and constructs a differential diagnostic subgraph containing multiple competing diseases. This not only provides a structured and theoretical basis for subsequent diagnostic decisions but also significantly improves the accuracy and efficiency of constructing the theoretical diagnostic thought chain, ensuring that potential differential diagnoses can be comprehensively considered when facing complex clinical situations, thereby providing doctors with more reliable auxiliary diagnostic support.

[0089] In one specific embodiment, the examination planning module 140 includes: a fusion unit 141, used to perform consistency analysis based on the clinical diagnostic thinking chain and the theoretical diagnostic thinking chain, and construct a fusion diagnostic thinking chain based on the analysis results; a pre-diagnosis unit 142, used to diagnose the clinical entity based on the fusion diagnostic thinking chain to obtain a diagnostic space; a gain unit 143, used to calculate the uncertainty entropy value of each disease option in the diagnostic space; and calculate the expected information gain of each candidate examination item by simulating the diagnostic changes under different examination results based on the uncertainty entropy value through multiple hypothesis verification; and an index planning unit 144, used to select the examination item with the largest information gain to generate an examination form.

[0090] It should be noted that the fusion unit 141 aims to integrate diagnostic information from different sources. Its function is to perform consistency analysis on the clinical diagnostic thinking chain and the theoretical diagnostic thinking chain, identify the commonalities, differences and potential conflicts between the two, and construct a more comprehensive and reliable fusion diagnostic thinking chain based on the analysis results.

[0091] Implementation methods may include: one approach is to use a weighted average or voting mechanism to assign different weights to the two thought chains based on their confidence or source reliability for fusion; another approach is to use expert systems or machine learning models to learn from historical case data to identify and resolve inconsistencies between the two thought chains, thereby generating an optimized fusion diagnostic thought chain.

[0092] The pre-diagnosis unit 142 is responsible for making a preliminary diagnosis of clinical entities using the constructed fusion diagnostic thinking chain. Its role is to deduce a list of possible diseases and their corresponding probabilities or confidence levels based on the patient's clinical entity information and the disease-symptom-examination relationship in the fusion diagnostic thinking chain, thereby forming a diagnostic space that includes all possible disease hypotheses.

[0093] Implementation methods may include: one approach is to perform reasoning based on probabilistic graphical models (such as Bayesian networks) to calculate the posterior probability of each disease under a given clinical entity; another approach is to use a rule-based reasoning engine to match diagnostic rules and clinical entities in the fusion diagnostic thinking chain to generate a preliminary set of diagnostic results.

[0094] Furthermore, the fusion here can be as follows: when both the first and second diagnostic path maps point to the same candidate disease, the confidence weight of the path corresponding to that candidate disease is increased; when the first and second diagnostic path maps point to conflicting candidate diseases, the conflicting paths are downweighted or retained based on the source of evidence, path length, case similarity, and edge weights of the medical knowledge graph; when there is a candidate disease with low probability of occurrence but high severity in the second diagnostic path map, that candidate disease is written into the fused diagnostic path map as a high-risk retained path.

[0095] The core function of gain unit 143 is to evaluate the potential of different examination items to reduce diagnostic uncertainty. It first calculates the uncertainty entropy value of each disease option in the diagnostic space, which reflects the degree of ambiguity of the current diagnostic result. Then, through multiple hypothesis testing, it simulates various possible outcomes after performing different examination items (e.g., a positive or negative result for one examination) and predicts how these outcomes will change the probability distribution of each disease in the diagnostic space. Based on these simulations, the unit calculates the expected information gain that each candidate examination item can bring, i.e., how much diagnostic uncertainty that examination item can reduce.

[0096] Implementation methods may include: one approach is to use Shannon entropy from information theory to quantify uncertainty and then use Bayesian updates to simulate the impact of examination results on disease probability, thereby calculating the expected information gain; another approach is to use decision trees or reinforcement learning methods to determine the information gain by evaluating the diagnostic benefits of different examination paths.

[0097] The purpose of the indicator planning unit 144 is to intelligently select the most diagnostically valuable examination items based on the evaluation results of the gain unit. Its function is to receive the information gain of each candidate examination item calculated by the gain unit and select the examination item with the highest information gain, ensuring that each examination helps the doctor narrow down the diagnostic scope or confirm the diagnosis to the greatest extent possible. Finally, the indicator planning unit 144 integrates the selected examination items to generate an examination report.

[0098] Implementation methods may include: one is to use a greedy algorithm to directly select the inspection item with the largest current information gain; the other is to use a heuristic search algorithm to consider the combined effect of multiple inspection items in order to optimize the overall diagnostic path.

[0099] Specifically, this module first receives clinical diagnostic thought chains and theoretical diagnostic thought chains as input. The fusion unit 141 performs a detailed consistency analysis on these two thought chains, including identifying their similarities and differences in disease hypotheses, symptom associations, and examination recommendations. This analysis effectively bridges potential conflicts between information from different sources and integrates their complementary advantages, thereby constructing a more comprehensive, accurate, and higher-confidence fusion diagnostic thought chain. This fusion diagnostic thought chain not only incorporates insights from clinical experience but also integrates the rigorous logic of medical knowledge graphs, laying a solid foundation for subsequent diagnosis. Subsequently, the pre-diagnosis unit 142 uses this fusion diagnostic thought chain to make a preliminary diagnosis of the patient's clinical entity. It matches the patient's symptoms, signs, and other information with the disease patterns in the fusion diagnostic thought chain, thereby deriving a series of possible disease hypotheses and assigning a corresponding probability or confidence level to each hypothesis, forming a preliminary diagnostic space. This diagnostic space clearly shows all possible diagnostic directions and their uncertainties at the current stage. To further narrow the diagnostic scope and improve diagnostic accuracy, the gain unit 143 plays a crucial role. It first quantifies the uncertainty of each disease option in the diagnostic space, for example, by calculating entropy values. Next, the gain unit 143 employs a multiple hypothesis testing strategy to simulate the possible outcomes of performing different examinations. For example, for a suspected disease, the system simulates how the probabilities of each disease in the diagnostic space would change if a blood test were performed and the result was positive or negative. Through this simulation, the gain unit 143 can predict how much diagnostic uncertainty each candidate examination item is expected to reduce, i.e., its information gain. Finally, the indicator planning unit 144 intelligently selects the most valuable examination items based on the information gain calculated by the gain unit. It prioritizes examination items that can minimize diagnostic uncertainty and are most helpful in differentiating competing diseases. In this way, the system can generate a highly optimized examination schedule, ensuring that each examination has a clear diagnostic purpose and maximum efficiency, avoiding blind examinations and wasted resources. This overall operational logic, from multi-source information fusion to intelligent examination planning, enables the system to provide an efficient, accurate, and personalized clinical auxiliary diagnostic process, significantly improving the scientific rigor and efficiency of diagnosis.

[0100] In one specific embodiment, the gain unit 143 is specifically used to: extract a local subgraph of Top-K diseases in the diagnostic space; enumerate candidate examination items in the local subgraph, and simulate the diagnostic distribution of each candidate examination under different results through multiple hypothesis testing; and calculate the expected information gain of each candidate examination based on the diagnostic distribution.

[0101] The process involves extracting local subgraphs of the Top-K diseases in the diagnostic space. This aims to focus on the numerous disease options that may exist in the diagnostic space, concentrating only on the K diseases that are most likely or have the greatest differential diagnostic value. These K diseases can be ranked based on the probability or confidence level of each disease option in the diagnostic space obtained from the pre-diagnosis unit, selecting the K diseases with the highest probability. Subsequently, a subgraph directly related to these K diseases (e.g., connected by edges related to symptoms, signs, and examination results) is extracted from a pre-defined medical knowledge graph to form a local subgraph. Alternatively, clinical experience rules or pre-defined disease association thresholds can be used to filter out the K diseases highly related to the current clinical entity from the diagnostic space. Then, graph database query technology is used to retrieve and construct a subgraph from the medical knowledge graph containing only these K diseases and their directly related symptoms, examinations, and other nodes.

[0102] This approach enumerates candidate examination items in a local subgraph and simulates the diagnostic distribution of each candidate examination under different outcomes using multiple hypothesis testing. Its purpose is to identify which examination items are most valuable for identifying Top-K diseases after focusing on the local subgraph. Multiple hypothesis testing is a method to evaluate the impact of different examination results on the probability of disease diagnosis by simulating them. Specifically, for each examination node in the local subgraph, possible positive, negative, abnormal, or normal results can be simulated. For each simulated result, the posterior probability distribution of Top-K diseases in the diagnostic space is recalculated using Bayesian inference or other probability update models. For example, if a simulated examination result is positive, the probability of diseases strongly associated with that result is updated, while the probability of diseases inconsistent with that result is reduced. Alternatively, a probability distribution model for examination results can be pre-defined (e.g., based on historical data or expert experience), and then multiple simulated result scenarios can be generated for each candidate examination item in the local subgraph based on its probability distribution. Under each scenario, a base large language model or a pre-trained diagnostic model is used, combined with the simulated examination results and the current clinical entities, to predict the updated disease diagnosis distribution.

[0103] The expected information gain for each candidate examination is calculated based on the diagnostic distribution. Information gain measures the degree to which an examination reduces diagnostic uncertainty. By calculating the expected information gain, the value of each examination item to the differential diagnosis can be quantified, thus guiding examination planning. Specifically, Shannon entropy can be used to quantify the uncertainty of the diagnostic distribution. First, the entropy value (H(D)) of the current diagnostic distribution is calculated. Then, for each candidate examination item, the conditional entropy (H(D|E)) after obtaining the examination result is calculated based on its different simulated results and their probabilities. The expected information gain is the difference between the current entropy value and the weighted average of the conditional entropies of all possible results. Alternatively, other uncertainty measures such as the Gini index or cross-entropy can be used. After updating the simulated diagnostic distribution, the difference in uncertainty measures before and after the update is calculated and weighted averaged with the probability of the examination result to obtain the expected information gain.

[0104] The simulation check gain process actually performs simulation calculations of multiple candidate hypotheses, for example, Candidate A: Perform a gastroscopy. If negative, GERD is ruled out, but AMI cannot be diagnosed. Information gain is moderate, and the procedure is invasive and time-consuming.

[0105] Candidate B: Perform an electrocardiogram (ECG). If ST-segment elevation is present, it directly confirms acute myocardial infarction (AMI), with the entropy value dropping to 0. If normal, STEMI is ruled out. The information gain is extremely high, it is non-invasive, and results are available in seconds.

[0106] Candidate C: Check for D-dimer. Used to rule out pulmonary embolism.

[0107] Decision output: The planning module calculates that Order_ECG has the highest cost-effectiveness (ROI).

[0108] The system queries the LIS system to see if the patient has an ECG result for today. If not, it generates a suggestion: "Please perform an 18-lead ECG immediately."

[0109] Closed-loop update: Suppose the doctor uploads ECG results: "ST segment elevation >0.1mV in V1-V5". The graph engine receives this evidence: - The probability of path B (GERD) is extremely compressed (although it may coexist, it is not the primary contradiction). The confidence of path A (AMI) is updated to 99%.

[0110] Furthermore, the gain unit 143 is specifically used for: calculating the Shannon entropy of each candidate examination item under the corresponding diagnostic distribution; predicting the probability of occurrence of the candidate examination item under different results, and calculating the updated diagnostic entropy under different results; calculating the difference between the Shannon entropy and the diagnostic entropy, and determining the information gain of the corresponding candidate examination item with the preset expected entropy.

[0111] In practical applications, the information gain is calculated by the expected entropy reduction, and the formula for calculating the expected entropy reduction is as follows: , Where H(D) is the Shannon entropy, Candidate inspection items, To check for possible positive or negative results, for The prior probability, In order to know The conditional entropy after that.

[0112] It's important to note that calculating the Shannon entropy of each candidate test item under its corresponding diagnostic distribution involves quantifying the probability distribution of each disease option in the current diagnostic space to measure the degree of uncertainty in the current diagnosis. Shannon entropy, a fundamental concept in information theory, effectively represents the uncertainty of a random variable. For example, it can be obtained by taking the logarithm of the probabilities of all disease options in the diagnostic space and summing the results; the larger the value, the higher the uncertainty of the current diagnosis. Predicting the probability of a candidate test item occurring under different outcomes means estimating the likelihood of various possible results (e.g., positive, negative, or a specific numerical range) before performing a candidate test. This can be done through historical medical data statistics, epidemiological data analysis, medical expert experience, or based on machine learning models. For example, for a test targeting a specific disease, the probability of a positive result and the probability of a negative result can be predicted. Calculating the updated diagnostic entropy under different outcomes means, after assuming a candidate test item produces a specific result, updating the probability distribution of each disease option in the current diagnostic space using that result, and recalculating the Shannon entropy of the updated diagnostic distribution. Typically, this probability update employs methods such as Bayes' theorem to incorporate evidence from the examination results into the prior probability of the disease, thereby obtaining the posterior probability distribution of the disease. Calculating the difference between the Shannon entropy and the diagnostic entropy involves comparing the initial Shannon entropy before the examination with the updated diagnostic entropy after the examination under a specific outcome. The difference represents the amount of information provided by that specific examination result. The larger this difference, the greater the contribution of the examination result to reducing diagnostic uncertainty. Determining the information gain of the corresponding candidate examination item by comparing it with a preset expected entropy involves combining the calculated difference with the probability of the specific outcome and using a weighted average to calculate the expected information gain of the candidate examination item across all possible outcomes. This expected information gain can be compared with a preset expected entropy (e.g., a threshold or benchmark used to screen examination items) to ultimately determine the value of the examination item.

[0113] Furthermore, the Shannon entropy of the diagnostic space is calculated: , Where D={d_1,d_2,…,d_n} represents the set of disease hypotheses in the diagnostic space, and p(d_i) represents the current probability of disease hypothesis d_i.

[0114] According to claim 7, the medical clinical support system based on multiple hypothesis testing is characterized in that the examination planning module is used to calculate the expected information gain for candidate examination item e: , Where R_e represents the set of possible examination results for candidate examination item e, P(r|e) represents the predicted probability of examination result r, and H(D|e=r) represents the conditional entropy obtained by updating the diagnostic space after knowing the examination result r.

[0115] Candidate inspection items are selected based on the comprehensive utility function: , Where Risk(e) represents the risk-benefit of candidate examination items for the identification of critical and severe illnesses, Cost(e) represents the examination cost, Time(e) represents the examination time, Invasive(e) represents the invasiveness of the examination, and α, β, γ, δ, and η are weighting coefficients.

[0116] At this point, the report constraint generation module 150 specifically extracts positive causal paths supporting the target disease hypothesis from the fusion diagnostic path graph, and filters key evidence nodes consistent with the positive causal paths based on the examination results to generate a positive evidence chain; obtains a set of candidate diseases competing with the target disease hypothesis from the diagnostic space, identifies paths that conflict with the key discriminant features corresponding to each candidate disease based on the examination results, and marks conflicting paths as pruned paths to generate a reverse exclusion chain; and inputs the positive evidence chain and the reverse exclusion chain into a large language model to generate a structured auxiliary diagnostic report.

[0117] By introducing Shannon entropy as an indicator to quantify diagnostic uncertainty, and combining it with the prediction of the probability of different outcomes of candidate examination items and the calculation of the updated diagnostic entropy using Bayesian methods, a rigorous and quantifiable method is provided to evaluate the information gain of each candidate examination item. Specifically, the system first quantifies the uncertainty of the current diagnostic space, i.e., calculates Shannon entropy. Subsequently, for each candidate examination item to be evaluated, the system predicts the probability of its various possible outcomes. Assuming a certain examination outcome occurs, the system uses methods such as Bayes' theorem to update the probability distribution of each disease option in the diagnostic space and recalculates the updated diagnostic entropy. By calculating the difference between the initial diagnostic entropy and the updated diagnostic entropy, the amount of information brought by that specific examination outcome can be obtained. Finally, by weighting and averaging the information brought by all possible outcomes with their corresponding probabilities, the expected information gain of the candidate examination item can be obtained. This information theory-based quantitative method enables the examination planning module to objectively and accurately evaluate the contribution of each examination item to reducing diagnostic uncertainty. Thus, after the initial diagnosis of clinical entities using the integrated diagnostic thinking chain, it can more scientifically select the examination items with the greatest information gain and generate more instructive examination reports.

[0118] In actual clinical diagnosis, diagnosis is often an iterative and dynamic process that requires continuous revision and improvement of the preliminary diagnosis based on new test results in order to improve the accuracy and efficiency of diagnosis.

[0119] In this regard, the examination planning module 140 in this application also includes a diagnostic closed-loop update unit 145, which is specifically used for: obtaining the examination results returned by the external examination system, wherein the examination results are the examination data corresponding to the examination form; performing likelihood calculation on each disease option in the diagnostic space based on the examination results, and updating the occurrence probability of each disease option using Bayes' formula; determining whether the disease option with the highest occurrence probability among the disease options exceeds a preset threshold, and if not, continuing to plan and calculate the information gain of each examination item.

[0120] The examination results returned by the external examination system correspond to the examination report, serving as the input for the diagnostic closed loop. This ensures the system obtains objective evidence corresponding to the previously generated examination reports. These results form the basis for updating disease probabilities. The system can establish data interfaces with external examination systems such as the hospital's LIS (Laboratory Information System) or PACS (Picture Archiving and Communication System), acquiring examination report data in real-time or periodically via API calls, message queue subscriptions, or file transfers. Alternatively, the examination data can be manually entered or scanned from paper reports, structuring the data before inputting it into the system. The core reasoning step of the diagnostic closed loop involves calculating the likelihood of each disease option in the diagnostic space based on the examination results and updating the probability of occurrence of each disease option using Bayes' theorem. By using new examination results as evidence, combined with existing prior disease probabilities, and employing probabilistic reasoning methods (such as Bayes' theorem), the posterior probability of each disease under a given examination result is calculated, thereby quantifying the impact of new evidence on the diagnosis. For each disease option, the conditional probability (likelihood value) between it and each examination result can be pre-stored. When the inspection results are obtained, these likelihood values ​​are substituted into Bayes' formula: P(D|E) = P(E|D) P(D) / P(E), where P(D) is the prior probability of the disease, P(E|D) is the likelihood of the examination result occurring in disease D, and P(D|E) is the updated posterior probability. Alternatively, a more complex probabilistic graphical model (such as a Bayesian network) can be used to represent the relationship between diseases, symptoms, and examination results, and inference algorithms (such as belief propagation algorithms) can be used for probability updates. The decision and control mechanism of the diagnostic closed loop is to determine whether the disease option with the highest probability of occurrence among all disease options exceeds a preset threshold. If not, the information gain of each examination item is calculated. This is used to assess the certainty of the current diagnosis. If the posterior probability of a disease is high enough (exceeding the threshold), the diagnosis is considered basically clear, and further examination planning can be stopped; otherwise, it indicates that the diagnosis still has uncertainty, and iterative planning of new examinations is needed to obtain more information. A confidence threshold can be preset (e.g., 0.8 or 0.9). After updating the occurrence probabilities of all disease options, the disease with the highest probability is identified and its probability is compared with a threshold. Alternatively, the probability difference between multiple high-probability diseases can be used for judgment. For example, if the difference between the highest and second-highest probabilities is less than a certain threshold, the diagnosis is considered unclear and further investigation is required. For instance, examination results can be obtained from laboratory information systems, medical imaging systems, hospital information systems, or electronic medical record systems; the likelihood value of each disease hypothesis under the examination results can be calculated; the occurrence probabilities of each disease hypothesis can be updated using Bayes' theorem; when the highest disease probability in the updated diagnostic space is lower than a preset report trigger threshold, or the difference between the probabilities of the top two diseases is lower than a preset distinction threshold, the examination planning module is triggered to continue calculating the expected information gain of candidate examination items.

[0121] Upon receiving the examination results returned by the external examination system corresponding to the previously generated examination form, the diagnostic closed-loop update unit 145 initiates a reassessment of the diagnostic probability. It performs likelihood calculations on each disease option in the diagnostic space, effectively quantifying the degree to which new examination results support or refute each potential diagnosis. Crucially, this unit then updates the probability of occurrence for each disease option using Bayesian formulas. This Bayesian update mechanism allows the system to combine new evidence (examination results) with existing understanding of disease probabilities, thereby providing a more refined and accurate assessment of the probability of each disease. After the probability update, the system determines whether the disease option with the highest probability of occurrence exceeds a preset threshold. This step serves as a convergence criterion for the diagnostic process. If a single disease reaches a sufficiently high probability, it indicates that the diagnosis is essentially clear, and the iterative process can end. Otherwise, the system continues to calculate the information gain of each examination item. This ensures that if the diagnosis remains uncertain, the system automatically restarts the information gain calculation process to identify the next most informative examination, thus pushing the diagnostic process towards a clear conclusion through continuous iteration. This closed-loop mechanism allows the system to dynamically adjust its diagnostic strategy based on incoming evidence, continuously improving the diagnosis until a satisfactory level of certainty is reached, thereby enhancing the overall accuracy and efficiency of medical clinical support systems.

[0122] In another embodiment, the system further includes a critical illness risk identification module 160 connected to the examination planning module 140, specifically used to mark high-mortality disease options in the diagnostic space and calculate the comprehensive confidence level of the disease options; when the confidence level exceeds a threshold, a circuit breaker mechanism is triggered, an emergency treatment instruction is output and the generation of examination reports is terminated.

[0123] It should be noted that the Critical Illness Risk Identification Module 160 is a component specifically designed to identify and manage potentially life-threatening illnesses. This module can be deployed as a standalone software service, interacting with the examination planning module via an API interface, or integrated as a sub-function of the examination planning module. Its primary function is to add a safety barrier to the routine diagnostic process, ensuring that high-risk diseases are detected promptly and prioritized for treatment.

[0124] The option to mark high-fatality diseases in the diagnostic space refers to the ability of the critical illness risk identification module to identify diseases with high-fatality characteristics from the diagnostic space generated by the pre-diagnosis unit. This can be achieved through a preset disease list containing known high-fatality diseases and their corresponding medical terminology codes; alternatively, the system can combine a medical knowledge graph to dynamically identify diseases by querying the attributes of disease nodes (e.g., mortality rate, prognosis severity, etc.).

[0125] Calculating the overall confidence level of the disease options refers to the risk assessment performed by the critical illness risk identification module on the labeled high-mortality disease options. This confidence level can be calculated based on a combination of factors, such as the probability distribution of the disease in the diagnostic space, the degree of matching with the patient's clinical entities (such as symptoms and signs), and preset expert experience weights. Another approach is to utilize a pre-trained machine learning model, inputting the patient's clinical entities and preliminary diagnostic results, to directly output the confidence level that the disease is a critical illness.

[0126] The circuit breaker mechanism, triggered when the confidence level exceeds a threshold, means that once the overall confidence level of a high-fatality disease option reaches or exceeds a preset safety threshold, the system will immediately initiate an emergency response. This circuit breaker mechanism can manifest as an interruption of the software process. For example, by setting a global status flag, once triggered, the subsequent checklist generation process will stop; or, through an event listener, when a high-confidence critical illness is detected, the preset circuit breaker logic will be executed immediately.

[0127] Outputting emergency medical instructions means that once the circuit breaker mechanism is triggered, the system will no longer generate routine examination reports, but will immediately provide users (such as doctors) with clear and guiding emergency medical advice. These instructions can be preset standardized emergency procedure templates, such as "immediately perform an electrocardiogram and activate the emergency green channel"; or they can be integrated with the hospital information system (HIS) or electronic medical record system (EMR) to automatically generate and push emergency consultation or referral notices.

[0128] Terminating checklist generation means that after the circuit breaker mechanism is triggered, the checklist planning module will stop its original process of selecting checklists based on information gain and generating checklists. This means that the system will no longer attempt to make a diagnosis through further examinations, but will instead focus on the immediate treatment of critical and severe cases, avoiding delays in treatment due to waiting for checklist results.

[0129] In another embodiment, the critical illness risk identification module 160 can further mark high-mortality or high-disability disease hypotheses in the diagnostic space based on the disease severity attributes in a preset high-risk disease database or medical knowledge graph; calculate the risk confidence of the high-mortality or high-disability disease hypotheses based on the disease hypothesis probability, clinical entity matching degree, disease severity weight, and key negative or positive evidence; when the risk confidence exceeds a preset risk threshold, output priority risk warning and priority examination suggestion, and place the priority examination suggestion before the regular information gain ranking results.

[0130] The proposed solution introduces a critical illness risk identification module 160 during the preliminary diagnosis stage to assess the risk of disease options within the diagnostic space. When a high-fatality disease is identified and its overall confidence level reaches a preset threshold, the system immediately triggers a circuit breaker mechanism, interrupting the routine examination report generation process and instead outputting emergency treatment instructions. This mechanism allows the system to prioritize patient safety while pursuing diagnostic efficiency, avoiding the potential delays in diagnosis and treatment of critical illnesses that might result from over-reliance on information gain optimization of examinations. By tightly integrating the critical illness risk identification module with the examination planning module, the system provides refined diagnostic assistance while also possessing the ability to respond rapidly to sudden high-risk situations, thereby improving the comprehensiveness and safety of clinical decision-making.

[0131] Furthermore, the report constraint generation module 150 includes a data fusion unit 151, an evidence chain construction unit 152, an exclusion chain construction unit 153, and a report generation unit 154.

[0132] The data fusion unit 151 receives examination data, preliminary diagnostic results, and diagnostic path information from the fusion diagnostic thought chain, and performs structured fusion to generate unified diagnostic context data. This data fusion unit 151 is responsible for integrating, cleaning, and standardizing diagnostic-related data from different sources and formats to form a unified, structured dataset. Its role is to provide a consistent and comprehensive information foundation for subsequent evidence chain construction and report generation. Specifically, a unified data model or ontology can be defined, mapping the received examination data, preliminary diagnostic results, and diagnostic path information from the fusion diagnostic thought chain into this model. Data type conversion, missing value imputation, and redundant information removal are then performed to ultimately generate unified context data containing all relevant diagnostic information. Alternatively, rule-based or machine learning methods can be used to semantically align and associate data from different sources. For example, structured indicators can be extracted from the free text descriptions in the examination report using natural language processing technology and associated with disease entities in the preliminary diagnostic results and causal relationships in the diagnostic path, thereby constructing comprehensive diagnostic context data.

[0133] The evidence chain construction unit 152 is connected to the data fusion unit 151 and is used to extract positive causal paths supporting the target disease from the fusion diagnostic thinking chain, and to screen key evidence nodes based on examination data to construct a positive evidence chain. This evidence chain construction unit 152 is responsible for identifying and extracting key information supporting the final diagnostic conclusion from the complex diagnostic thinking chain, and organizing it into a logically clear sequence of evidence. Its role is to provide strong support for the diagnostic report and enhance the persuasiveness of the diagnostic conclusion. For example, by traversing the fusion diagnostic thinking chain, causal paths related to the preliminary diagnostic result (target disease) can be identified, such as paths from symptoms to disease, and from disease to examination results. Then, combined with actual examination data, key evidence that matches the nodes on the path (such as specific symptoms, positive examination results) is screened and organized according to causal relationships or chronological order to form a positive evidence chain. Alternatively, graph algorithms, such as shortest path algorithms or influence analysis, can be used to find the path that best explains the target disease in the fusion diagnostic thinking chain. At the same time, by comparing with the inspection data, we can verify whether the nodes on these paths are supported by actual data, thereby constructing a concise and persuasive chain of positive evidence.

[0134] The exclusion chain construction unit 153, connected to the evidence chain construction unit 152, is used to identify candidate diseases competing with the target disease based on examination data, extract falsified causal paths, and construct a reverse exclusion evidence chain. This exclusion chain construction unit 153 is responsible for identifying and organizing candidate diseases competing with the preliminary diagnostic result (target disease) and explaining the key evidence for excluding these competing diseases. Its role is to improve the rigor and transparency of the diagnostic process, demonstrating the system's ability in differential diagnosis. Specifically, a set of candidate diseases competing with the target disease can be obtained from the diagnostic space. Then, based on examination data, key discriminant features of these candidate diseases (e.g., negative test results or absent symptoms specific to a certain disease) are identified. If the examination data conflicts with these discriminant features (e.g., the test results show that the feature is absent, but the disease requires the feature), the candidate disease and its falsified causal path are extracted to form a reverse exclusion evidence chain. Alternatively, paths that have been "pruned" or have significantly reduced confidence in the fusion diagnostic thought chain can be analyzed; these paths typically correspond to excluded disease hypotheses. By combining the examination data, it is possible to clearly identify which examination results directly refute the diagnosis of these competing diseases, thereby constructing a reverse exclusion chain of evidence.

[0135] The report generation unit 154 is connected to the evidence chain construction unit 152 and the exclusion chain construction unit 153, and is used to invoke the base big language model to generate a structured auxiliary diagnostic report based on the positive evidence chain and the negative exclusion evidence chain. This report generation unit 154 is responsible for using the base big language model to transform the structured positive evidence chain and the negative exclusion evidence chain into a natural language auxiliary diagnostic report. Its function is to present complex diagnostic logic and data in a human-readable way, facilitating clinicians' understanding and decision-making. For example, the positive evidence chain and the negative exclusion evidence chain can be used as structured input, combined with a preset report template and the generation capability of the base big language model, guiding the model to generate report text according to a specific logical order (such as diagnostic conclusion, evidence support, exclusion basis, and treatment recommendations). The model can summarize, interpret, and organize the key information in the evidence chain. Alternatively, key entities, relationships, and values ​​in the evidence chain and the exclusion chain can be encoded to form a specific prompt input to the base big language model. Upon receiving this prompt, the model leverages its powerful language understanding and generation capabilities to automatically organize the language and generate an accurate, logically clear, and medically compliant auxiliary diagnostic report. Specifically, the structured auxiliary diagnostic report is generated based on the structured logic constraint protocol using at least one of the following methods: when the large language model supports decoding control, the structured logic constraint protocol is dynamically loaded during the decoding stage to filter or reweight candidate terms during the generation process; when the large language model does not support decoding control, the structured logic constraint protocol is converted into a structured prompt template, report field template, or post-output validation rules to constrain or validate the structured auxiliary diagnostic report.

[0136] Furthermore, the evidence chain construction unit 152 is specifically used for: identifying the shortest causal path corresponding to the target disease in the fusion diagnostic thinking chain; performing consistency verification on each node in the shortest causal path based on the examination data; selecting key evidence nodes that meet the diagnostic and treatment guidelines according to the verification results; and sorting the key evidence nodes according to time sequence or causal relationship to generate the positive evidence chain.

[0137] The identification of the shortest causal path corresponding to the target disease aims to quickly locate and extract the causal chain with the highest correlation and most direct logical relationship to the target disease from the complex chain of fusion diagnostic thinking. The chain of fusion diagnostic thinking typically contains a large number of nodes and edges, representing various medical concepts such as symptoms, signs, examinations, and diseases, and their interrelationships. Identifying the shortest causal path can employ path search algorithms in graph theory, such as breadth-first search or depth-first search, to find the path with the fewest steps or the strongest correlation from the patient's clinical entity to the target disease node. Alternatively, pre-defined medical logic rules or heuristic search methods based on expert experience can be used to determine the most diagnostically valuable path. This helps to focus on core evidence and avoid interference from irrelevant information.

[0138] Consistency checks are performed on each node in the shortest causal path based on the examination data to verify whether each medical concept node (such as symptoms, signs, examination results, etc.) in the identified shortest causal path matches the patient's actual examination data. Consistency checks can be performed by comparing the node information in the path with the patient's structured or unstructured examination data. For example, if the path contains a "hypertension" node, it is necessary to verify whether the patient's blood pressure measurement is indeed higher than the normal range; if it contains a "CT scan shows lung nodules" node, it is necessary to verify whether the corresponding description exists in the imaging report. The verification process can employ various methods such as exact matching, range matching, or semantic matching based on medical ontology. This step ensures the authenticity of the theoretical causal path at the individual patient level.

[0139] The goal of screening key evidence nodes that meet the criteria of treatment guidelines based on the verification results is to further filter out those nodes that have passed consistency verification and are not only real in patients but also conform to current medical treatment guidelines or expert consensus. Treatment guidelines typically specify the necessary conditions, supporting evidence, or exclusionary evidence required to diagnose a disease. The screening process can pre-encode the key diagnostic criteria in the treatment guidelines into a set of rules, and then compare the verified nodes against these rules. For example, for a certain disease, the guidelines may require "at least 3 major symptoms and 2 minor symptoms," and the system will screen according to this rule. This step enhances the clinical authority and standardization of the evidence.

[0140] The key evidence nodes are ordered according to chronological order or causal relationship to generate a positive evidence chain. This chain organizes the selected key evidence nodes according to their logical or chronological order in the course of the disease, forming a clear and coherent positive evidence chain. Chronological ordering is suitable for evidence with a clear onset time or examination time point, such as "fever (day 1) → cough (day 2) → abnormal lung CT scan (day 3)". Causal ordering focuses on the logical deductive relationship between evidence, such as "smoking history → chronic cough → abnormal lung function → chronic obstructive pulmonary disease". A reasonable ordering can better demonstrate the diagnostic logic of the disease, enabling doctors to intuitively understand the diagnostic basis and improving the readability and persuasiveness of the report.

[0141] In another embodiment, the report constraint generation module 150 further includes: A logical constraint construction unit is used to convert the positive evidence chain and the reverse exclusion evidence chain into a structured logical constraint template; The constraint injection unit, connected to the logical constraint construction unit, is used to embed the structured logical constraint template as a decoding constraint into the generation process of the base large language model. A generation control unit is used to limit the candidate output space of the base large language model under the logical constraints, so that the generation result strictly conforms to the fusion diagnostic thinking chain.

[0142] This application's solution employs a logical constraint construction unit, a constraint injection unit, and a generation control unit to rigorously control the report generation process of the base large language model through medical logic. Specifically, the logical constraint construction unit first uses the positive evidence chain and the reverse exclusion evidence chain provided by the data fusion unit 151 in the report constraint generation module 150. These evidence chains represent the positive causal path supporting the target disease and the reverse causal path excluding competing diseases extracted from the fusion diagnostic thinking chain, transforming them into machine-understandable structured logical constraint templates. These templates precisely encode the medical logical relationship between the diagnostic conclusion, supporting evidence, and exclusion criteria. Subsequently, the constraint injection unit embeds these structured logical constraint templates as decoding constraints into the generation process of the base large language model. This means that at each step of the model's report generation, these medical logic rules will play a role, guiding the model's text generation direction. Finally, under the strict constraints of these logical constraints, the generation control unit filters and adjusts the candidate output space of the base large language model, ensuring that every word and sentence generated by the model strictly conforms to the medical logic and reasoning path established by the fusion diagnostic thinking chain. In this way, the proposed solution effectively solves the "illusion" problem that may exist in the base-based large language model, ensuring the medical rigor and accuracy of the assisted diagnostic report. This makes the report content not only fluent and natural, but also impeccable in medical logic, thereby significantly improving the reliability of the system in clinical decision support.

[0143] In one specific implementation, the logical constraint construction unit is specifically used to: transform the diagnostic path in the positive evidence chain into a strong constraint rule that must meet the conditions; transform the disproven path in the reverse exclusion evidence chain into an exclusion constraint rule that prohibits the generation of content; transform the preliminary diagnostic results and their confidence levels into output priority control parameters; and construct a structured logical constraint protocol based on the above information.

[0144] Transforming the diagnostic path in the positive evidence chain into strongly constrained rules that must be met involves encoding the key causal chains or sequences of evidence that directly support the diagnosis of the target disease into mandatory logical expressions or rule sets. These strongly constrained rules ensure that the base language model must include and explicitly articulate these core diagnostic paths and their supporting evidence during report generation. For example, if "symptom A" combined with "examination result B" clearly points to "disease C," then the report must reflect the diagnosis of "disease C" and cite "symptom A" and "examination result B" as its basis. This can be achieved by constructing formal logical statements, such as first-order predicate logic or descriptive logical expressions, or by defining structured data templates that require specific fields to be filled in.

[0145] Transforming falsified paths in a reverse exclusion chain of evidence into exclusion constraints that prohibit content generation refers to converting causal paths used to exclude competing diseases or disprove specific diagnostic hypotheses into content or logic explicitly prohibited from appearing in reports. These exclusion constraints effectively prevent the base language model from introducing erroneous information or misleading diagnoses that contradict actual evidence when generating reports. For example, if "Examination Result D" explicitly excludes "Disease E," then "Disease E" must not be mentioned in the report as a possible diagnosis. This can be achieved by defining a list of negative keywords, prohibiting specific semantic patterns, or constructing negative logical expressions.

[0146] Transforming preliminary diagnostic results and their confidence levels into output priority control parameters refers to generating parameters that guide the base language model in emphasizing or prioritizing different information in the report, based on the system's preliminary diagnostic results for clinical entities and the confidence level of those results. Preliminary diagnostic results with higher confidence levels can correspond to higher priority parameters, prompting the language model to elaborate more comprehensively and prominently on the basis of the diagnosis, the differential diagnosis process, and treatment recommendations in the report. This can be achieved by assigning weights to different diagnostic options or information types, or by embedding emphasis instructions in the generated prompts.

[0147] Building a structured logical constraint protocol based on the above information refers to integrating strong constraint rules, exclusion constraint rules, and output priority control parameters into a unified protocol or framework with clear syntax and semantics. This protocol defines the representation methods, interrelationships, and how these different types of constraints are parsed and applied by the underlying large language model. This can be represented using structured data formats such as JSON Schema, XML documents, or domain-specific languages ​​(DSLs), ensuring the integrity, consistency, and machine readability of the constraints.

[0148] In another embodiment, the exclusion chain construction unit 153 is specifically used for: obtaining a set of candidate diseases competing with the target disease from the diagnostic space; identifying key discriminant features corresponding to each candidate disease based on the examination data; determining whether the key discriminant features conflict with the examination data; extracting the corresponding causal path for the candidate disease that conflicts, marking it as a pruned path, and generating the reverse exclusion evidence chain.

[0149] Understandably, the exclusion chain construction unit 153 systematically constructs a reverse exclusion evidence chain through a series of logically rigorous steps, thereby enhancing the accuracy and credibility of the auxiliary diagnostic report. First, the unit obtains a set of candidate diseases competing with the target disease from the diagnostic space. These candidate diseases are potential differential diagnoses derived from clinical entities and preliminary diagnostic results through medical knowledge graphs or historical case data analysis. Then, for each candidate disease, the exclusion chain construction unit 153 identifies its unique key discriminant features, based on pre-defined medical knowledge or treatment guidelines, that can distinguish it from other diseases (especially the target disease). These features can be specific symptoms, signs, or laboratory test indicators. Next, the unit rigorously compares these identified key discriminant features with the patient's actual examination data. If a candidate disease's key discriminant feature is inconsistent or contradictory to the patient's examination data—for example, if the patient's examination results clearly exclude a core diagnostic criterion for the disease—then the candidate disease is considered to conflict with the patient's actual situation. Once a conflict is found, the system traces the complete causal path of the conflicting candidate disease in the fusion diagnostic thought chain and marks it as a "pruned path." These pruned paths clearly demonstrate the specific reasons and basis for excluding the candidate disease. Ultimately, all these causal paths marked as pruned are integrated to form a reverse exclusion evidence chain. This evidence chain not only explicitly lists the excluded candidate diseases but also provides specific examination data and logical justification for their exclusion, thus providing a solid basis for the auxiliary report generated by the base large language model, ensuring the report's rigor and persuasiveness. In this way, the exclusion chain construction unit 1203 of this application can effectively utilize examination data to falsify differential diagnoses, avoiding the risk of misdiagnosis or missed diagnosis, and improving the decision support capability of the entire auxiliary diagnostic system in complex differential diagnostic scenarios.

[0150] Furthermore, the report generation unit 154 is specifically used to: perform structured encoding on the positive evidence chain and the reverse exclusion evidence chain based on a preset medical report template; input the encoded data and the preliminary diagnosis result and its confidence level into the base large language model; control the base large language model to generate an auxiliary report in the logical order of "diagnosis conclusion - evidence support - exclusion basis - treatment suggestion"; and output a natural language diagnosis report that conforms to clinical diagnosis and treatment standards.

[0151] In this technical solution, the positive evidence chain and the negative exclusion evidence chain are structured and encoded based on a preset medical report template. This aims to transform unstructured or semi-structured information from the positive and negative exclusion evidence chains into a structured format that is easily understood and processed by the base language model. For example, a JSON or XML-based data structure can be defined to map key information in the evidence chain, such as disease nodes, symptoms, examination results, causal relationships, and reasons for exclusion, to predefined fields. Alternatively, a specific markup language, such as Markdown or a custom text template, can be used to fill the evidence chain content into the corresponding placeholders in the template, thus providing a clear and standardized input to the large language model. The encoded data, along with the preliminary diagnosis result and its confidence level, is input into the base language model. Its function is to provide the base language model with all the core information needed to generate the report, including structured evidence and the preliminary judgment and reliability of the diagnosis. Specifically, the structured and encoded evidence chain data, the preliminary diagnosis result, and its confidence level can be concatenated into a unified input prompt, which serves as the input to the base language model. Furthermore, encoded data can be used as context, and preliminary diagnostic results and confidence levels can be used as specific instructions or parameters, passed to the base language model via an application programming interface (API). The base language model is controlled to generate auxiliary reports according to the logical order of "diagnostic conclusion—supporting evidence—exclusion criteria—treatment recommendations," aiming to ensure that the generated reports are logically clear, structurally rigorous, and conform to the reading habits and diagnostic and treatment processes of clinicians. In terms of implementation, the input prompts can explicitly instruct the base language model to strictly organize content according to this logical order. For example, the prompt can include instructions such as "Please generate an auxiliary diagnostic report strictly according to the order of 'diagnostic conclusion—supporting evidence—exclusion criteria—treatment recommendations' based on the following information." Additionally, a post-processing mechanism can be used to structurally adjust the original text generated by the base language model to ensure it conforms to the preset logical order. The output is a natural language diagnostic report that conforms to clinical diagnostic and treatment standards, aiming to ultimately produce a professional and easy-to-understand report that clinicians can directly refer to and use. To achieve this goal, the base language model can be fine-tuned in the medical field to make its generated text more professional and standardized. In addition, the post-processing module can be used to perform grammatical, medical terminology, and standardization checks and corrections on the reports generated by the base large language model to ensure the accuracy and compliance of the reports.

[0152] This application's solution transforms complex medical reasoning processes into standardized data understandable by a foundational large language model by structurally encoding the positive and negative chains of evidence and the chains of exclusion. This encoded data, along with the preliminary diagnostic results and their confidence levels, is then input into the foundational large language model, providing it with a comprehensive and structured diagnostic context. Based on this, a precise control mechanism guides the foundational large language model to strictly adhere to the inherent logical sequence of clinical diagnosis and treatment: "diagnosis conclusion—evidence support—exclusion criteria—treatment recommendations." This control not only ensures the structure and logical rigor of the report but also, through standardized constraints on the model's output, ensures that the final generated natural language diagnostic report highly conforms to clinical diagnostic and treatment guidelines. Through this approach, this application effectively solves the problems of structural confusion, unclear logic, and non-compliance with professional standards that may occur when the foundational large language model generates clinical reports, enabling the system to output high-quality, reliable, and easily understood and adopted auxiliary diagnostic reports by clinicians.

[0153] In this embodiment, the constraint injection unit is specifically used to: dynamically load the structured logical constraints during the decoding stage of the base large language model; filter candidate tokens in the generation process and filter tokens that do not conform to the logical constraints; perform probability reweighting on tokens that conform to the logical constraints; and generate the final report text based on the filtered and reweighted token sequence.

[0154] Dynamic loading refers to the process of acquiring and applying pre-built structured logical constraints on demand, based on the current generation context or requirements, during the real-time text generation (i.e., decoding) of the base large language model. This differs from loading all constraints at once during model training or before inference begins. Instead, it allows the system to flexibly introduce or update relevant constraints based on the report generation progress, the currently generated report section (e.g., diagnostic conclusions, supporting evidence, exclusion criteria), or specific clinical situations. Implementation methods can include: the constraint management module retrieving and providing corresponding logical constraints from the constraint library based on the current generation status (e.g., generated text prefixes, report paragraph types to be generated) when the decoder requests them; or, through an application programming interface (API) or event-triggered mechanism, calling external services in real-time to acquire or update constraints when the decoder generates specific content.

[0155] Candidate tokens refer to a series of possible words and their corresponding probability values ​​predicted by the base language model based on its internal probability distribution when generating the next word (token). "Filtering" refers to evaluating and filtering these candidate tokens to ensure that only tokens that conform to preset logical constraints can enter the subsequent generation stage. "Filtering tokens that do not conform to the logical constraints" means removing tokens that contradict, are inconsistent with, or are irrelevant to the medical knowledge graph, positive evidence chain, negative exclusion evidence chain, or preliminary diagnosis results from the candidate list. For example, if the logical constraint explicitly states that a certain disease has been excluded, then any token mentioning that disease will be filtered out. Implementation methods may include: a rule-based matcher that compares each candidate token with keywords, phrases, or patterns in the logical constraints, directly eliminating those that do not conform; or a semantic consistency checker that uses an additional semantic model or knowledge base to determine whether the candidate token's semantics conflict with the current logical constraint, filtering out those that conflict.

[0156] Probabilistic reweighting refers to adjusting the original generation probability of tokens after they have been selected and found to conform to logical constraints. Tokens conforming to these constraints are those words that have passed the screening stage and are deemed to be consistent with medical logic and clinical facts. Reweighting increases the generation probability of tokens highly relevant to core diagnostic conclusions, key evidence, or exclusion criteria, while decreasing the probability of tokens that, although conforming to constraints, are of lower importance or poorly expressed. This helps guide large language models to prioritize more accurate, concise, and clinically appropriate words. Implementation methods can include: linear weighting or multiplicative weighting, assigning different weight factors based on the degree of matching or importance of the token with the constraints to adjust its original probability; or using reinforcement learning or adversarial training methods to dynamically adjust the probability distribution of tokens through feedback mechanisms to optimize the quality and compliance of the generated text.

[0157] Generating the final report text based on the filtered and reweighted token sequence refers to the process where, after the aforementioned dynamic loading, filtering, and probability reweighting, the base large language model selects the most suitable token based on the adjusted token probability distribution and adds it to the generated text sequence. This process is iterated until a complete auxiliary report is generated. This process ensures that each generated token has undergone rigorous testing and optimization under logical constraints, thereby guaranteeing the accuracy, logicality, and clinical applicability of the final report text. Implementation methods can include: greedy decoding, selecting the token with the highest probability at each step; or beam search, retaining multiple sequences of tokens with the highest probability at each step and continuing to expand in subsequent steps to ultimately select the optimal sequence; or sampling methods, such as Top-K sampling or kernel sampling, randomly selecting tokens within a certain range to increase text diversity while still being guided by constraints.

[0158] This application's solution ensures the medical rigor and accuracy of the generated content by finely managing and applying structured logical constraints during the decoding stage of the auxiliary report generation using a base-based large language model. Specifically, when the base-based large language model begins generating report text, the constraint injection unit dynamically loads structured logical constraints related to the current generation task based on the current generation context and report structure. These constraints originate from the transformation of positive and negative exclusionary evidence chains, representing the core logic of the diagnosis and the key basis for exclusion. When the model predicts the next candidate token, the constraint injection unit first rigorously filters these candidate tokens. Any token that conflicts with, contradicts, or does not conform to medical facts from the loaded logical constraints will be immediately filtered out, thus fundamentally avoiding the generation of inaccurate or non-compliant content. Subsequently, for the candidate tokens that pass the filtering and conform to the logical constraints, the constraint injection unit further reweights their original generation probabilities. This reweighting mechanism increases the probability of tokens highly relevant to core diagnostic conclusions, key supporting evidence, or clear exclusion criteria, while decreasing the weight of secondary or poorly expressed tokens. This guides the model to prioritize the most accurate, concise, and clinically compliant expressions. Finally, the base language model generates the final auxiliary report text based on the filtered and reweighted token sequence. Through this combination of dynamic loading, rigorous filtering, and intelligent reweighting, the proposed solution effectively overcomes potential logical biases or factual errors that may occur in the free-generation mode of large language models. This ensures that the generated auxiliary report is not only linguistically fluent but also logically sound, significantly improving the clinical usability and credibility of the report.

[0159] In this embodiment, the report constraint generation module 150 further includes a consistency verification unit, which is specifically used for: The consistency between the diagnostic conclusions, evidence chains, and exclusion chains in the auxiliary report is verified; if a logical conflict is detected, a regeneration mechanism is triggered to re-invoke the report generation unit to generate the auxiliary report; if the consistency verification passes, the final report is output.

[0160] Specifically, this can involve performing consistency checks on the candidate disease descriptions, positive evidence chains, and reverse exclusion chains in the structured auxiliary diagnostic report; when a logical conflict is detected, feedback of the conflict information is sent to the report generation unit and regeneration is triggered; when the consistency check passes, the auxiliary report that has passed the check is output.

[0161] This consistency verification unit can be implemented in various ways. For example, a pre-set set of medical logic rules can be used to compare key medical entities in the report and the relationships between them to determine whether they conform to known medical knowledge and treatment guidelines. Alternatively, a specially trained semantic analysis model can be used to deeply understand the report text and identify potential semantic conflicts or logical breaks. Verifying the consistency between the diagnostic conclusions, evidence chains, and exclusion chains in the auxiliary report aims to comprehensively assess the logical rigor of the report. Specifically, the verification process may include: checking whether the diagnostic conclusions have a strong medical correlation with key information such as core symptoms, signs, and examination results in the evidence chain; and verifying whether the excluded diseases in the exclusion chain do indeed have a clear conflict or inconsistency with the examination data, thereby ensuring the rationality of the exclusion. Furthermore, key information in the report can be mapped to a medical knowledge graph, and the structured knowledge of the graph can be used for path verification to discover any logical relationships that do not conform to medical common sense. If a logical conflict is detected, a regeneration mechanism is triggered, re-calling the report generation unit to generate the auxiliary report. This mechanism provides the system with self-correction and iterative optimization capabilities. When the consistency verification unit detects logical problems in the report, it can send a feedback signal containing the conflict type and location to the report generation unit. Upon receiving the feedback, the report generation unit can adjust its generation strategy, for example, by modifying the input prompts of the base language model, adding stricter logical constraints, or introducing additional reasoning steps during the generation process to avoid recurring the same logical errors. If the consistency verification passes, the final report is output, ensuring that only rigorously reviewed and logically correct auxiliary reports are ultimately presented to clinicians. Verified reports can be directly displayed to users or integrated into medical information systems as a reference for clinical decision-making. Before output, the report can also be standardized to conform to the specific document specifications of the hospital or department.

[0162] In the aforementioned medical clinical support system based on multiple hypothesis testing, after generating the initial support report, the report constraint generation module introduces a consistency verification unit to ensure its clinical reliability. This unit receives the support report generated by the report generation unit using the foundational large language model and performs a comprehensive logical consistency check on its internal diagnostic conclusions, the positive evidence chain supporting those conclusions, and the reverse exclusion evidence chain excluding competing diseases. The verification process deeply analyzes the medical relevance and logical rationality between these key pieces of information; for example, it determines whether the diagnostic conclusions are sufficiently supported by the evidence chain and whether the exclusion chain is valid and contradictory in excluding other possibilities. Once the consistency verification unit detects any logical conflicts or inconsistencies in the support report, it immediately triggers a regeneration mechanism. This mechanism re-invokes the report generation unit and may provide specific feedback on the conflicts, prompting the report generation unit to adjust its generation strategy or correct its internal logic to generate a new support report. This iterative process continues until the consistency verification unit confirms that the generated support report achieves complete logical consistency between the diagnostic conclusions, the evidence chain, and the exclusion chain. Only after the auxiliary report passes a rigorous consistency check will it be output as the final report, thus ensuring that the auxiliary reports provided to clinicians are highly reliable, logically rigorous, and compliant with medical standards. In this way, this application effectively solves the logical inconsistency problem that may occur when large language models generate complex medical reports, significantly improving the quality and clinical usability of auxiliary reports.

[0163] The implementation of the medical clinical support system based on multiple hypothesis testing described above has the following significant technical advantages compared to existing large-scale medical model application solutions: By introducing causal ablation and guideline constraint injection based on medical knowledge graphs, this system fundamentally curbs the tendency of general-purpose large models to "fabricate" diagnostic suggestions, ensuring that the output is rigorous and consistent with evidence-based medicine. Utilizing entropy reduction programming, it can proactively calculate which tests are most effective in differentiating between two diseases, effectively simulating the clinical thinking of doctors, improving the accuracy and comprehensiveness of diagnoses, optimizing the rationality of examination planning, and ensuring the rigor and reliability of auxiliary reports, thereby enhancing the intelligence level of medical clinical assistance.

[0164] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A medical clinical support system based on multiple hypothesis testing, characterized in that, The system includes: The clinical entity extraction module is used to receive the user's chief complaint data input in natural language and generate the user's clinical entities from the chief complaint data based on standard medical terminology encoding. The clinical diagnostic path construction module, which is connected to the clinical entity extraction module, is used to match and filter multiple candidate cases from the medical record database based on the clinical entities, and to construct a clinical diagnostic thought chain based on the multiple candidate cases. The theoretical diagnostic path construction module, which is connected to the clinical entity extraction module, is used to construct a theoretical diagnostic thinking chain based on the clinical entities and in combination with a preset medical knowledge graph. An examination planning module connected to the clinical diagnostic pathway construction module and the theoretical diagnostic pathway construction module is used to construct a fusion diagnostic thinking chain based on the clinical diagnostic thinking chain and the theoretical diagnostic thinking chain; to perform a preliminary diagnosis on the clinical entity using the fusion diagnostic thinking chain, and to calculate the information gain of the preliminary diagnostic results using a competitive hypothesis approach; and to generate an examination form based on the information gain and the preliminary diagnostic results, wherein the examination form contains multiple examination items. The report constraint generation module, connected to the inspection planning module, is used to obtain the inspection data corresponding to the inspection form, and to output an auxiliary report based on the inspection data and the preliminary diagnosis results using the base large language model.

2. The medical clinical support system based on multiple hypothesis testing according to claim 1, characterized in that, The clinical entity extraction module includes: An interface unit, connected to the input module of the medical system, is used to receive the user's chief complaint data input in natural language, wherein the chief complaint data includes at least physical condition, symptoms, past medical history and medical records; An entity recognition unit, connected to the interface unit, is used to call a medical language model to perform word segmentation and medical named entity recognition on each piece of information in the chief complaint data, and to abstract symptom entities, sign entities, past medical history entities, and medication entities based on the recognition results. The encoding conversion unit, connected to the entity recognition unit, is used to perform context disambiguation processing on ambiguous entities in the symptom entity, the sign entity, the past history entity, and the medication entity based on a preset medical dictionary to obtain a standard entity set; and to map each entity in the standard entity set to a standard medical terminology encoding system to obtain clinical entities.

3. The medical clinical support system based on multiple hypothesis testing according to claim 1, characterized in that, The clinical diagnostic pathway construction module includes: The clinical phenotype anchoring unit is used to construct a patient feature vector based on the clinical entity and to select Top-K candidate cases by calculating the cosine similarity between the patient feature vector and the pre-stored case prototype vector. The first differential diagnosis reasoning unit is used to statistically analyze the distribution of diagnostic results corresponding to the Top-K candidate cases, generate a candidate disease set, and construct a probabilistic clinical diagnostic thinking chain based on the candidate disease set.

4. The medical clinical support system based on multiple hypothesis testing according to claim 3, characterized in that, The first differential diagnostic reasoning unit is specifically used for: The diagnostic logic and diagnostic features of each candidate case are extracted, and the disease probability distribution of each candidate case in the Top-K candidate cases is calculated based on the diagnostic features. Based on the diagnostic logic and diagnostic features, a corresponding clinical diagnostic thought chain is constructed, and each clinical diagnostic thought chain is assigned a priority according to the disease probability distribution.

5. The medical clinical support system based on multiple hypothesis testing according to claim 2, characterized in that, The theoretical diagnostic path construction module includes: The query unit is used to use the clinical entity as a graph query node to filter candidate graphs in the medical knowledge graph database that contain at least two identical symptom entities, sign entities, past medical history entities, and medication entities. The differential diagnosis reasoning unit is used to perform reverse causal path traversal based on the candidate atlas along the relationship between symptoms, diseases, and examinations, extract disease nodes and examination nodes related to the clinical entity, and construct a differential diagnosis subgraph containing multiple competing diseases.

6. The medical clinical support system based on multiple hypothesis testing according to claim 1, characterized in that, The inspection planning module includes: The fusion unit is used to perform consistency analysis between the clinical diagnostic thinking chain and the theoretical diagnostic thinking chain, and to construct a fusion diagnostic thinking chain based on the analysis results. The pre-diagnosis unit is used to diagnose the clinical entity based on the fusion diagnostic thinking chain to obtain a diagnostic space; The gain unit is used to calculate the uncertainty entropy value of each disease option in the diagnostic space; and to calculate the expected information gain of each candidate examination item by simulating the diagnostic changes under different examination results based on the uncertainty entropy value through multiple hypothesis verification. The indicator planning unit is used to select the inspection items with the greatest information gain to generate an inspection list.

7. The medical clinical support system based on multiple hypothesis testing according to claim 6, characterized in that, The gain unit is specifically used for: Extract local sub-graphs of Top-K diseases in the diagnostic space; Enumerate candidate examination items in the local subgraph and simulate the distribution of diagnosis under different results for each candidate examination through multiple hypothesis testing. The expected information gain for each candidate examination is calculated based on the diagnostic distribution.

8. The medical clinical support system based on multiple hypothesis testing according to claim 7, characterized in that, The gain unit is specifically used for: Calculate the Shannon entropy of each candidate examination item under the corresponding diagnostic distribution; Predict the probability of occurrence of candidate examination items under different outcomes, and calculate the updated diagnostic entropy under different outcomes; The difference between the Shannon entropy and the diagnostic entropy is calculated, and the information gain of the corresponding candidate examination item is determined by comparing it with the preset expected entropy.

9. The medical clinical support system based on multiple hypothesis testing according to claim 6, characterized in that, The inspection planning module also includes a diagnostic closed-loop update unit, specifically used for: Obtain the inspection results returned by the external inspection system, wherein the inspection results are the inspection data corresponding to the inspection form; Based on the examination results, the likelihood of each disease option in the diagnostic space is calculated, and the occurrence probability of each disease option is updated using Bayes' theorem. Determine whether the disease option with the highest probability of occurrence among all disease options exceeds a preset threshold; otherwise, continue to plan and calculate the information gain of each examination item.

10. The medical clinical support system based on multiple hypothesis testing according to claim 1, characterized in that, The report constraint generation module includes: The data fusion unit is used to receive the examination data, the preliminary diagnosis results, and the diagnostic path information in the fusion diagnostic thinking chain, and to perform structured fusion to generate unified diagnostic context data. An evidence chain construction unit, connected to the data fusion unit, is used to extract positive causal paths supporting the target disease from the fusion diagnostic thinking chain, and to screen key evidence nodes based on the examination data to construct a positive evidence chain. The exclusion chain construction unit, connected to the evidence chain construction unit, is used to identify candidate diseases competing with the target disease based on the examination data, extract the falsified causal paths, and construct a reverse exclusion evidence chain. The report generation unit, connected to the evidence chain construction unit and the exclusion chain construction unit, is used to call the base large language model to generate a structured auxiliary diagnostic report based on the positive evidence chain and the reverse exclusion evidence chain.

Images